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
>
> - unsound type system
> - undefined behavior for categories of errors other than memory corruption
> - inappropriately nondeterministic semantics
> - mutable aliasing by default (mutability is fine, aliasing is the issue)
> - pointer arithmetic without appropriate type system support
> - imprecise type system (>40 years behind state of the art)
> - non-orthogonal language definition
> - null pointers without appropriate type system support
> - Turing-complete constructors

Please mention the language for each point. I think that "inappropriately nondeterministic semantics" can be JS.

On Tuesday, 12 October 2021 at 20:29:32 UTC, Paul Backus wrote:
> On Tuesday, 12 October 2021 at 19:41:57 UTC, H. S. Teoh wrote:
>> - C++ concepts-like feature of specifying the expected interface of a
>>   template parameter.
>>    - Yes, sig constraints fit the bill, kinda-sorta.  But it leads to
>>      poor, unhelpful error messages.  Yes, this can be fixed by using
>>      static if, pragma(msg), etc., but this requires a lot of extra work
>>      on the part of the user which should have been handled by the
>>      language.
>>    - Yes, there's a dub package that kinda-sorta does this. But again,
>>      this is something that should have been done by the language.
>
> You can get about 90% of the way to better constraint errors with existing language features:
>
>     struct Check
>     {
>         bool passed;
>         string message;
>
>         T opCast(T : bool)() { return passed; }
>     }
>
>     enum hasFoo(T) =
>         Check(
>         	__traits(hasMember, T, "foo"),
>             "`" ~ T.stringof ~ "` must have a member named `foo`"
>         );
>
>     struct Pass { int foo; }
>     struct Fail { int bar; }
>
>     // Can check with static assert
>     static assert(hasFoo!Pass);
>     static assert(!hasFoo!Fail);
>
>     // Works in constraints
>     auto getFoo(T)(T input)
>         if (hasFoo!T)
>     {
>         return input.foo;
>     }
>
>     static assert(__traits(compiles, Pass().getFoo));
>     static assert(!__traits(compiles, Fail().getFoo));
>
>     // Can check error message
>     pragma(msg, hasFoo!Fail.message);
>
> The only thing missing is a way to get the compiler to print out your custom message, instead of (or in addition to) the default "must satisfy `hasFoo!T`" message.
>
> I plan to write a DIP for this as soon as I am done with @nodiscard.

templates doesn't work with DCD/DSymbol because it doesn't do semantic analysis, so that kind of features is impossible implement for tooling right now..


this is why things like tagged union (sumtype) and multiple return type should be implemented as language features, that way it is easier to parse (on top of other benefits)

please push for language feature! your work on sumtype was great, but there is much more to gain from upgrading it as a language feature

On Wednesday, 13 October 2021 at 01:56:19 UTC, russhy wrote:
> this is why things like tagged union (sumtype) and multiple return type should be implemented as language features, that way it is easier to parse (on top of other benefits)
>
> please push for language feature! your work on sumtype was great, but there is much more to gain from upgrading it as a language feature

If anyone wants to work on a DIP and implementation for built-in sum types, they will have my full support. Unfortunately, I do not have the time or the skills necessary to lead such a project myself.

On Wednesday, 13 October 2021 at 02:39:47 UTC, Paul Backus wrote:
> On Wednesday, 13 October 2021 at 01:56:19 UTC, russhy wrote:
>> this is why things like tagged union (sumtype) and multiple return type should be implemented as language features, that way it is easier to parse (on top of other benefits)
>>
>> please push for language feature! your work on sumtype was great, but there is much more to gain from upgrading it as a language feature
>
> If anyone wants to work on a DIP and implementation for built-in sum types, they will have my full support. Unfortunately, I do not have the time or the skills necessary to lead such a project myself.

I think such a feature would benefit from having tuple syntax and semantics done first. Timon did have a DIP for tuples.

On Wednesday, 13 October 2021 at 01:56:06 UTC, russhy wrote:
> On Monday, 11 October 2021 at 20:48:47 UTC, 12345swordy wrote:
>> On Monday, 11 October 2021 at 18:27:29 UTC, russhy wrote:
>>>> Worst features implemented in a non-toy language
>>>     - GC as a feature
>> This GC phobia is hurting the d language.
>>> - class (reference type)
>> WHY!?
>>
>> -Alex
>
>
> because, as other said, it is hard to differentiate from struct (values), you always have to check the symbol signature, wich is just annoying

It is not an issue if you have a functional IDE that does the heavy lifting for you. This isn't a language issue here.

You are doing something very wrong if you find yourself typing
>void pass(Mytype* type) {}

where Mytype is a class. This is not c++ here.

-Alex

On 10/12/21 1:29 AM, surlymoor wrote:
> I just want to be able to have a returned value be implicitly wrapped if its type is part of the `SumType` returned by the function.
> 
> ```d
> // -preview=shortenedMethods is awesome
> SumType!(int, string) div(int a, int b) => b != 0 ? a : "Divisor is zero";
> ```

Hear, hear