On 6/8/2022 12:18 PM, claptrap wrote:
> Isn't the DIP process supposed to catch these sorts of things?

It does catch those sorts of things. But the checks do not happen for @system code, and the code snippet is @system code.

I submitted a DIP to make @safe the default (rather than @system) but it was rejected. This is the result.

On 6/8/2022 9:22 AM, Steven Schveighoffer wrote:
> The reality is that people are (mostly) only dealing with the existing implementation, until it stops working. But to silently break it, and silently break it with *memory corruption* does not seem an appropriate penalty.

The point of @system code is people can do whatever they want.

The answer is to make @safe the default. But that DIP was rejected.

On 6/8/2022 11:32 AM, Timon Gehr wrote:
> Your code is literally calling this function:
> 
> ```d
> string foo(scope string s){ return s; }
> ```
> 
> This causes UB, therefore you can't blame the compiler frontend here. I guess you can complain about the language specification, but what else are you expecting `scope` to do? There could be some more diagnostics I guess, like for the case where a stack variable is escaped directly.

Annotating foo() with @scope yields:

    test6.d(5): Deprecation: scope variable `s` may not be returned

On 6/8/2022 12:33 PM, 12345swordy wrote:
> You shouldn't have to mark your functions safe to prevent shooting yourself in the foot.

I agree, but the DIP to make functions @safe by default was rejected.

On 6/8/2022 12:02 PM, Steven Schveighoffer wrote:
> But for some reason,

The reason is it's @system code, where it's on the programmer.

@safe layers on a vast smorgasbord of extra checking.

On 6/8/2022 12:59 PM, Mathias LANG wrote:
> I have argued with Walter for a long time that having `scope` enforced only in `@safe` code was a grave mistake, and would be extremely confusing. It would have avoided this situation.

The idea is that @safe should be the default and so @system code would be rare and would stick out like a sore thumb.

In @system code, maintaining the invariants of the function parameters is entirely up to the programmer.

On 6/8/2022 1:49 PM, Dukc wrote:
> The philosophy is to force to be explicit in the simplest cases that are almost always errors, but not trying to seriously prevent the escape.

Yup. That simple check is also what the original D1 compiler did (and what C and C++ compilers do). Making `scope` work to plug all the holes was a vast increase in technology.

`scope` engenders a lot of complaints, too, because it is ruthless and demanding and annoys people with the annotations.

Fortunately, D gives you a choice - use @safe and the compiler will kick in and demand that the code stays in its lane. Or use @system, and do whatevs, and the onus is on you to be careful with that saw as the blade guards are removed.

On 6/8/2022 3:03 PM, Dukc wrote:
> In fact, I'm surprised the compiler does not siletly add `return`.
D does not do attribute inference for regular functions, because of the risk of a mismatch between a function's definition (with body) and a declaration (without body) of the same function.

On Wed, Jun 08, 2022 at 04:21:33PM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/8/2022 12:18 PM, claptrap wrote:
> > Isn't the DIP process supposed to catch these sorts of things?
> 
> It does catch those sorts of things. But the checks do not happen for @system code, and the code snippet is @system code.
> 
> I submitted a DIP to make @safe the default (rather than @system) but it was rejected. This is the result.

I was in favor of the @safe by default DIP. The only amendment I wanted was that @safe by default would only apply to extern(D) functions, which IIRC just about everyone else also wanted.  IIRC, you were the only one who opposed this amendment, which then caused the majority to reject the DIP.

Had you accepted the compromise then, we would already have @safe by default today.  So it seems a bit incongruous to now place blame on the DIP being rejected, as though everyone flatly rejected the whole idea. Such was not the case. A compromise *could* have been reached.

(And for the record, if the amended DIP were to be submitted today, I'd vote in favor. @safe by default is a good thing to have -- except on extern(C) interfaces to C code, which by definition is un-@safe -- the most it can be is @trusted, and I'm sure nobody wants @trusted by default.)


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".

On 09/06/2022 11:47 AM, H. S. Teoh wrote:
> (And for the record, if the amended DIP were to be submitted today, I'd
> vote in favor. @safe by default is a good thing to have -- except on
> extern(C) interfaces to C code, which by definition is un-@safe -- the
> most it can be is @trusted, and I'm sure nobody wants @trusted by
> default.)

I'm in favor of turning on attribute inference instead.

It'll do the same thing (effectively) while also covering things like DIP1000's attributes too.

Why not try it and see how much breakage it would really cause? If hardly anything lets just do it without a DIP.