On 03.06.2016 02:31, Walter Bright wrote:
On 6/2/2016 4:29 PM, Timon Gehr wrote:// need to know that lifetime of a ends not after lifetime of b void assign(S,T)(ref S a, T b){ a = b; }void foo(scope int* k){ void bar(){ scope int* x; // need to check that lifetime of x ends not after lifetime of k assign(x,k);It'll fail to compile because T is not annotated with 'scope'. Annotating T with scope will then fail to compile because the assignment to 'a' may outlive 'b'. ...
There are no actual execution traces with those issues. The point is that you need additional annotations that make it work.
} }> Note that it is tempting to come up with ad-hoc solutions that make some small finite set of examples work. If they cover the cases that matter, it's good.
Yes, but how do you establish that they do without using sound reasoning of the style I'm advocating? For example, there are a lot of tests for DMD, but bugs that matter keep being reported. This issue can be essentially eradicated for many relevant parts of a type system design by sticking to at most a handful of basic principles.
Rust has the type system annotations you want,
We don't need to have the same annotations. We just need to be able to carry the same information around in the type system. I'm sure there is some syntax that will feel natural to D programmers.
but Rust has a reputation for being difficult to write code for.
I don't think it is because it has sufficiently powerful annotations to write verifiably memory safe code and refactor it.
I do agree that ergonomics is an important consideration, but it should be optimized under the most basic constraints that a type system needs to fulfill. (Otherwise users will try it, get frustrated and use @system code.)
I assume the 'return' annotations we already have can stay and will cover quite some ground.
