[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

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



--- Comment #58 from Kenji Hara <k.hara.pg at gmail.com> 2013-03-31 12:09:31 PDT ---
(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().

> > The fact clearly represents that we cannot always regard $ as "length".
> > Indeed, it is true in built-in arrays and range concept, but isn't true in
> > associative arrays and some user-defined containers. So I think that this
> > enhancement has a bias toward range concept.
> 
> 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.

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")

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.

> > 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.

> 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? 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.

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