On Tuesday, 12 October 2021 at 21:38:48 UTC, Timon Gehr wrote:
> On 10/11/21 5:59 PM, Atila Neves wrote:
>> ...
>
> This is likely to be incomplete or overly abstract, but here's my approximate take:
>
>> * Worst features implemented in a non-toy language
>
> - Turing-complete constructors

Care to explain?

> - @safe `void` initialization

For what types? It doesn't compile for pointers, for instance, and I don't see why void initialising an int would be unsafe.

> - @safe extern(C) function prototypes

Instead of @trusted, you mean?

> - .init

Because?

> - separation of templates and CTFE

What would it look like if they weren't separated?

> - interaction of type qualifiers with reference types

I'd love to know what you mean by this.

On Fri, Nov 05, 2021 at 09:22:12PM +0000, victoroak via Digitalmars-d wrote:
> On Friday, 5 November 2021 at 17:02:05 UTC, Atila Neves wrote:
> > 
> > > - @safe `void` initialization
> > 
> > For what types? It doesn't compile for pointers, for instance, and I don't see why void initialising an int would be unsafe.
> > 
> > > - .init
> > 
> > Because?
> > 
> 
> Well, I can't answer for him but `void` initialization and `.init` makes it impossible to have any meaningful constraint on a type. And some types may depend on these constraints to maintain safety.
> 
> ```d
> import std.stdio;
> 
> struct LimitedInt(int min, int max)
> {
>     @disable this();
> 
>     this(int number)
>     {
>         assert(number >= min);
>         assert(number <= max);
>         _number = number;
>     }
> 
>     private int _number;
> }
> 
> void main() @safe
> {
>     LimitedInt!(1, 1000) x = void;
>     auto y = LimitedInt!(1, 1000).init;
>     writeln(x);
>     writeln(y);
> }
> ```
> 
> It's `@safe` in this example but there's no way to enforce these constraints when you have those.

@safe does not mean enforcing type constraints.  It means *memory* safety.  The above code exhibits no memory unsafety, even though constraints are violated and the output is, ostensibly, wrong because of broken constraints.


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.

On Friday, 5 November 2021 at 21:46:35 UTC, H. S. Teoh wrote:
>
> @safe does not mean enforcing type constraints.  It means *memory* safety.  The above code exhibits no memory unsafety, even though constraints are violated and the output is, ostensibly, wrong because of broken constraints.
>
>

`.init` was not mentioned as breaking `@safe` just as a bad feature and I was answering why I think it is a bad feature.

But the presence of both `.init` and @safe `void` initialization makes it way harder to write correct `@trusted` code that depends on some constraints because you can't really enforce them.

On Friday, 5 November 2021 at 21:54:27 UTC, victoroak wrote:
> On Friday, 5 November 2021 at 21:46:35 UTC, H. S. Teoh wrote:
>>
>> @safe does not mean enforcing type constraints.  It means *memory* safety.  The above code exhibits no memory unsafety, even though constraints are violated and the output is, ostensibly, wrong because of broken constraints.
>>
>>
>
> `.init` was not mentioned as breaking `@safe` just as a bad feature and I was answering why I think it is a bad feature.
>
> But the presence of both `.init` and @safe `void` initialization makes it way harder to write correct `@trusted` code that depends on some constraints because you can't really enforce them.

...which is one of the reasons we need @system variables:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1035.md