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.
