On 14.04.20 22:14, Walter Bright wrote:
> On 4/14/2020 10:16 AM, Steven Schveighoffer wrote:
>> That being said, I agree with the simple case of returning a pointer from a stack variable directly from a function being disallowed. That also can be easily worked around, which should probably be required, but is never correct anyway.
> 
> Oh, it can be correct, when one wants to examine the stack pointer value. I've used it for that purpose myself. (Examining the stack pointer is valuable when determining whether other pointers are pointing into the stack or not.)
> 
> As I replied to Timon, you're drawing a subjective (not objective) line at what is acceptable or not.
> 

It depends on the language being consistent. If the language says what you are doing is guaranteed to lead to UB, a diagnostic is fine.

If the spec says this is a supported use case that is guaranteed to work across all D compilers, the story is a bit different.

The spec is not formal enough to figure out which of those is the case. Does the spec really mandate an implementation to put the program stack at a continuous range of addresses? Are dangling pointers guaranteed to compare correctly to valid pointers? etc.

On 15.04.20 08:12, Walter Bright wrote:
>>
> 
> Ironically, I argue for consistency with "safe by default"

You really don't. Allowing memory corruption to be annotated @safe is inconsistent with the meaning of @safe.

On 15.04.20 17:11, Steven Schveighoffer wrote:
> 
> If we didn't have existing code that's extern(C) then the debate would be entirely different. It would be a new thing, and it would be a legitimate position to have extern(C) prototypes safe by default.

No.

On 15.04.20 17:11, Steven Schveighoffer wrote:
> 
> I'll note that I proposed an alteration that has received zero responses that I think would solve all those concerns:
> 
> https://forum.dlang.org/post/r6kvm4$1vq5$1@digitalmars.com

I had answered to that with the example of @safe functions with inconsistent return values. I think you'd need to do some more mangling to make this acceptable.

On 4/15/2020 1:14 AM, Max Samukha wrote:
> A good reference point would be C. If it is allowed in C, it should be allowed in @system D. If I put @system on a D function, i tell the compiler not to bug me with incorrect assumptions about my code's safety.

What matters is having a way to get things done, not any way.

On 4/15/2020 5:01 AM, Adam D. Ruppe wrote:
> I'm asking for confidence in D's future.

If you've got an issue in the future that you need help with, that's what we're here for.

We're not going to make D @system useless.

On Thursday, 16 April 2020 at 04:49:08 UTC, Walter Bright wrote:
> On 4/15/2020 1:14 AM, Max Samukha wrote:
>> A good reference point would be C. If it is allowed in C, it should be allowed in @system D. If I put @system on a D function, i tell the compiler not to bug me with incorrect assumptions about my code's safety.
>
> What matters is having a way to get things done, not any way.

Did I propose "any way"? You said that there were no objective criteria for what checks to perform. I proposed C as a reference, which basically means "unsafe enough to rule out complaints such as Adam's". If you are going to make @safe the default, it makes sense to reduce the restrictions on @system, not the other way round.