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
}
-Steve
More information about the Digitalmars-d
mailing list