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.
