Is @safe still a work-in-progress?

[Steven Schveighoffer]

On 8/24/18 10:25 PM, Walter Bright wrote:
> 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.

So this would mean a member function would have to be refactored into a 
different function with a different calling syntax. i.e:

x.foo(target);

would have to be refactored to:

target.foo(x);

or foo(target, x);

Aside from the adjustment in name that is necessary to make this read 
correctly, that may cause other problems (sometimes non-member functions 
aren't available if it's a template instantiation).

>>> 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.

I stand partly corrected! Indeed you can put a void-returning function 
at the *end* of a pipeline call, I hadn't thought of that.

But in terms of put, strictly speaking, any call of some.pipeline.put(x) 
is wrong. It should be put(some.pipeline, x), to avoid issues with how 
put was designed.

>> 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.

Maybe it's better to designate one sink, and have that be the result. I 
know that after inout was implemented, there were definitely cases where 
one wanted to have multiple inout routes (i.e. independent traces 
between multiple parameters for copying mutability). It may be the same 
for this, I don't know.

>> 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.

I don't mean prove like mathematical proof. I mean try to consider how 
this affects all cases instead of just the one case that will make 
phobos compile.

"show" is a better verb than "prove".

>> 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'm just saying if dip1000 cannot fix all the problems, that instead of 
adding weird exceptions, or the classic "you're just doing it wrong", 
maybe we should reconsider the approach.

Another case which was brought up and pretty much ignored was this one: 
https://forum.dlang.org/post/qkrdpmdqaxjadgvsojxr@forum.dlang.org

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

I'm opting for the latter, as the idea of band-aid PRs to get Phobos 
compiling with dip1000 just to see if dip1000 is going to work seems 
like the wrong approach to me.

The consequence of this is that getting out of the way means your PRs 
don't get pulled.

-Steve