On Saturday, 28 January 2017 at 22:31:23 UTC, Walter Bright wrote:
>
>> It only addresses cases where a reference might be escaped through a
>> single return value; it doesn't address escaping through 'out' parameters,
>
> Yes it does (the general case is storing a value into any data structure pointed to by an argument).

I don't understand. Let's say I have an arbitrary class 'Container', and I want a function that stores a pointer to an int in this container, in a way that lets the function's caller know that the int* given to it will last only as long as the container, and I want to do it without return values. The prototype would be akin to

    void store(ref <scope-info> Container cont, <scope-info> int* ptr);

And the code it would be used in would look like:

    {
        scope Container c;
        scope int*      ptr = ...;

        store(c, ptr);
    }

What would the syntax be?

>> or through a returned tuple.
>
> Yes it does (it's as if the tuple elements were fields of a struct).

I meant a little more specific. You have no way to do this

Pair!(int*, float*)   makePair(<scope of return.first> int*,
                               <scope of return.second> float*);

You can declare them both a scope return, but then their scope is "merged" into the return value, which may be undesirable if you want to treat them differently. Although it's not that important, because this particular case would rarely appear in actual practical code, unlike swap and out parameters.

> There will be a need for @system code for some things, that is correct. That's also true of Rust, where cyclic data structures have to be marked as unsafe, and functions cannot access mutable global data.

Yeah, but cyclic data structures and complex types are one thing. I'm just talking about having a (scope int*)[] type, and a swap function. Those should be covered in the scope system, and shouldn't need GC or RC.

> Nobody has come up with a better plan. A Rust-like system would require users to not just add annotations, but redesign all their code and data structures. It's out of the question.

> There has been off and on for about 10 years. Little has come of it.
>
> Then came -dip25, which addressed the return ref problem. It worked surprisingly well. There was some severe criticism of it last year as being unusable, but those turned out to be implementation bugs that were not difficult to resolve.

Well, I liked Schultz's original proposal. It seemed easier to theorize formally, and didn't need major redesign the way Rust's templates do.

And having read the thread it was proposed in... I didn't see any brainstorming? It seems to me that dip25 replaced Schult's proposal without transition, or without debate about the merits and trade-offs of either proposition, or any rationale explaining why Schultz's proposition was abandoned.

> It's fair if you don't agree with my rationale, but that isn't the same as not addressing them at all. I believe I have addressed the issues you brought up here. If you'd like further clarification, please ask.

I'll probably have more to say on that later, but I think THIS is the major point of contention. I don't feel like you've addressed my concerns, because I'm pretty sure you haven't understood my concerns. You interpreted my remarks as obstacles to be overcome, not as information I was trying to communicate to you.

I feel like your opinion is that the reason I'm arguing against dip1000 is that I don't understand it or its context well enough. I feel you have the same opinion of others people who argue against the dip. This is what I meant by "not being taken seriously".

> I didn't write that.

Sorry, I was replying another poster above in the thread. I'm not used to mailing list forums.

On 1/28/2017 3:56 PM, Olivier FAURE wrote:
> Let's say I have an arbitrary class 'Container', and I want
> a function that stores a pointer to an int in this container, in a way that lets
> the function's caller know that the int* given to it will last only as long as
> the container, and I want to do it without return values. The prototype would be
> akin to
>
>     void store(ref <scope-info> Container cont, <scope-info> int* ptr);
>
> And the code it would be used in would look like:
>
>     {
>         scope Container c;
>         scope int*      ptr = ...;
>
>         store(c, ptr);
>     }
>
> What would the syntax be?


    c.ptr = ptr;

You can also do:

    ref Container store(ref return scope c, return scope int* ptr);


> You can declare them both a scope return, but then their scope is "merged" into
> the return value, which may be undesirable if you want to treat them
> differently. Although it's not that important, because this particular case
> would rarely appear in actual practical code, unlike swap and out parameters.

Yes, the result is the "merged" scope. This issue is a known (discussed previously on the n.g.) limitation. Is it a significant one? I doubt it, as I have a hard time contriving a realistic example. Time will tell, though.


> And having read the thread it was proposed in... I didn't see any brainstorming?
> It seems to me that dip25 replaced Schult's proposal without transition, or
> without debate about the merits and trade-offs of either proposition, or any
> rationale explaining why Schultz's proposition was abandoned.

The rationale is I was looking for a much simpler scheme. Even -dip25 is a very simple scheme, and I have a hard time convincing people to use it. What chance does a complex annotation scheme have?


> I'll probably have more to say on that later, but I think THIS is the major
> point of contention. I don't feel like you've addressed my concerns, because I'm
> pretty sure you haven't understood my concerns. You interpreted my remarks as
> obstacles to be overcome, not as information I was trying to communicate to you.

Aren't problems obstacles to be overcome? I don't really understand your point. You ask me to clarify, I try to clarify. You ask how can this be done, I try to answer. You say you don't like the syntax, I agree and say I can't find anything better. You say there's a limitation, I agree and say based on my experience with it so far it is not a killer limitation.

Please keep in mind we do not have a blank slate. There are serious constraints:

1. dip1000 and non-dip1000 has to coexist
2. cannot ask people to rethink and redesign algorithms and data structures
3. new syntax has to be minimal
4. breaking existing code is unacceptable
5. creating a bondage-and-discipline lifetime tracking annotation system will not be acceptable to most users
6. using it needs to be opt-in
7. once one tries to implement something, it gets a lot harder than just writing a spec. Trying to shepherd it through the test suite, Phobos, and existing projects is not at all straightforward.

Any system has to deal with those things.

Remember the 'const' system introduced in D2 was nearly universally disliked for years. Over time it has proven its value.

The reason -dip1000 is behind a switch is so it can be developed without disruption. Dicebot's bug report in this thread is a crack in that, but I'm working on closing it.

Continuing on a new thread because this is getting kinda off-topic.

http://forum.dlang.org/post/jhtvuvhxsayjatsdbhxo@forum.dlang.org

On Friday, 27 January 2017 at 19:12:37 UTC, Walter Bright wrote:
> On 1/27/2017 3:12 AM, Dicebot wrote:
>> And also stuff like https://github.com/dlang/druntime/pull/1740
>
> I'm curious what is wrong with that?

You have been pushing for premature merged of `return scope` under a premise that it will be hidden behind a switch and won't affect anyone yet. Now you rush to adjust druntime to use it and require the same from any druntime contributors.

On 1/29/2017 4:18 AM, Dicebot wrote:
> On Friday, 27 January 2017 at 19:12:37 UTC, Walter Bright wrote:
>> On 1/27/2017 3:12 AM, Dicebot wrote:
>>> And also stuff like https://github.com/dlang/druntime/pull/1740
>>
>> I'm curious what is wrong with that?
>
> You have been pushing for premature merged of `return scope` under a premise
> that it will be hidden behind a switch and won't affect anyone yet. Now you rush
> to adjust druntime to use it

Drilling down in Phobos to make it work with -dip1000, at the bottom are usually calls to core.stdc.*. Without annotating those functions, all progress on -dip1000 comes to a halt.

-dip1000 is designed so that non-dip1000 code can call dip1000 code. Adding these annotations should be benign to existing code. Nothing failed after adding these annotations, either in Phobos which is not (yet) dip1000, nor any of the projects tested, nor any of the test suite.

> and require the same from any druntime contributors.

Since druntime is now compiled with -dip1000, and future druntime contributions are not existing code, that is a reasonable expectation.

On the same premise, I am working to get Phobos compatible with -dip1000. Without that compatibility, -dip1000 is pretty much unusable.

----

It's analogous to druntime and phobos being officially compiled with -dip25, which has been the case for some time now.

On 01/30/2017 12:38 AM, Walter Bright wrote:
> ...

Please, don't waste your time. You mentioned being curious about what is wrong with that PR - I have explained. Let's just stop here before you write another 20 posts presuming that I only disagree with your development methodology because I don't understand it.

On Monday, 30 January 2017 at 01:15:52 UTC, Dicebot wrote:
> On 01/30/2017 12:38 AM, Walter Bright wrote:
>> ...
>
> Please, don't waste your time. You mentioned being curious about what is wrong with that PR - I have explained. Let's just stop here before you write another 20 posts presuming that I only disagree with your development methodology because I don't understand it.

Walter created an entire language and a community around it. Can you, please, share with us how your accomplishments give any importance to whatever your disagreement is with him? All that is visible, here is you protest everything, take any opportunity to verbally abuse everyone and make no contribution.

Thanks.

On Monday, 30 January 2017 at 01:15:52 UTC, Dicebot wrote:
> On 01/30/2017 12:38 AM, Walter Bright wrote:
>> ...
>
> Please, don't waste your time. You mentioned being curious about what is wrong with that PR - I have explained. Let's just stop here before you write another 20 posts presuming that I only disagree with your development methodology because I don't understand it.

I hope it puts some light on why I abandoned the DIP process.

On Monday, 30 January 2017 at 01:34:52 UTC, ilya-stromberg wrote:
> Walter created an entire language and a community around it. Can you, please, share with us how your accomplishments give any importance to whatever your disagreement is with him? All that is visible, here is you protest everything, take any opportunity to verbally abuse everyone and make no contribution.
>
> Thanks.

No because you are making an argument from authority and are asking to replied by another argument from authority, which bring 0 value to anyone.

On Saturday, 28 January 2017 at 21:46:17 UTC, Walter Bright wrote:
>> Same problem, same solution, same fallout.
>
> What problem?

Ask Andrei, he asked for inout's deprecation. I'm not going to run after you two like you are toddlers. Having to make the same case again and again for literally years is not something I wish to take part in. That case has been made. Get up to date or delegate.