I've been putting off upgrading my DMD because I was afraid the new length
feature would quietly break some of my code. Well, today I finally decided
to upgrade because of the new stream.d fixes. I recompile one of my projects
to find a very strange runtime error message:
   Error: file 'D:\foo

It's due to std.file.getcwd() leaving on a null byte! getcwd() was bitten by
this feature in the code:
   dir[0 .. length]
which used to refer to the local variable named length, but now is
implicitly dir.length, which is leaving the null byte in the array.

I think it should be an error to declare something with the name length, so that you catch these mistakes easily. length is a popular name.

--
Christopher E. Miller

"Vathix" <vathixSpamFix@dprogramming.com> wrote in message news:ch22pr$qvq$1@digitaldaemon.com...
> I've been putting off upgrading my DMD because I was afraid the new length feature would quietly break some of my code. Well, today I finally decided to upgrade because of the new stream.d fixes. I recompile one of my
projects
> to find a very strange runtime error message:
>    Error: file 'D:\foo
>
> It's due to std.file.getcwd() leaving on a null byte! getcwd() was bitten
by
> this feature in the code:
>    dir[0 .. length]
> which used to refer to the local variable named length, but now is
> implicitly dir.length, which is leaving the null byte in the array.
>
> I think it should be an error to declare something with the name length,
so
> that you catch these mistakes easily. length is a popular name.

I was bitten by that in recompiling Phobos, too. But I'm a bit reluctant to make it a keyword as it is popular.

> > I think it should be an error to declare something with the name length,
> so
> > that you catch these mistakes easily. length is a popular name.
>
> I was bitten by that in recompiling Phobos, too. But I'm a bit reluctant
to
> make it a keyword as it is popular.
>

I actually don't really like this feature. Allowing with(array) makes more sense to me. It explicitly lets you specify which array you want length to refer to, and it's not just for length.

How about a vote?
   1) Leave it how it is now; having all these silent bugs and possible
future misunderstandings.
   2) Make it an error to declare something with the name 'length'.
   3) Replace the feature with:  with(array)statement

Mango was bitten by it too. The silent bugs are a glaring minefield, so something has to change. Frankly, there was nothing wrong with how it was before; e.g.

char[] substring = text [index .. text.length];

What's wrong with being explicit about where the 'length' property is coming from? Introducing this new 'special case' within the bounds of a [] pair provides no tangible value to the programmer, and is an impediment to catching subtle bugs.

Permit me to ask the obvious question: why was this changed in the first place?



"Vathix" <vathixSpamFix@dprogramming.com> wrote in message news:ch2deu$10tu$1@digitaldaemon.com...
> > > I think it should be an error to declare something with the name
length,
> > so
> > > that you catch these mistakes easily. length is a popular name.
> >
> > I was bitten by that in recompiling Phobos, too. But I'm a bit reluctant
> to
> > make it a keyword as it is popular.
> >
>
> I actually don't really like this feature. Allowing with(array) makes more sense to me. It explicitly lets you specify which array you want length to refer to, and it's not just for length.
>
> How about a vote?
>    1) Leave it how it is now; having all these silent bugs and possible
> future misunderstandings.
>    2) Make it an error to declare something with the name 'length'.
>    3) Replace the feature with:  with(array)statement
>
>
>

"antiAlias" <fu@bar.com> wrote in message news:ch2fml$126h$1@digitaldaemon.com...
> Mango was bitten by it too. The silent bugs are a glaring minefield, so something has to change. Frankly, there was nothing wrong with how it was before; e.g.
>
> char[] substring = text [index .. text.length];
>
> What's wrong with being explicit about where the 'length' property is
coming
> from? Introducing this new 'special case' within the bounds of a [] pair provides no tangible value to the programmer, and is an impediment to catching subtle bugs.
>
> Permit me to ask the obvious question: why was this changed in the first place?
>

Probably because of things like:

blaBla.foo!(int).bar.getSomething.subSomething[0..blaBla.foo!(int).bar.getSo
mething.subSomething];
vs
blaBla.foo!(int).bar.getSomething.subSomething[0..length];

:)


>
> "Vathix" <vathixSpamFix@dprogramming.com> wrote in message news:ch2deu$10tu$1@digitaldaemon.com...
> > > > I think it should be an error to declare something with the name
> length,
> > > so
> > > > that you catch these mistakes easily. length is a popular name.
> > >
> > > I was bitten by that in recompiling Phobos, too. But I'm a bit
reluctant
> > to
> > > make it a keyword as it is popular.
> > >
> >
> > I actually don't really like this feature. Allowing with(array) makes
more
> > sense to me. It explicitly lets you specify which array you want length
to
> > refer to, and it's not just for length.
> >
> > How about a vote?
> >    1) Leave it how it is now; having all these silent bugs and possible
> > future misunderstandings.
> >    2) Make it an error to declare something with the name 'length'.
> >    3) Replace the feature with:  with(array)statement
> >
> >
> >
>
>

