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

Steven Schveighoffer schveiguy at gmail.com
Thu Jan 16 15:55:50 UTC 2020

On 1/15/20 1:26 PM, Walter Bright wrote:
> On 1/13/2020 12:37 PM, Steven Schveighoffer wrote:
>> How does the DIP affect interfaces and class virtual functions? 
>> Especially interfaces without marking will be a potential problem as 
>> there will be no errors on a @system interface stub which now is 
>> tagged with @safe but has no implementation to complain about. But an 
>> implementing class would fail to compile potentially (and might be in 
>> a separate project). This is a fundamental API difference that's not 
>> easy to account for. The DIP should address that process.
> Unmarked introducing functions (such as the ones in Object) will have to 
> be marked as @system. Later on we can mark them @safe as a separate 
> transition issue.

This needs at the very least a section of the DIP. I would recommend 
some kind of deprecation period where people are told to mark their 
abstract and interface functions @system or @safe (and might even be 
worth making it an error for a short time to nudge them even further). 
Otherwise, you will have projects that compile just fine, but silently 
change their API when the DIP becomes the default.

>> I noticed that even templated class member functions are currently 
>> @system unless tagged @safe (for good reason). So there's going to be 
>> a lot of code out there like this.
> Templated functions get their safety inferred if not explicitly marked.

Sorry, I could have worded this better. Member functions of templated 
classes (i.e. virtual functions) are not inferred like they are for structs:

class C(T)
   T foo() { return T.init; }

struct S(T)
   T foo() { return T.init; }

void main() @safe
    S!int s;
    assert(s.foo == 0); // OK, S.foo inferred @safe
    auto c = new C!int;
    assert(c.foo == 0); // error, cannot call @system function C.foo


More information about the Digitalmars-d mailing list