On 10/11/21 1:35 PM, russhy wrote:
> On Monday, 11 October 2021 at 16:12:59 UTC, FeepingCreature wrote:
>> On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:
>> Sumtypes should be built-in, and they should implicitly construct from its member types.
> 
> I 100% agree with you

100%. I am really loving Ilya's `mir.algebraic` for my sumtype needs:

http://mir-core.libmir.org/mir_algebraic.html

> Same for Nullable/Optional in my opinion

Likewise mir algebraic has Nullable. But what it (and D overall as a builtin) is really missing is Result type (with Ok and Err tags) -- will be eagerly checking out Chaloupka's `expected` package soon.

PS:

>> But I'm actually convinced that the worst thing is the lack of
>> implicit construction for sumtypes. Because when you try to actually
>> use sumtypes, you end up with stuff like
>> `Nullable!MySumType(MySumType(MemberType("Hello World")))`.

https://run.dlang.io/is/XUtxwm  :)

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:
> * Worst features implemented in a non-toy language

Well not a feature per se, but the idea that number of keywords or number of features really matters.

People argue you should remove things just to remove things. But this often just moves the inherent difficulty of programming from the language to the code.

You don't wanna go too far with it, of course, but there is simple metric here.

> * Worst features (in your opinion) in D

The whole int promotion and casting mess. Two ideas that sound fine in isolation but make things just nearly unusable in real life when combined.

> * Features you'd like to see in D

Explicit implicit construction. Minimally on return values, but also on function arguments would be nice.

Note the constructor called implicitly must be explicitly labeled implicit.

On Monday, 11 October 2021 at 20:51:13 UTC, Adam D Ruppe wrote:
> You don't wanna go too far with it, of course, but there is simple metric here.

err there is NO simple metric here.

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

Fix formating

On Monday, 11 October 2021 at 20:41:33 UTC, James Blachly wrote:
> Likewise mir algebraic has Nullable. But what it (and D overall as a builtin) is really missing is Result type (with Ok and Err tags) -- will be eagerly checking out Chaloupka's `expected` package soon.

The real missing piece here IMO is DIP 1038 [1]. Once it is fully accepted and implemented, defining a Result type will be trivial.

[1] https://github.com/dlang/DIPs/blob/b30b94d40bd76b513d31509f8e40f7c38d111929/DIPs/DIP1038.md

On Monday, 11 October 2021 at 21:22:29 UTC, RazvanN wrote:
> On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:
>> I'm brainstorming about what I'll talk about at DConf, and during a conversation with Walter I thought it might be cool to talk about:
>>
>> * Worst features implemented in a non-toy language
>> * Worst features (in your opinion) in D
>> * Features you'd like to see in D
>>
>> Ideas? Examples?
>>
>> Thanks!
>
> Worst features:
>
> - ability to define alias this on class objects
Yes! This right here is the worst feature as it is a source of headaches when it comes to compiler bugs.
We can replace this that introduce new features for the classes such as the much needed properties overhaul that is still WIP. https://github.com/12345swordy/DIPs/blob/properties/DIPs/%40get%20%40set%20.md
and introduce default interface implementation.

Before you ask, No, using string mixin or templates for implementing interfaces  is NOT considered to be a default interface implementation.
See here: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/default-interface-methods.md


- Alex

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

it is not GC phobia, i use the GC for some projects and i'm ok with it

it just is when you don't need it, you need to be careful with @nogc, and there is no way to globally enforce a @nogc behavior


these issues would be solved if GC was introduced as a library, or as a toggleable feature without having to resort to -betterC

that's one strength D has over C#, being able to not rely on the GC, even thought i don't like the comparison myself, D still is a system language

Countless hours wasted working aroung GC limitations with Unity (C# game engine)

If they had went with D, they wouldn't have to be this careful with their language! an area D should have won market share (engine code + scripting code at the same time!)