Release D 2.073.0

[Olivier FAURE via Digitalmars-d-announce]

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.