On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote:
> 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 :-)

Document it and we will help you get it reviewed and merged. Until you do that we will stay in your way. Heck, once we understand it we may even lead, but we can't do that if we have no clue WTF its supposed to do or why the changes are being made.

At the very least PRs need detailed changelog entries and preferably spec updates and revisions to the DIP1000 proposal document. Heck even a wiki page would be useful. I'm trying to make the spec page on memory safe programming the authoritative source see https://github.com/dlang/dlang.org/pull/2453

On Saturday, 25 August 2018 at 02:37:00 UTC, Walter Bright wrote:
> On 8/23/2018 5:58 PM, Chris M. wrote:
>> Seems to be more of a warning of what issues we may face if DIP25/DIP1000 are finally implemented. It would be good to consider NLLs as well before D is committed. No point in repeating issues that have already been studied.
>
> DIP25 waqs "finally implemented" several years ago, and works well. DIP1000 was implemented as well, it works, but it didn't cover the case of returning through a ref parameter.
>
> There's no way to "thoroughly vet" them before implementing. It doesn't happen with C++, either, somebody builds an implementation and then people try it out.

What about my other point then on the syntax? I think something similar to what I suggested would be a much more flexible solution and is worth considering.

On 8/24/18 10:28 PM, Walter Bright wrote:
> On 8/23/2018 8:14 AM, Steven Schveighoffer wrote:
>> If I had to design a specific way to allow the common case to be easy, but still provide a mechanism for the uncommon cases, I would say:
>>
>> 1. define a compiler-recognized attribute (e.g. @__sink).
>> 2. If @__sink is applied to any parameter, that is effectively the return value.
>> 3. In the absence of a @__sink designation on non-void-returning functions, it applies to the return value.
>> 4. In the absence of a @__sink designation on void returning functions, it applies to the first parameter.
>> 5. Inference of @__sink happens even on non-templates.
>> 6. If @__sink is attributed on multiple parameters, you assume all return parameters are assigned to all @__sink parameters for the purposes of verifying lifetimes are not exceeded.
> 
> 
> 'ref' is already @__sink.

No, otherwise we wouldn't need the patch you are pushing.

-Steve

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

On 8/25/2018 5:42 AM, Chris M. wrote:
> What about my other point then on the syntax? I think something similar to what I suggested would be a much more flexible solution and is worth considering.

Much more work would be needed to make that a proposal.

On 8/25/2018 4:09 AM, Nicholas Wilson wrote:
> On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote:
>> 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 :-)
> 
> Document it

Already done: https://issues.dlang.org/show_bug.cgi?id=19097

On Wednesday, 29 August 2018 at 05:04:22 UTC, Walter Bright wrote:
> On 8/25/2018 4:09 AM, Nicholas Wilson wrote:
>> On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote:
>>> 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 :-)
>> 
>> Document it
>
> Already done: https://issues.dlang.org/show_bug.cgi?id=19097

Bugzilla is not documentation. These are language changes they need to be in release notes and the spec.

On 8/28/2018 6:12 AM, Steven Schveighoffer wrote:
> 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);

Maybe it should be anyway.


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

There are some of those in Phobos, too. It's covered by the proposed addition.


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

I don't know how to find all cases, either, except by implementing it.

On 8/23/2018 6:10 AM, Atila Neves wrote:
> ----------
> struct S {
>      int x;
>      @safe int* foo() { return &x; }
> }
> ----------
> 
> % dmd -o- -dip1000 foo.d
> % echo $?
> 0

struct S {
    int x;
    @safe int* foo() { return &x; }
}

int* bar() {
    S s;
    return s.foo();
}

dmd test -dip1000
test.d(3): Error: returning &this.x escapes a reference to parameter this, perhaps annotate with return


> 
> Oops:
> 
> ----------
> int* gPtr;
> void main() {
>      auto s = S(42);
>      gPtr = s.foo;
> }
> ----------

I get:

test.d(3): Error: returning &this.x escapes a reference to parameter this, perhaps annotate with return


> ----------
> int[] gSlice;
> void main() {
>      auto s = S([42]);
>      gSlice = s.foo;
> }
> 
> struct S {
>      int[] x;
>      @safe int[] foo() return { return x; }
> }
> ----------

T[] is treated like T* as far as scope, etc., are concerned. You should see identical results.

> And in a struct, `this` is a `ref`, yet `scope` on a member function applies to `this`.

Actually, it applies to fields of `this`.

On 8/28/2018 10:18 PM, Nicholas Wilson wrote:
> Bugzilla is not documentation. These are language changes they need to be in release notes and the spec.

You asked for a clue: "we have no clue WTF its supposed to do or why the changes are being made" and there it is. There are no barriers to reviewing the idea nor the implementation.