Issue 5236 - raw reading for integers and a few refactorings

[RazvanN7]

Added raw reading for integers

[dlang-bot]

Fix	Bugzilla	Description
✗	5236	[patch] std.format.formattedRead/unformatValue does not support the raw reading of integer types

[andralex]

Getting there!

[andralex]

So here T is always a (possibly qualified) bool. Under what circumstances may parse!T(input) not compile?

[andralex]

This will not compile if Range is a wide string: you'd attempt to assign a wide char (2 or 4 bytes) over a single byte. I suggest you change the constraint for rawRead to just ElementType!(Range).sizeof == 1. There is a crazier possibility by which you do accept wide strings and you do implement raw reads, but only if T.sizeof is a multiple of the character size. Probably we don't need this; most people who'd entertain the idea of a raw read will do so from a stream of bytes or a narrow string.

[andralex]

To avoid this cast and clarify the possibilities, you may put this constraint for the function:

if (is(Unqual!(ElementType!Range) == char) || is(Unqual!(ElementType!Range) == byte) || is(Unqual!(ElementType!Range) == ubyte))

[andralex]

Following the logic before, here if somebody wants to parse a wide string with %r you would issue a run-time error:

if (spec.spec == 'r')
{
    static if (is(Unqual!(ElementType!Range) == char) || is(Unqual!(ElementType!Range) == byte) || is(Unqual!(ElementType!Range) == ubyte))
        return rawRead!T(input);
    else
        throw new Exception("The raw read specifier %r may only be used with narrow strings and ranges of bytes."); 
}

[andralex]

This is a distinct matter prior to this PR: the constraint here is too lax, e.g. I could call unformatValue with a float[] and will fail to compile somewhere in the innards of the implementation. The function should recuse itself.

[RazvanN7]

Sorry but I don't get it. All of the other overload functions for unformat value test that T is of a certain type and that input is an InputRange. Why whould the routine for integrals be different?

[andralex]

Consider this code:

void main()
{
	import std.format;
	double[] array;
	FormatSpec!char sp;
	auto x = unformatValue!int(array, sp);
}

This fails to compile (try it!), and the error messages point inside the standard library code. We never want to allow that to happen. Instead, we want to point at the user code "You passed the wrong arguments". That's why we need all templates in the stdlib have constraints that describe exactly the inputs they support.

There are clearly still places where existing code does not satisfy this, but at least we should make sure new code has the appropriate constraints. You may want to fix the problem for the other overloads as well!

[RazvanN7]

So, if I understand correctly, the only case where "auto x = unformatValue!int(array, sp);" should compile is when isSomeChar!(ElementType!<array_Type>)?

[ntrel]

@RazvanN7 Could you include a description in the title of your PRs please - thanks! It helps with managing the PR queue vs somehow remembering bug numbers.

[andralex]

unindent one level

[andralex]

OK, we're good modulo minute nits. Thanks!

[andralex]

unindent one level

[RazvanN7]

Done. Thank you

[andralex]

Auto-merge toggled on