ref is unsafe

[Maxim Fomin]

On Wednesday, 2 January 2013 at 19:37:51 UTC, Jonathan M Davis 
wrote:
> On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
>> I think it should not be fixed, but probably compiler may issue
>> warning at some circumstances when it can realize this 
>> situation.
>
> It's a hole in @safe. It must be fixed. That's not even vaguely 
> up for
> discussion. The question is _how_ to fix it. Ideally, it would 
> be fixed in a way
> that limits how much more code has to become @system.

I argue that @safity can be easily broken (not only by example I 
provided) and there is no way to fix all holes because D is a 
system language and provides access to low-level features. @Safe 
is good to warn about (not prevent from) doing something wrong 
but it cannot stop from all safety breakages. Nor it should make 
plenty of code uncompilable just because some trick may cause 
segfault. Actually many things can cause segfaults, but they are 
not intended to be fixed.

>> By the way, there is another issue with ref -
>> http://dpaste.dzfl.pl/928767a9 which was discussed several 
>> month
>> ago minimum. Do you think this should be also fixed?
>
> It's not a bug. You're dereferencing a null pointer, so you get 
> a segfault.
> There's nothing surprising there.

Consider broaden example when function takes pointer, does not 
check for null and passes later reference. This is similar to 
double ref trick.

Consider another example:

---main.d-----
extern(C) void foo() @safe pure nothrow;

void notThatSafe () @safe pure nothrow
{
	foo();
}

void main()
{
	notThatSafe();
}

----foo.d---
extern(C) void foo()
{
	throw new Exception("");
}
----------

So, pure, nothrow and safe are effectively stripped off by 
separate compilation.

Another example, which does not require separate file: 
http://dpaste.dzfl.pl/f968cab5

>> I don't take into D's @safity seriously because it can be 
>> easily
>> hacked.
>
> It's fine if you don't care about it, but as the maintainers of 
> the language
> and standard library, we have to take it seriously. Regardless 
> of the
> likelihood of there being a bug caused by this, it breaks 
> @safe, so it must be
> fixed, even if that means simply making all functions which 
> both accept by ref
> and return by ref @system. But that's very undesirable, because 
> it will lead
> to too much code being considered @system even when it's 
> perfectly safe. Hence
> why this is being discussed.
>
> - Jonathan M Davis

Again, I argue that D is a system language and there are many 
possibilities to break @safity. Although fixing holes does make 
sense in general, it does not make sense fixing obvious issues so 
that plenty of code becomes uncompilable and @safity usage 
becomes very annoying.