• Embedding js in an html document.

• adding objects to an existing language

• nontrivial namespace collisions when importing std

• int promotion

• verbose enums

• contracts and all the cute ideas expanding a template header to affect the matching

• sword of damocles of safe by default or who knows what koolaid being enabled one day

• base types having fake opoverloads ( 2.opCmp(3) == 1)

• universal function call syntax being universal (let me define a function in the same scope that I ufcs it)

• a nice overload for _____TrAiTs(compiles,mixin("foo.bar"))

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

Attribute soup

1. inconsistent - some with leading '@' & some without
   all attributes should start with @. This will help to reduce number of key/reserved words

2. need re-declare attributes for aggregated types (struct/class) even if it is already declared on module level

3. All attributes should be non-negative word and introduce negation
   Ex: @gc:
   @nogc become @!gc

Simple example
module x;

@!gc @!throw:

void funcionDoNotThrow() {}

// Reverse the above module attribute setting
void functionThrow() @throw {}

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

__traits should've died years ago. Its continued existence shows some level of paralysis.

The decision to build languages as monolithic lumps of specification, then a compiler, also phased in it's design, while simple, I think will be a detriment in the post Moore's law age, as it makes it very irritating to use and understand the full muscle of the optimizer in the right places - and fundamentally limits the potential of the/a language in a now post-heterogenous world: you should he able to compile for a GPU as part of the compiler a la a trait (This is an acceptable use of the keyword, reflection is not).

I think D's worst feature is really a human tendency to avoid language solutions for things. sumtype is a good library, but it should be core language for example. Typecons.tuple is even less marginal.

My dream feature for D is a combination of static analysis, formal verification, and some brand of mutation testing guided by them (When we spoke about it last, Atila, you convinced me but it would take someone more dedicated than I to implement it)

On Monday, 11 October 2021 at 21:38:17 UTC, russhy wrote:

try a @nogc main() function. Yes this doesn't handle module global and thread constructors, but its global enough.

On Monday, 11 October 2021 at 22:01:34 UTC, max haughton wrote:

I think a big problem from an exploratory perspective is that that is essentially
impossible in a one-file-at-a-time compilation world and that to explore the space
of possibilities far more people than the D community has.
This afflicts
C, C++, OpenCL, IPSC (1 file at a time, lack of anything other than immediate local context)
CUDA, SYCL, (one file at a time, but lets do it twice! one for the host, one for the device)
OpenMP (where premature outlining for device offloading has caused massive missed optimisation opportunity)

in a static slice of time, yes. As a feature to easily add language functionality, without taking up more keywords, with minimal "feature space", its indispensable. It does however show that a program needs an API to the compiler during compilation. Is there a better way to do this? core.reflect and core.codegen seem like good steps.

On Monday, 11 October 2021 at 21:41:45 UTC, monkyyy wrote:

Are these still around? This compiles now:

unittest {
    import std;

    assert(!std.ascii.isAlpha('5'));
}

unittest {
    import std;
    import std.ascii : isAlpha;

    assert(isAlpha('X'));
    assert(std.uni.isAlpha('X'));
}

On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:

real, specifically fp80 real. Its slow, its almost always unintentional and phobos tends to use it way more than it should.