DIP 1028---Make @safe the Default---Community Review Round 1

[Steven Schveighoffer]

On 1/2/20 6:19 AM, jmh530 wrote:
> On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review 
>> for DIP 1028, "Make @safe the Default":
>>
> 
> I believe this DIP should be not be accepted until 1) it is possible to 
> write a @safe RC type, 2) someone writes a tool that adds @system to 
> every function that is not annotated @safe or @trusted (or already 
> @system) (probably not that hard).
> 

So I spent about 3 days to try and bring a large project into the realm 
of `@safe` [1]. I'm still not done there, but it's both eminently 
possible, and satisfying to have something to show for "you can just 
mark all your stuff @safe". However, one of the biggest costs we are 
going to have for this DIP (and I 100% support this DIP), is that 
deprecations are not going to be easy. It's not always easy to take your 
well-crafted API, and make it usable in both `@safe` and `@system` code.

The two large issues I ran into (and these I think we need to have fixed 
in concurrence with this release):

1. std.variant.Variant cannot be @safe. We need a SafeVariant. I went 
with TaggedAlgebraic due to the nice generative features there.

2. Object.opXXX is NOT marked @safe. This means doing operators with 
objects (especially opEquals). In my PR, because I no longer needed to 
compare objects since I was moving away from Variant (which uses 
TypeInfo for checking runtime type), this problem kind of went away. But 
it's definitely something that is concerning.

These are likely not the only problems that will happen. And most likely 
we will see a lot of these little things crop up. The DIP should address 
not just schedules, but prerequisites for moving to the next stage of 
the process (e.g. Object must be usable with @safe before an official 
deprecation is added to the compiler).

If you read through the discussions on making MySQL safe (see the 
referenced issue report [2]), the biggest difficulty for me is if you 
need to change return types (as I did from Variant to TaggedAlgebraic). 
Now, your API needs to necessarily adjust because you can't overload 
based on return type in D. If that were possible, then the API updates 
and deprecations would be easy.

Is it even feasible to overload something like return type based on the 
context called from? i.e. if you call from a @system function, you get 
type A, if you call from a @safe function, you get type B.

-Steve

[1] https://github.com/mysql-d/mysql-native/pull/214
[2] https://github.com/mysql-d/mysql-native/issues/175