ADL

[Manu via Digitalmars-d]

On 4 September 2016 at 07:38, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at 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.