I think this (the line with y) is worth an enhancement request.
http://d.puremagic.com/issues/show_bug.cgi?id=10615
Bye,
bearophile
Ali Çehreli:
I don't think we are there yet. :)
Thinking some more about this topic I have created a small test
example:
uint i = 100;
void main(in string[] args) {
auto j = args.length;
ubyte x1 = (i ^^ 2) % 256; // OK
ubyte x2 = (i ^^ 3) % 256; // OK
ubyte[] arr = [(i ^^
Ali Çehreli:
That would be great but there are many other cases where the
compiler does not do anything like that. Here, it would have to
decide similar to "even though this is a runtime foreach, I
know at compile time that 'result' is a fixed-length array so
'i' is between 0 and 10. I also h
On 07/10/2013 04:10 PM, bearophile wrote:
> Ali Çehreli:
>
>> Change the code so that the result does not fit a ubyte you will get
>> the same error as in line 11.
>
> The result is supposed to fit in an ubyte because the input is supposed
> to be made of nibbles.
Not in either of the two cases
Ali Çehreli:
Change the code so that the result does not fit a ubyte you
will get the same error as in line 11.
The result is supposed to fit in an ubyte because the input is
supposed to be made of nibbles. (I have tried to add asserts or
tests, but they don't change the situation, so I have
On 07/10/2013 03:08 PM, bearophile wrote:
> Do you know why the assignment to 'item' is accepted in the first case
> and refused in the second?
>
>
> ubyte generate1(s...)() {
> ubyte[10] result;
> foreach (immutable i, ref item; result)
> item = s[0][0] << 4;
s[0][0] is known
Do you know why the assignment to 'item' is accepted in the first
case and refused in the second?
ubyte generate1(s...)() {
ubyte[10] result;
foreach (immutable i, ref item; result)
item = s[0][0] << 4;
return result[0];
}
ubyte generate2(s...)() {
ubyte[10] result;
