October 22, 2005
In article <djdtqk$2ht$1@digitaldaemon.com>, Burton Radons says...
>
>I've argued before that all the C type languages have it wrong - keywords should be distinct from identifiers.  The way it is now just causes problems, such as, say, changing a common identifier into a keyword and breaking five years of code.  Languages, like software, should be designed with the expectation of change.

We could always make D like Fortran and have all keywords be non-reserved.  Then there wouldn't be any problems ;-)


SEan


October 22, 2005
In article <djds6t$u2$1@digitaldaemon.com>, Burton Radons says...
>
>This is why I never use "with" anymore; at some point it always seems to produce fragile base class problems.  And I'm one person!  I can't imagine how problematic that would get with a team, or with multiple teams working together, or with a program over five years old.

I don't use 'with' either, for much the same reason--I don't like the ambiguity that 'with' tends to create.  By contrast, I like the 'length' convention because the scope it's valid in is quite small, and because I find it more meaningful than '$'.


October 22, 2005
In article <djcipj$ilp$1@digitaldaemon.com>, Burton Radons says...
>
>The contextual identifier "length" has been a problem ever since it was introduced (I can never seem to stop naming an identifier I'm going to use in an array "length", and any time I use it intentionally it looks odd), and we've had the superior "$" for a long time now.  As a result, "length" is becoming even more of a problem because I forget it even exists, and I'm sure there are people who don't know of the superior alternative.  I think it's now time to go to the next step and deprecate and eventually remove this bad thing.

Sorry Burton, but I'm on the opposite side of this issue...I'm always forgetting about the '$' (dollar-sign) being length, I did't think it was a good idea back in dmd v0.116 when it was created, and don't use it now, and I won't use it in the future! I think that the '$' should be the one deprecated out of D, and to leave the 'length' within arrays alone. Frankly, I'm always using the array name then the '.length', but if 'length' stays in, I would go with using the 'length' stand-alone in arrays. (Forget about wasting '$' token for this! Better to use it for a Meta-Programming token or something more useful!)

Highest regards,
David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
October 22, 2005
On Sat, 22 Oct 2005 15:59:19 -0400, clayasaurus <clayasaurus@gmail.com> wrote:

> Burton Radons wrote:
>> The contextual identifier "length" has been a problem ever since it was introduced (I can never seem to stop naming an identifier I'm going to use in an array "length", and any time I use it intentionally it looks odd), and we've had the superior "$" for a long time now.  As a result, "length" is becoming even more of a problem because I forget it even exists, and I'm sure there are people who don't know of the superior alternative.  I think it's now time to go to the next step and deprecate and eventually remove this bad thing.
>
> How is "length" any different than "sizeof" "ptr" "dup" "reverse" and "sort" ?

Because length can be used without specifying the variable name being used if it's in an array or slice subscript. The others can't do that. A lot of people are using "length" for other variable names and it will cause (and already is) a lot of grief. When this magic length was added, I stated that I'm glad I named my length variables "len" and avoided this. For some reason, I still don't like $ for length; but I can't say that I've given it much of a chance becuase it hasn't been widely accepted yet (I believe it's even still a trial feature). I do prefer $ over length due to the above reasons, however.

I think this magic "length" should be deprecated.

Compromise: $length might be the best solution.

Someone suggested "len" instead of "length", I think it's worse ;)

>
> Here's a good thread so we don't repeat too much previous discussions.
> http://www.digitalmars.com/d/archives/digitalmars/D/17942.html

"How about xx for "something big" and $ for length?"
   xx -> @
October 22, 2005
On Fri, 21 Oct 2005 22:30:25 +0000, Burton Radons wrote:

> The contextual identifier "length" has been a problem ever since it was introduced (I can never seem to stop naming an identifier I'm going to use in an array "length", and any time I use it intentionally it looks odd), and we've had the superior "$" for a long time now.  As a result, "length" is becoming even more of a problem because I forget it even exists, and I'm sure there are people who don't know of the superior alternative.  I think it's now time to go to the next step and deprecate and eventually remove this bad thing.

I only use '$' and never 'length'. Actually, I never use 'length', or any standard English word, as an identifier name either. The use of these words exposes a program to future changes in the reserved word list of the language. I prefer to avoid this risk.

I suggested '$' to Walter because of its existing usage in regular expression syntaxes - in which it represents the end of a line (not the last character) thus I naturally see '$' as the length symbol. However, regardless of which symbol token that Walter would have chosen, that symbol would have been better than a word which could also be an identifier name in other contexts.

-- 
Derek Parnell
Melbourne, Australia
23/10/2005 7:55:17 AM
October 22, 2005
Derek Parnell escribió:
> 
> I only use '$' and never 'length'.
> 

Same here. I didn't even remember about that special case. Thanks for reminding me... That said, I vot for $ to stay and "length" to go.

-- 
Carlos Santander Bernal
October 22, 2005
Ouch! Someone just jabbed a sharp stick into my ribs.

For those who don't recall, here's an attempt to capture some history:


The problem
=========

For purposes of illustration:

# char[] getLine (char[] s)
# {
#        uint length = s.length;
#        foreach (uint i, char c; s)
#                      if (c == '\n')
#                        {
#                        length = i;
#                        break;
#                        }
#       return s [0..length];
# }

That function is supposed to return the subset of its argument only as far as a newline, or all of it if there's no newline present. Do you see the insideous bug there? Many of you will not, so here's the beef:

Walter added a very subtle pseudo-reserved word, that's only used when it comes to arrays. Yes, it's that word "length". When used within square-brackets, it always means "the length of the enclosing array". Of course, this overrides any other variable (or function) that happens to be called "length". Naturally, no warning is emitted, and the result is a nasty and difficult to spot bug.


Why was this introduced?
=================

The problem originated where one might need to reference the array-length within a sub-expression; typically an expression within the array brackets themselves. This extended to templates, which required a means to explicitly reference the array length whilst avoiding recanting the array itself (or something like that ~ I'm just relying on memory here).

The upshot, I understand, was that the notion of an implicit array-length 'temporary' seemed appropriate. Unfortunately it was implemented as a pseudo-reserved "length", rather than in some alternate manner that didn't quite shove it up the programmers' proverbial arse. So to speak.


How did the '$' thing happen?
===================

There was actually some notable* concensus on a resolution, using '$' (or some other character) as a prefix. Thus we might have had $length or $len, $argptr, $arguments, $file, $line, and $timestamp which, by the nature of reserving the $ prefix, would have left the door open for D to optionally add further "meta keywords" down the road; and, most importantly, without the possibility of collision against programmer-defined identifiers such as variable-names. Any old prefix would have worked, as long as it were /reserved/ for compiler usage only.

Instead, that notion was abandoned in favour of reserving $ explicitly, and solely, to replace the fragile usage of "length" within arrays. Having said that, $ within arrays is apparently still a "test", and said use of length within array-brackets is still supported at this time.


The upshot
========

Some comments posted thus far might lead one to believe the issue is one of "what looks nicer". While that may be important, this topic is about something of greater substance ~ IMO ~ I sincerely hope that has been made reasonably clear.

Burton is saying: "isn't it time to drop the fragile meaning of length completely (remove that special case from the compiler), and move '$' to a more permanent status?". He is not trying to say that '$' is somehow better than 'length', or vice versa. We've beaten that to death in the past.

For my money, I'd like to see the "prefix" approach adopted. Yet I seriously doubt that will happen. In leui of that, I'll second Burton's request to solidify, or <gasp> maybe even wrap up, the status of this long-running issue.


- Kris


* Notable in that concensus on this NG is exceptionally rare.


October 22, 2005
In article <129emmh9luoam.1if5cpo9j11ib$.dlg@40tude.net>, Derek Parnell says...
>
>I suggested '$' to Walter because of its existing usage in regular expression syntaxes - in which it represents the end of a line (not the last character) thus I naturally see '$' as the length symbol.

Ah, that makes sense.  I'd forgotten about this aspect of regular expressions. At least I now know why '$' was chosen :-)


Sean


October 23, 2005
In article <djeht6$k60$1@digitaldaemon.com>, Kris says...
>
>There was actually some notable* concensus on a resolution, using '$' (or some other character) as a prefix. Thus we might have had $length or $len, $argptr, $arguments, $file, $line, and $timestamp which, by the nature of reserving the $ prefix, would have left the door open for D to optionally add further "meta keywords" down the road; and, most importantly, without the possibility of collision against programmer-defined identifiers such as variable-names. Any old prefix would have worked, as long as it were /reserved/ for compiler usage only.
>
>Instead, that notion was abandoned in favour of reserving $ explicitly, and solely, to replace the fragile usage of "length" within arrays. Having said that, $ within arrays is apparently still a "test", and said use of length within array-brackets is still supported at this time.
..
>For my money, I'd like to see the "prefix" approach adopted. Yet I seriously doubt that will happen. In leui of that, I'll second Burton's request to solidify, or <gasp> maybe even wrap up, the status of this long-running issue.

For me, this has been one of those "I've never done it, so what's the problem" issues.  But I I agree that the 'length' token, by itself, can cause subtle errors, and there's no reason to have the potential for that in D.  I somewhat prefer the prefix idea as well, though now that I know that the '$' symbol was chosen for its meaning in regular expressions, I'm not sure I could see it as anything else.  Count me as a part of the "it's been long enough, get rid of 'length'" contingent.


Sean


October 23, 2005
Vathix wrote:
> On Sat, 22 Oct 2005 15:59:19 -0400, clayasaurus <clayasaurus@gmail.com>  wrote:
> 
>> Burton Radons wrote:
>>
>>> The contextual identifier "length" has been a problem ever since it was  introduced (I can never seem to stop naming an identifier I'm going to  use in an array "length", and any time I use it intentionally it looks  odd), and we've had the superior "$" for a long time now.  As a result,  "length" is becoming even more of a problem because I forget it even  exists, and I'm sure there are people who don't know of the superior  alternative.  I think it's now time to go to the next step and  deprecate and eventually remove this bad thing.
>>
>>
>> How is "length" any different than "sizeof" "ptr" "dup" "reverse" and  "sort" ?
> 
> 
> Because length can be used without specifying the variable name being used  if it's in an array or slice subscript. The others can't do that. A lot of  people are using "length" for other variable names and it will cause (and  already is) a lot of grief. When this magic length was added, I stated  that I'm glad I named my length variables "len" and avoided this. For some  reason, I still don't like $ for length; but I can't say that I've given  it much of a chance becuase it hasn't been widely accepted yet (I believe  it's even still a trial feature). I do prefer $ over length due to the  above reasons, however.
> 
> I think this magic "length" should be deprecated.

Ahh. Ok, I guess I missed the whole point then. I agree it should be depreciated, but I don't agree it should be replaced with $, since $ is not intuitive.

> 
> Compromise: $length might be the best solution.
> 

I like it! Perhaps even @length (@ = 'a' = 'array' in my mind).

[0..$length]
[0..@length]

> Someone suggested "len" instead of "length", I think it's worse ;)
> 

I can see why :-P

>>
>> Here's a good thread so we don't repeat too much previous discussions.
>> http://www.digitalmars.com/d/archives/digitalmars/D/17942.html
> 
> 
> "How about xx for "something big" and $ for length?"
>    xx -> @