Am Mon, 22 Jul 2013 05:47:34 +0200
schrieb "JS" <js.mdnq@gmail.com>:

> Doing simple stuff like
> 
> for(int i = 0; i < s.length - 1; i++) fails catastrophically if s is empty. To make right one has to reduce performance by writing extra checks.

And my opinion on the matter is that it is catastrophic style to subtract 1 from a length that's possibly 0. Please write:

if (s.length) foreach (i; 0 .. s.length - 1)

> There seems to be no real good reason why size_t is unsigned... Surely one doesn't require too many strings larger than 2^63 bits on an x64 os...

So the size_t should be signed on 64-bit systems and unsigned on 32-bit systems? And please note that all length properties are unsigned, strings, other arrays, range structures, tuples and bit arrays have a ulong length, because they can theoretically hold more bits than 2^32 on 32-bit systems.

> I running into a lot of trouble because of the way D deals with implicit casting of between signed and unsigned.

That's a good point. There are languages that disallow this implicit conversion. I'd also like size_t to be a type of its own, so you cannot mess up by assigning a size_t to a uint while developing on 32-bit.

> please don't tell me to use foreach... isn't not a panacea.

Yes, please.

-- 
Marco

On 7/22/13, monarch_dodra <monarchdodra@gmail.com> wrote:
> 99% sure that's unspecified behavior. I wouldn't rely on anything like that.

Actually it used to be a bug that writing to the index /without/ ref would end up changing the iteration order, but this was fixed in 2.063. It's in the changelog:

http://dlang.org/changelog.html#foreachref

On Monday, 22 July 2013 at 16:29:39 UTC, Maxim Fomin wrote:
>> This also compiles, but I used a different aggregate, yet represents the same thing. Because it is implemented differently, I get a completely different result. Unless I'm mistaken, when a result depends on the implementation, and the implementation doesn't state what the result is, then that's what unspecified behavior is. (unspecified, not undefined).
>
> This is different because in 0..5 ref int maps directly to variable modified, but in iota() it maps to value returned by .front property function and since it doesn't return by ref, refness is wiped out. Behavior is defined in both cases.

defined: yes
entirely dependant on implementation details: also yes

It's not a pattern to be relied on in the slightest.

Andrej Mitrovic:

> Actually it used to be a bug that writing to the index /without/ ref
> would end up changing the iteration order, but this was fixed in
> 2.063. It's in the changelog:
>
> http://dlang.org/changelog.html#foreachref

The right design in my opinion is to have the iteration variable immutable on default, and mutable/reference on request. This saves from bugs and offers new optimization opportunities. But unfortunately D doesn't have a "mutable" keyword, D variables are generally mutable on default, and Walter seemed not interested in my numerous explanations that the mutable foreach iteration variable is bug-prone. So Hara has adopted a compromise, now if you don't use "ref" the actual iteration variable on an interval doesn't change. But it's mutable on default.

So the standard idiom to use foreach on interval needs to be:

foreach (immutable i; 0 .. 10) { ... }

And the programmer has to remove that immutable only where really the iteration variable must change :-)

Bye,
bearophile

On Monday, 22 July 2013 at 21:08:48 UTC, bearophile wrote:
> So the standard idiom to use foreach on interval needs to be:
>
> foreach (immutable i; 0 .. 10) { ... }
>
>
> Bye,
> bearophile

This comes with another issue embedded here

http://forum.dlang.org/thread/felqszcrbvtrepjtfpul@forum.dlang.org