http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #58 from Kenji Hara <[email protected]> 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: -------
