On 8/23/2018 6:32 AM, Steven Schveighoffer wrote:
Furthermore any member function (or UFCS function for that matter) REQUIRES the
first parameter to be the aggregate. How do you make a member function that
stuffs the return into a different parameter properly typecheck?
What I propose is that the function interface be refactored so it does fit into
these patterns. Is that an unreasonable requirement? I don't know. But it
doesn't seem to be, as I haven't run into it yet.
Phobos doesn't do this by accident. It's how constructors work (see above) and
how pipeline programming works.
Constructors I agree are reasonable to consider `this` to be the return value.
On that point, I would say we should definitely go ahead with making that rule,
and I think it will lead to no confusion whatsoever.
pipeline programming depends on returning something other than `void`, so I
don't see how this applies.
grep Phobos for instances of put() and see its signature. It's part of pipeline
programming, and it's all over the place.
You would have to consider the shortest liftetime and assume everything goes
there.
That's right.
It would restrict your legitimate calls.
Maybe that's a good thing. Having multiple simultaneous routes of data out of a
function is not good practice (note that it is impossible with functional
programming). If you absolutely must have it, the exit routes can be aggregated
into a struct, then pass that struct as the first argument.
I want to stress that it may be a valid solution, but we should strive to prove
the solutions are the best possible rather than just use duct-tape methodology.
I don't know how to prove anything with programming languages.
It should even be considered that perhaps there are better solutions even than
the approach dip1000 has taken.
People have hypothesized that for several years, and so far none have been
forthcoming beyond a few hand-wavy generalities.
I also want to point out that the attitude of 'we could just fix it, but nobody
will pull my request' is unhelpful. We want to make sure we have the best
solution possible, don't take criticism as meaningless petty bickering. People
are genuinely trying to make sure D is improved. Hostility towards reviews or
debate doesn't foster that.
I'm not hostile to debate. I just don't care for "this is uncharted territory,
so let's do nothing" which has been going on for probably 4 years now,
coincident with "scope is incomplete, D sux".
I.e. lead, follow, or get out of the way :-)