"antiAlias" <fu@bar.com> wrote in message news:ch2fml$126h$1@digitaldaemon.com...
> Mango was bitten by it too. The silent bugs are a glaring minefield, so something has to change. Frankly, there was nothing wrong with how it was before; e.g.
>
> char[] substring = text [index .. text.length];
>
> What's wrong with being explicit about where the 'length' property is
coming
> from? Introducing this new 'special case' within the bounds of a [] pair provides no tangible value to the programmer, and is an impediment to catching subtle bugs.
>
> Permit me to ask the obvious question: why was this changed in the first place?

It's a problem for things like:

    e[0..e.length]

when e is an arbitrarilly complex expression with side effects. For example, e could be a function returning an array. Or a template instantiation. Or a combination of the two.

"Walter" <newshound@digitalmars.com> wrote in message news:ch2hmr$138t$1@digitaldaemon.com...

"antiAlias" <fu@bar.com> wrote in message news:ch2fml$126h$1@digitaldaemon.com...
> Mango was bitten by it too. The silent bugs are a glaring minefield, so something has to change. Frankly, there was nothing wrong with how it was before; e.g.
>
> char[] substring = text [index .. text.length];
>
> What's wrong with being explicit about where the 'length' property is
coming
> from? Introducing this new 'special case' within the bounds of a [] pair provides no tangible value to the programmer, and is an impediment to catching subtle bugs.
>
> Permit me to ask the obvious question: why was this changed in the first place?

It's a problem for things like:

    e[0..e.length]

when e is an arbitrarilly complex expression with side effects. For example, e could be a function returning an array. Or a template instantiation. Or a combination of the two.

===========================

Right. Thanks for the clarification.

However, you've added a special-case for array lengths which does not help in any fundamental manner with the general-case. Further, this special-case open the door to subtle and nasty bugs; in both existing and new code.

The problem here is trying to do too much within a single expression. There's good reason why constructors are really intended to /construct/ only; rather than perform some arbitrarily complex functionality.

Might I suggest coming up with a way to handle the general-case, rather than introducing a special-case for arrays only? That way, you'll have helped the language evolve systematically, and avoided making it rather fragile at the same time.

For example: expression 'e' might be held in a temporary, and made available as a keyword?

> It's a problem for things like:
>
>    e[0..e.length]
>
> when e is an arbitrarilly complex expression with side effects. For
> example,
> e could be a function returning an array. Or a template instantiation. Or
> a
> combination of the two.

Is it possible with something obvious like

e[k..]

meaning

e[k..e.length]

or is that problematic?

No keyword needed, no name clash, shorter expression. Perhaps the expression syntax suffers.

Bent Rasmussen wrote:
>>It's a problem for things like:
>>
>>   e[0..e.length]
>>
>>when e is an arbitrarilly complex expression with side effects. For example,
>>e could be a function returning an array. Or a template instantiation. Or a
>>combination of the two.
> 
> 
> Is it possible with something obvious like
> 
> e[k..]
> 
> meaning
> 
> e[k..e.length]
> 
> or is that problematic?
> 
> No keyword needed, no name clash, shorter expression.
> Perhaps the expression syntax suffers.

Nice, but it doesn't scale as well.  The 'length' keyword lets us do things like

    e[length - 4 .. length]

Python evades this problem by shamelessly disregarding runtime performance and interpreting negative subscripts as being taken from the end.  D doesn't have that option. :)

 -- andy

> Nice, but it doesn't scale as well.  The 'length' keyword lets us do things like
>
>     e[length - 4 .. length]
>
> Python evades this problem by shamelessly disregarding runtime performance and interpreting negative subscripts as being taken from the end.  D doesn't have that option. :)

I see and that argument ties in with Walters argument. If it were not for that argument I would say  that it is no big deal because it doesn't have to scale, as far as I can see; but that's a matter of oppinion. Its also possible to do the other way around, although with near no benefit except symmetry (I'm a sucker for that though)

e[i..]
e[..j]
e[i..j]

It boils down to having something short that stands for length. It could be some special symbol of course, but who wants to sacrifice $ for such a purpose

e[..$]
e[..$-c]