Is @safe still a work-in-progress?

[Walter Bright]

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 :-)