Release D 2.073.0

[Walter Bright via Digitalmars-d-announce]

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.