Which parts in dlang don't you use and why ?

Personally i have no need for enum types, immutable is doing fine.
Auto return types i find dangerous to use.
Voldermont types.
Named initialiser.
Tuple features.
Maybe some other ?
Feature creep can make your own code unreadable.

Offcourse taste can very from person to person.

On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:

Having many ways to express the same concept makes code harder to read. This is an issue in C++, but you can combat it by creating coding norms.

In general it is better to have fewer features and instead improve metaprogramming so that missing features can be done in a library.

Also some features could be merged, like alias and enum constants.

I want to be able to support CP936, not just UTF8.

I can't use CP936. It's my pet peeve.

Hopefully we can solve the coding problem just like Python with #encoding= GBK.

On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:

There is one feature (actually a mix of features) I'd be happy not to use, but it is not possible: I call it autoreals, because it resembles somewhat the idea behind autodecoding - in both cases the compiler (or Phobos) does something automatically that you cannot avoid and sometimes causes real headache, but which you could do easily yourself if it were not done automatically): What I'm talking about is

• reals being differently implemented on different computers
• reals being internally used for computation and intermediate storage
• reals being automatically used in CTFE (and reals in CTFE might differ from the reals at runtime)

All together this ends in generic code (for example in libraries) behaving more or less like a random generator; at least it feels like this.

I would be able to cope with the first point by either not using reals at all or static if to generate separate code for every version. But together with the other two "features" reals cannot be ignored anymore. You cannot even assume a function with return type double to return a double. So to be sure to have a double, when a double is needed you need to do stuff like

double d = some_fun();
ulong tmp = *cast(ulong*) &d;
tmp ^= 12543;
/* maybe here some more ugly stuff that doesn't change the value until it is enough to trick the optimizer */
tmp ^= 12543;
d = *cast(double*) &tmp;

Even worse with CTFE, where you get values that are neither NaN, nor infinity but larger then <type>.max. And you cannot even use static if to find out which reals are used in CTFE, because CTFE might use different reals or reals on an other platform or whatever. So to be able to find out which real you use, you need to add more ugly code like

if (__ctfe)
{
    if (real.max + 1 != real.infinity && real.max + 10 - 20 < real.max)
    {
        ...
    }
    else
    {
    }
}

Finally you end up writing several hundred lines of code for something that would have fitted in one line without autoreals; probably you would prefer to write a library (using heavy amount of asm parts) with types Float and Double that is just doing what float and double are normally supposed to do.

What I really dislike about this is, that you have no means to escape from it, while the other way round it would be easy: If you really want to use reals instead of double, you could just use reals...

For a number it's best to have something you know how many bytes it takes in memory.

Knowing the number of bytes in memory is a good thing.

On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:

Well, I don't like magic constructs in the language like the type of AliasSeq you can't touch.

But the more general problem in D are not features per se, but how they are composed of.
For instance: Why no AST macros instead of string mixins, templates, mixin templates and alias?
All these forms could be special ast macros.

Structs are nice but at the same time awful to use because they are incompatible with interfaces and classes, I hope this will change to some extent, but I think it wouldn't be that smooth.

Being multi-paradigmatic seems nice at a first sight, but which paradigm should your standard library and other frameworks follow? Providing all paradigms at once make your frameworks redundant and bloated, so you just follow one which is most of the time not OOP.
This is the same problematic with custom memory containers.

I wish we would only use structs as ref/value types with the ability to box them to interfaces automatically increasing compatibility between libraries to a large extent.

On Saturday, 22 May 2021 at 13:26:38 UTC, sighoya wrote:

I think AST macros require a tiny core language and having most of the language features being implemented by macros. The D AST is not really suitable as it stands.

D is a bit like C++ in this regard, there might be a minimal core language that could be distilled from it, but it would take a D3 full breaking change to get there, so it won't happen.

You could probably expose classes in a form that is compatible with structs, but that would expose implementation details and give implementors less freedom.