http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #57 from Andrei Alexandrescu <[email protected]> 2013-03-31 11:04:45 PDT --- (In reply to comment #56) > (In reply to comment #55) > > @Kenji: I'm a bit unclear on your view on this. You mention you'd prefer a > > library solution but your pull request seems to go for a in-compiler > > solution. > > As Steven already mentioned in comment#14, automatically forwarding from $ to > 'length' would break user-defined containers. 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. > 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. On the contrary, I'd argue that notions such as length-less ranges and infinite ranges contributed to the notion that opDollar may be (rarely) something distinct from length. > 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. 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. > In other words, this is just reasonable for std.range users. Most of D > programmers would use std.range, but not all. Again, I find it very difficult to agree with this. $ has always been length wherever meaningful - long before ranges came up. > I don't mention that infinite range _should_ have r[n..$], rather mention that > it is possible. Yes, and defaulting $ to length does not prevent that. Again, if a range does define opDollar, that will always be chosen. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
