[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #59 from Andrei Alexandrescu <andrei at erdani.com> 2013-03-31 17:30:22 PDT ---
(In reply to comment #58)
> (In reply to comment #57)
> > I don't think there's any breakage. My understanding is that those containers
> > already need to define opDollar. If opDollar is defined there is no change in
> > semantics.
> 
> No. This enhancement will suddenly change a "correctly invalid" code to
> "accepts-invalid".
> 
> SparseArray a;  // SparseArray does not have opDollar,
> // because it is unnecessary now.
> 
> auto n = a.length;  // actually contains element count, or maximum index number
> a[$-1];  // now: Error: undefined identifier __dollar
>          // after: incorrectly translated to a[a.length-1];
> 
> Finally SparseArray's author should add @disable opDollar().

Understood. I would argue that behavior changes from "invalid" to "valid and
correct". I think it would be hard to find one D programmer who'd write s[$ -
1] and expect it to be anything else than a[a.length - 1]. This behavior has
been built in forever.

Whether SparseArray should support operator [] and length are separate
questions. If it does, and if anyone ever writes a[$ - 1], that should be
correct code and there is no other possible semantics than a[a.length - 1].

> > I'd have quite a bit of difficulty agreeing with this. The notion that "$" is a
> > synonym for "length" predates ranges and has been there for strings and arrays
> > ever since they were defined.
> 
> "$" is a synonym for "length" in D - yes. But, **in general**, "$" is not a
> synonym for "length". The difference is important.

Agreed.

> The advantage of UFCS and std.range.opDollar approach is that is "opt-in" for
> the "$" meaning. It does not change the meaning of current existing code.
> (Again, "change" == "currently invalid/meaningless code will be changed to
> acceptable, potentially and unintendedly")

I'd say the change is to a behavior that has a null surprise factor. If anyone
writes a[$ - 1] or whatnot, it is clear what they meant and what they expect.

> On the other hand, your compiler approach is "opt-out". It moves boilerplate
> code from all range definition to SparseArray definition. This is unacceptable
> to me.

Let me submit for your consideration that (a) it's undecided whether that's bad
for SparseArray, and (b) the vast majority of ranges simply want opDollar be
the same as length. This is the case for all of Phobos, and this bug originated
in wake of a large diff that added very many "alias length opDollar;" to
virtually all ranges that support [] and length. It's just what everybody
expects. I would argue we can't afford to make everybody pay for the sake of a
rare occurrence. 

> > > And, as far as possible, compiler should be a neutral.
> > 
> > That shouldn't be done to a fault, either. The D language is not neutral on
> > user-defined expr++ vs. ++expr; it forces both to have similar semantics to
> > their built-in counterparts. In contrast, the C++ language allows defining
> > ++expr and expr++ with different semantics. But wait, it's worse: (a) C++
> > forces a net loss of efficiency for expr++ barring heroic optimization efforts
> > that are not generally applicable, and (b) C++ requires actual boilerplate to
> > ensure both variants work. I think it is plain that C++ made the wrong decision
> > and D learned from it and made the right decision.
> 
> It is entirely different thing.

I agree it is a different thing. I was replying to the part with "As far as
possible, compiler should be neutral" by simply showing that sometimes being
neutral is exactly the wrong thing to do.

> > Similarly, we should not require boilerplate for $ just to convince it to do
> > what it's always done for arrays and strings. Associative arrays and
> > user-defined containers are free to disable it or define it, depending on
> > what's most useful for them. 
> 
> Why you enforce disabling opDollar to other container authors?

I think most container authors will benefit of that behavior.

> It is equivalent
> to enforce writing "alias opDollar = length;` to all range authors.
> I cannot see any difference there. If you favor the former, I can say it is
> definitely a kind of bias.

Yes, there is a bias - frequency. My core argument is that the vast majority of
ranges simply want $ and length to mean the same thing, and very few need to
have them mean different things.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------