DMD 0.177 release [Length in slice expressions]

[Kevin Bealer]

== Quote from Andrei Alexandrescu (See Website For Email)
(SeeWebsiteForEmail at erdani.org)'s article
> Don Clugston wrote:
> > Andrei Alexandrescu (See Website For Email) wrote:
> >> Similarly, let's say that a group of revolutionaries convinces Walter
> >> (as I understand happened in case of using "length" and "$" inside
> >> slice expressions, which is a shame and an absolute disaster that must
> >> be undone at all costs) to implement "auto"
> >
> > This off-hand remark worries me. I presume that you mean being able to
> > reference the length of a string, from inside the slice? (rather than
> > simply the notation).
> >
> > And the problem being that it requires a sliceable entity to know its
> > length? Or is the problem more serious than that?
> > It's worrying because any change would break an enormous amount of code.
>
> It would indeed break an enormous amount of code, but "all costs"
> includes "enormous costs". :o) A reasonable migration path is to
> deprecate them soon and make them illegal over the course of one year.
>
> A small book could be written on just how bad language design is using
> "length" and "$" to capture slice size inside a slice expression. I
> managed to write two lengthy emails to Walter about them, and just
> barely got started. Long story short, "length" introduces a keyword
> through the back door, effectively making any use of "length" anywhere
> unrecommended and highly fragile. Using "$" is a waste of symbolic real
> estate to serve a narrow purpose; the semantics isn't naturally
> generalized to its logical conclusion; and the choice of symbol itself
> as a reminiscent of Perl's regexp is at best dubious ("#" would have
> been vastly better as it has count connotation in natural language, and
> making it into an operator would have fixed the generalization issue).
> As things stand now, the rules governing the popping up of "length" and
> "$" constitute a sudden boo-boo on an otherwise carefully designed
> expression landscape.

I guess the question is, what is the best alternative.  I agree about
'length', and I usually don't use "length" in this way, but I do things
like x[$-2..$] all the time.  Some proposals:

1. Symbols

Going in the symbol direction, it might also make sense to *add* something
like "^" for the start of a container.  This would be useful with AAs and
user defined types.  We could use both: a[^+2..$-2].  This would only really
be useful with containers that did not index from 0, i.e. non-integer or AA
indices.

char[char[]] words;
words[^.."brink"]; // all words in dictionary before 'brink'
words["brack"..$] // instead of symbols

Which could translate to:
words.opSlice(words.opBegin(), "brink")
words.opSlice("brack", opEnd())

2. I like this better: I call it "with without with"

In order to maximize the dollar value :) of syntax symbol real estate, the
meaning of $ could be expanded as follows:

Something like X[$begin..$end] could be a shortcut for either X[0..X.length]
for arrays, or X[X.opBegin()..X.opEnd()] for user types.

I think the above solves the problem, doesn't it?  The "$end" phrase is terse
enough for most coders, unique enough to avoid namespace conflicts, avoids the
problem of keywords ghosting in and out of existence in mid-expression, and
avoids ruining $ (or # if #end is used instead) for the symbol space.

We can stop right there... or go on to something for post-1.0:

Other applications of $ could be:

A. Syntax reduction for enumerated types and fields:

  struct Colors {
    enum { red, green, blue };
    void set(int c);
  };

  Colors c;
  c.set($red);

  This use of enumerated type is becoming more common, having "$" be a
  shortcut for <context>.X might make a lot of code more readable.  The
  question then becomes, "Which contexts are searched for .X?"

B. Reserved for language features.

  Leave this open for language designer use.  All $xyz expressions are context
  dependent keywords.  This allows much shorter words to be used, and allows
  language features to be named intelligently without worrying about crashing
  into user-defined names.  For example, C could never introduce a new keyword
  called "begin" or "end", since it would break nearly every C program, but we
  can easily add a keyword called $begin which will not conflict with anything,
  since the $ saves us from conflicts.

  Most of the discussions for new features here have at least some arguments on
  how to add the new syntax for the feature, what other uses those symbols could
  be used for, etc.  The $xyz route allows Walter to introduce lots of language
  concepts in the future without conflicts.  It could even be used to prototype
  keywords that are experimental.  They can even be removed or promoted to non-$
  status later if desired.

  NOTE that if # was used instead of $, it would dovetail nicely with the
  "#line" and "#file" quasi-keywords.

> > These issues you're raising seem to be far too fundamental to be fixed
> > in the next few days, casting grave doubts on whether a D1.0 release on
> > Jan 1 is a good idea.
>
> The lvalue/rvalue issue is fundamental. I'm not in the position to
> assess whether it's a maker or breaker of D 1.0.
>
> The "length"/"$" issue is not fundamental the same way that C's
> declaration syntax, Java's throw specifications, C++'s use of "<" and
> ">" for templates, and Mao Zedong's refusal to use a toothbrush are not
> fundamental. It will "just" go down in history as a huge embarrassment
> and a good resource for cheap shooters and naysayers. If I understand
> its genesis, it will also be a canonical example of why design by
> committee is bad.
>
> Andrei

I like the terseness of "$" but I'm willing to do away with it if it
really is that bad.  What I'm wondering, is how far do you think we
need to roll back the syntax, before it's "The Right Thing" (tm) again?

Do we really need to go all the way to myarray[0..myarray.length], or
can some intermediate solution work?

Kevin