complement to $

Steven Schveighoffer schveiguy at yahoo.com
Mon May 17 04:07:50 PDT 2010


On Sat, 15 May 2010 01:07:50 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> On Fri, 14 May 2010 13:33:57 -0400, Walter Bright  
>> <newshound1 at digitalmars.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> So how does this look:  coll[^..$];
>>>
>>> nooooooooo <g>
>>  Do you have specific objections, or does it just look horrendous to  
>> you :)  Would another symbol be acceptable?
>
>
> The problem is D already has a lot of syntax. More syntax just makes the  
> language more burdensome after a certain point, even if in isolation  
> it's a good idea.
>

In a lot of cases, this is somewhat true.  On the other hand though,  
shortcut syntaxes like this are not as bad.  What I mean by shortcut is  
that 1) its a shortcut for an existing syntax (e.g. $ is short for  
coll.length), and 2) it doesn't affect or improves readability.

A good example of shortcut syntax is the recent inout changes.  At first,  
the objection was "we already have too mcuh const", but when you look at  
the result, it is *less* const because you don't have to worry about the  
three cases, only one.

The burden for such shortcuts is usually on readers of such code, not  
writers.  But a small lesson from the docs is all that is needed.  Any new  
developer will already be looking up $ when they encounter it, if you put  
^ right there with it, it's not so bad.  Once you understand the meanings,  
it reads just as smoothly  (and I'd say even smoother) as the alternative  
syntax.

I'll also say that I'm not in love with ^, it's just a suggestion.  I'd  
not be upset if something else were to be used.  But 0 cannot be it.

> One particular problem regex has is that few can remember its syntax  
> unless they use it every day.

I don't use it every day, in fact, I almost always have to look up syntax  
if I want to get fancy.

But I always remember several things:

1. [^abc] means none of these
2. . means any character
3. * means 0 or more of the previous characters and + means 1 or more of  
the previous characters
4. ^ and $ mean beginning and end of line.  I usually have to look up  
which one means which :)

point 4 may suggest a special error message if someone does coll[^-1] or  
coll[$..^]

>>>> Thoughts? other ideas?
>>>
>>> I'd just go with accepting the literal 0. Let's see how far that goes  
>>> first.
>>  I thought of a counter case:
>>  auto tm = new TreeMap!(int, uint);
>> tm[-1] = 5;
>> tm[1] = 6;
>>  What does tm[0..$] mean?  What about tm[0]?  If it is analogous to  
>> "beginning of collection" then it doesn't make any sense for a  
>> container with a key of numeric type.
>>  Actually any map type where the indexes don't *always* start at zero  
>> are a problem.
>
> I'd question the design of a map type that has the start at something  
> other than 0.

Then I guess you question the AA design?  Or STL's std::map?  Or Java's  
TreeMap and HashMap?  Or dcollections' map types?

I don't think you meant this.  The whole *point* of a map is to have  
arbitrary indexes, requiring them to start at 0 would defeat the whole  
purpose.

-Steve


More information about the Digitalmars-d mailing list