On 4 September 2016 at 07:38, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/3/16 11:31 AM, Manu via Digitalmars-d wrote: >>> >>> > In any case, these difficulties are the consequence of trying to write >>> > C++ >>> > code in D. >> >> You've told me this before, and I find it kind of offensive every time >> you do, since I've been programming D for like 7 years now, and I >> definitely don't code D like C++. >> If anything, I have a strong tendency to code C++ like D, and that has >> lead to a lot of interesting changes in my C++ style. >> >> I'm tired of these sorts of dismissals. You insist that I'm not a >> 'real' D programmer, or something to that effect. > > > There's really no need to take offense here. We have a bit of a mimosa > culture of easily bruised egos it seems. As the joke goes: "You take offense > too easily." "I can't believe you just said that!" > > It's hard to not see your view as coming straight from the "I want to speak > Italian by replacing English words with Italian words" box. > > * It hypothesizes that one entire style of design is completely impossible > because it lacks one obscure feature from C++.
And you did it again. It's the insistence that I'm trying to write C++ in D that's really annoying. (it's not the first time) I'm writing textbook modern D code. It's a style of design that is absolutely impossible in C++, ergo, I'm writing D code! The thing I'm trying to present is that it doesn't work intuitively. The whole reason I came here to comment is because I realised that D's central modern design pattern, that is, algorithms + UFCS (ie, pipeline style; *impossible in C++*) doesn't quite work properly, and it can be hard to understand why. UFCS needs to 'work', not 'sometimes work'. Let's forget I ever said C++ or ADL. I only raised it because I wondered why this wasn't a problem in C++, and then realised that ADL existed in C++. > * Vast evidence to the contrary is ignored. To the contrary of what? That UFCS from within a template doesn't work in a practical way? Nobody has presented any solution or workaround that doesn't require manual user intervention. A solution like: `adl(string fn, T, Args...)(auto ref T x, auto ref Args args)` has appeared on the table. I find it hard to accept criticism for my opinion when that's the proposed solution. That is a clear demonstration of the problem, not a solution. The logical conclusion of this is that all algorithm implementations have to call all functions this way if you want UFCS to work the way users would expect... but users would not expect to call functions in this way either. > * The fact that the feature is problematic and controversial even within C++ > circles is also neglected. I haven't commented in ADL's merits in C++, just that it's the mechanism by which C++ doesn't exhibit this (similar) problem which is much more significant in D than it is in C++. D needs a solution otherwise UFCS appears a weak language offering where it breaks down when used in algorithm functions, and I quite strongly resist the idea that the best solution is manual user intervention. > * The lack of said feature is regarded as an utter disaster and no > workaround is even close to cutting the mustard. I do think it's an absolute disaster. It's a core premise of modern D, algorithms and UFCS are central. I'd almost say they *are* modern D. I don't think core language offerings and design recommendations should require 'work arounds', that sounds like something that's just broken by design. You're right, that doesn't cut the mustard, and I'd be extremely disappointed to accept that as 'solved'. > * A language change is a must; no library solution would ever be acceptable. Library solution implies user-intervention. My argument is that I find the notion of user intervention in this case unacceptable. I think it's too fundamental to require work-arounds. I'm happy to be proven wrong, but I'm not gonna concede on that point easily. > For the most part this is a Pop a level up and figure what the needed > accomplishment is, so other routes than the ADL bottleneck are possible. > Let's approach this together like a problem that has a solution within D, > and let's make that solution accessible comfortably. Sure... but that doesn't mean I'm just going to accept the proposed workarounds as 'fixed'. I find the proposed workarounds really unpleasant, and I don't want to see that proliferate. I'd rather resist an idea I hate now, than see it take root. If I back off, and they become a thing, then who do I have to blame? > Two apocryphal anecdotes: Koenig invented the eponymous lookup as a > consequence to the fact that namespaces broke the "Hello, world" program > (something to do with cout and endl being migrated to namespace std), which > surprised the inner circles of C++ the way putting mentos in coke surprises > the unwary. Namespaces are an unusually poorly designed feature of C++, not > second even to exceptions. By that time significant work had been invested > in defining and implementing namespaces, so going back wasn't quite an > option. ADL was hailed as a horrible hack but a lifesaving one. Compilers > have been slow to implement ADL, partly because essentially it meant > breaking a lookup algorithm that was relatively orderly and DWIM, and > replace it with a patchwork of special cases. The community has since > learned to live with the odd idioms that make code work with the new rules. I understand these things, but D isn't C++ and modules aren't namespaces. I think something that might appear ADL-like would look different and be simpler in D. An algorithm that calls a function on some T it receives just wants to look near the T; UFCS functions will be there. What you're effectively saying is they introduced ADL as a hack because the language was impractical without it. I'm saying the same situation exists in D right now. I don't think something ADL-like would have the same extent of negative impact on D as it does in C++. Modules are well-defined, and 'looking beside T for UFCS functions' is a much narrower and more well defined search scope. > Second anecdote: Scott Meyers had an infamous talk on C++ in which the > leitmotif was "What does f(x) mean?" Scott asks the question in the > beginning to which the obvious response is "Call function f passing it > argument x". By the time his talk is done, the horrified audience realizes > they have no idea what f(x) means and where it goes. I've seen this one. Again, we're not talking about C++. It hasn't been explored (to my knowledge) how a similar mechanism it would look and affect D. I suspect (with no evidence) it would be relatively benign by comparison to the problems ADL introduces to C++, and D stands to gain a lot more from the transaction, ie, UFCS will work in generic functions the same as non-generic functions. D requires this much more than C++ does, particularly when you take this as the direction of forward momentum for D design.