On Sunday, 5 May 2013 at 00:47:00 UTC, Walter Bright wrote:
If the compiler accepts that code, it will crash at runtime. If
it doesn't accept that code, then it will also disallow
legitimate code like:
ref T foob(ref U u) { static T t; return t; }
ref T bar() { U u; return foob(u); }
It doesn't accept it, with or without any combination of
annotation. Now, the example with a static effectively require an
annotation.
And it illustrate
wonderfully what I'm saying : most people in the discussion
(and it has been
shown now that this includes you) were unaware of how does
Rust solve the problem.
I don't think excluding a solution that isn't understood is
the smartest thing
to do.
I suggest you enumerate the cases with a Rust-like system and
show us how it solves the problem without annotations. Note
that Rust has pretty much zero real world usage - it's one
thing to say needing to use annotations is 'rare' and another
to know it based on typical usage patterns of the language.
Rust assume, when no annotation is present, that the return ref's
lifetime is the union of ref parameters lifetime. I'm sure we can
find an example of D code somewhere that don't fit into this, but
real world usage in D would almost never require any annotation
(this is the case of all D codebase I've played with as of now,
and I don't actually see any use case for example like the static
one mentioned above).
For example, if the default is "assume the ref return refers to
the ref parameter", then some containers would require the
annotation and some would not. This is not very viable when
doing generic coding, unless you are willing to provide two
copies of each such function - one with the annotations and the
other without.
The default can't be that as several parameters can be passed by
ref. The default is return ref lifetime is the union of ref
parameters lifetime. I don't see any container that require the
annotation.
Note also that if you have A calls B calls C, the annotation on
C doesn't propagate up to B, again leading to a situation where
you're forced to make two versions of the functions.
(I say doesn't propagate because in a language that supports
separate compilation, all the compiler knows about a function
is its signature.)
It doesn't require code duplication. Named lifetime make sense
for the caller, not the callee (in which they only are identifier
that can be used to describe lifetime's relation explicitly for
the caller).
