On Wednesday, 15 December 2021 at 08:27:25 UTC, RazvanN wrote:
> I would vote for having a dip that would somehow make it easy to express the intent that you want to avoid destruction for a specific object.

What about permitting 'union { S s; }' at function scope?  It is a slightly odd syntax; but it it consistent and, well, if you are trying to void initialise or bypass deconstruction, you are already plumbing dirty parts of the language.

On Wednesday, 15 December 2021 at 08:27:25 UTC, RazvanN wrote:
> My perspective is that currently you have an easy way to bypass destruction but you need to do the union trick to bypass destruction. I would vote for having a dip that would somehow make it easy to express the intent that you want to avoid destruction for a specific object.

(In particular, I agree with the other folks you cite that void-initialisation should not bypass destruction.  To me, void-initialisation is not a way of _bypassing_ construction, but is an _optimization_ you can apply when the compiler tried to construct some object more than once.

But I agree that it should be possible to bypass destruction.)

On 12/14/2021 7:51 AM, Atila Neves wrote:
> On Tuesday, 14 December 2021 at 12:14:52 UTC, Tejas wrote:
>> Sorry for reviving this thread, was just sifting through...
>> The following code also outputs `dtor!`, unfortunately :(
>>
>> ```d
>>
>> import std.stdio:writeln;
>>
>> struct S{
>>     @disable this();
>>     ~this(){
>>         writeln("dtor!");
>>     }
>> }
>>
>> void main(){
>>     S s = void;
>> }
>>
>> ```
>>
>> Compiler :
>> LDC - the LLVM D compiler (1.25.0):
>>   based on DMD v2.095.1 and LLVM 11.1.0
> 
> Is there an issue for this?

Should there be? Using void initialization means it's up to the user to initialize it properly before use.

On 12/14/2021 4:51 AM, Stanislav Blinov wrote:
>> That's what I did after reading your message, with the bonus of slapping @safe on `S.__dtor` as well ;)
>>
>> ```d
>> import std.stdio:writeln;
>>
>> struct S{
>>     @disable this();
>>     ~this()@safe/*now @safe*/{
>>         writeln("dtor!");
>>     }
>> }
>>
>> void main()@safe/* now @safe*/{
>>     S s = void;
>> }
>> ```
>>
>> It defeated `@safe` ;_;
> 
> Oh, right, S doesn't have any pointers. @safe only cares about void-initializing those.

@safe is about memory safety. The example code is not memory unsafe.

On 12/14/2021 6:05 AM, Paul Backus wrote:
> If you can find a way to actually cause UB in @safe code, you should post it on the bug tracker. However, this example does not qualify.

UB is not quite right. It's about memory unsafety. Another way to illustrate this is:

  import std.stdio;

  @safe void main() {
    int x = void;
    writeln(x);
  }

will print garbage, but it is not unsafe.

On Wednesday, 15 December 2021 at 10:17:49 UTC, Walter Bright wrote:
> On 12/14/2021 6:05 AM, Paul Backus wrote:
>> If you can find a way to actually cause UB in @safe code, you should post it on the bug tracker. However, this example does not qualify.
>
> UB is not quite right. It's about memory unsafety. Another way to illustrate this is:
>
>   import std.stdio;
>
>   @safe void main() {
>     int x = void;
>     writeln(x);
>   }
>
> will print garbage, but it is not unsafe.

A violation of memory unsafety is either (a) UB or (b) behavior that is not UB itself, but allows UB to occur in @safe code (i.e., it violates one of the language's safety invariants). So if you've found a memory safety violation, it is always possible to use it to create an example of UB in @safe code.

The above example is neither memory-unsafe nor UB. According to the spec, it prints an implementation-defined value of type int.