On 10/17/13 11:53 PM, Maxim Fomin wrote:
Root of the issue is that in D static type system and memory safity are separated from each other. Key idea is that having information about static type of object is not sufficient to know whether using it is memory safe or not.
This is a common approach in many languages (actually all that I know about). Clearly stuff on the stack can be attached an invisible attribute "it's on the stack!" but that doesn't go well with separate compilation.
Thanks for collecting together the situations where safety is broken. It's a bummer your posts are perpetually gloomy, but there's hope we may be able to do something about that. I'd like to make improving @safe the focus of 2.065, by fixing the implementation bugs and by looking at the more complicated cases, too.
So, what actually D has, is a feature, which does not really prevents memory errors, but bans some language features and criteria for banning features is wrong: some legal cases are banned, some cases which should be blocked, are not. If you are really interested in safety you can put our attention to languages like C#. D doesn't provide such facilities.
It's a given that safety will disallow constructs that are safe upon inspection but the type system is unable to prove correct. This is the case for all languages, C# included.
Andrei
