Walter Bright:
http://wiki.dlang.org/DIP60
Given the current strong constraints in the directions of D
design, I like it.
But in DIPs I suggest to also write a list of the advantages of a
proposal, and a list of all the disadvantages.
In this ER I suggested a @noheap, that is meant to also forbid
the C memory allocation functions:
https://issues.dlang.org/show_bug.cgi?id=5219
But I guess there is no reliable way to catch those function
calls too?
If the discussion is against @noheap then I'll close that ER as
obsolete.
With @nogc D has most of the basic function effects covered. One
missing effect that D is not yet putting under control is
nontermination; to annotate functions that can not loop forever
and never return (like a function with an infinite loop inside,
etc). But for the kind of programs written in D, I presume this
effect is not yet important enough to deserve an annotation like
@terminates.
There is a language studied by Microsoft that faces the problem
of effects algebra in a more discipled and high-level way. I
don't know how much this can help D at its current development
stage:
http://research.microsoft.com/en-us/projects/koka/
But in general reading research papers is useful to get in a good
mindframe.
In Koka language the functions that can not terminate are
annotated with "div", that means "divergence". But Koka has a
good effect inference.
Bye,
bearophile
