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

Everything to do with header files.

Autodecoding. Autodecoding. Autodecoding.

Mutable by default.

Template errors. (esp. template instance func(T) where T = string cannot be instantiated with T = string, or something along those lines, really, really, frustrates me)

Inconsistent built-in property naming. (As a bonus: historical baggage)

A fear of language solutions because of reasons, leading to annoying issues like std.sumtype being a PITA to debug sometimes due to bad error messages it can't really do anything about.

alias this

abc => { return 123; } should not be returning a function that returns a function.

Language support for complex types:

• sumtype and/or tagged unions. esp. in regards to pattern matching

• optional types.

• Maybe even a result/value_or_error type.

ProtoObject

Taken from C#: Having to specify ref and out parameters at point of usage, not just at definition.

Being able to specify new/experimental functionality per-module, a.l.a nullable syntax in C#.

Being able to match structs against an interface or other such construct. As a language feature since a template version I can foresee eating my CPU.

Allocators being better integrated with the language/phobos.

Standard, de-facto interface/library/whatever for things like logging, databases, etc.

Object initialisers: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/how-to-initialize-objects-by-using-an-object-initializer

And most importantly, a plan for D's future and development, because personally I have 0 idea where D is trying to go now, what it's trying to be, who it tries to please, etc. What is our vision? What are our goals and ambitions for the language?

I know it's basically completely infeasible but it's a fun thought experiment to think about what a "D3" could be like. Learning from the warts of the current language, removing historical issues, just a complete redesign whilst still being D.

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

What I want to change:
Hope to support GBK, such as Python: # encoding GBK, etc.
I hope ,can directly use the standard library without 'GC'.
I hope ,can also use <> as template parameter ,as !() more literal.
I hope ,can use... like 'C++'.
Hopefully, we can enhance 'betterC' or reduce 'GC', so that we can make good use of the 'standard library' or 'various advanced functions'
I also hope that'd has asimple, direct and easy to use GUILibrary of hdpi support.GUIis too important.
I hope there are also concept constraints in in 'd' like in C++.
I hope that the d community can change the default attribute. It is better to provide a tool for users to change their code.
Be able to list important libraries separately and explain their purpose briefly.
I hope we can collect more good articles in the forum into Wiki and other places. We should make good use of the excellent posts of people in the forum
I hope we can pay attention to Chinese users, because Chinese people use d too little.
I have translated many d's articles. I hope to give me some links so that the Chinese can also find d's article, so as not to always say that there are too few Chinese documents.
At present, this is what I can think of , that's all.

On Tuesday, 12 October 2021 at 03:17:08 UTC, SealabJaster wrote:

https://dlang.org/changelog/2.098.0.html#ambiguous-lambda

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.

// -preview=shortenedMethods is awesome
SumType!(int, string) div(int a, int b) => b != 0 ? a : "Divisor is zero";

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

• Null terminated strings without length validation

• No bounds checking by default

• Implicit conversions between enumerations and numeric types

• Lack on any sort of namespacing mechanism

• Use of explicit pointers for out parameters

• inconsistent tag soup, e.g. @safe vs pure, and the amount that almost feels like coding with Spring annotations

• the __ prefixes for some runtime stuff like __traits

• chasing the next computing fad while trying to find out the target audience

• basically all the WIP stuff actually finalized before anything new gets started

• safe by default (well I can still dream, until then @safe: at the top of each module)

• a richer ecosystem, C++, Java and C# aren't the same ones as when Andrei's book got published.

On Tuesday, 12 October 2021 at 03:17:08 UTC, SealabJaster wrote:

I agree with this so much, like why couldn't it have been made so you had to be explicit if you wanted to return a function? Like:

abc => &{ return 123; }

Usage of unsigned integers as positive numbers.
cf. dotnet uses signed integers and the sky doesn't fall (it's 32-bit int most of the time even). Granted some C and posix functions use signed integers when they need to return -1 sentinel value. Recently I ported an oldish program to 64 bits, naturally it used narrowing conversions everywhere, but it was mostly signed integers, those aren't very sensitive to narrowing and extension. But the program crashed; when I looked at the cause, it was STL's string::find method returning unsigned integer even though it returns a sentinel value string::npos when the searched string isn't found, and the program there converted the returned value to uint, but then string::npos!=cast(uint)string::npos - unsigned integers are sensitive to extensions.

On 10/12/21 2:14 AM, bauss wrote:

Just FYI, the abc => {} syntax is just recently deprecated.

https://dlang.org/changelog/2.098.0.html#ambiguous-lambda

-Steve

On Tuesday, 12 October 2021 at 11:39:56 UTC, Steven Schveighoffer wrote:

Yeah, but I would rather that it was still allowed and that the semantics just changed.

But obviously for good reason that isn't happening since it would break existing code.

On 10/12/21 8:42 AM, bauss wrote:

What would you change it to?

(abc) {return 123; } already works. If you need to return a delegate, then abc => () { return 123; } works. We don't need 10 names for different kinds of snow.

-Steve