On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

• Identifier-delimited string literals (https://dlang.org/dips/1026)
• Typesafe variadic arguments (https://github.com/dlang/dmd/pull/11124)
• lazy
• alias this inside a class
• old alias type identifier notation instead of alias identifier = type
• extern(C++, identifier) (Mathias Lang did not manage to convince Walter at DConf 2022 though)
• __FUNCTION__ and __PRETTY_FUNCTION__
• this(this) (postblit is superseded by copy constructor, though there are still a lot of bugs)
• Redundant __traits such as isFloating, isIntegral, isScalar, isStaticArray, isUnsigned

Not 100% sure about each one, but these are my candidates

ImportC, betterC, @nogc, nothrow, @safe, @property, nested comments, delimited strings, case labels, new alias syntax.

The new alias syntax works well for simple symbol alias, but feels less natural for more complex types so I actually went to the old syntax for all my aliases.

On Thursday, 15 September 2022 at 13:43:01 UTC, Dennis wrote:

I would be all for this if we could get something like opImplCast() which would basically be the same as opCast() but without requiring cast.

I believe the operator overloads must be static for it to work properly with ex. Foo foo = 100;.

Foo foo = 100; // Would trigger static void opImplCast(T)(T value) where T is int.
int a = foo; // Would trigger ex. static T opImplCast(T)(Foo instance) where T is int

You should of course be able to be explicit about types like int opImplCast(Foo instance);

On Thursday, 15 September 2022 at 14:10:07 UTC, bauss wrote:

Foo foo = 100; // Would trigger static void opImplCast(T)(T value) where T is int.

Minor typo here, it should be:

Foo foo = 100; // Would trigger static Foo opImplCast(T)(T value) where T is int.

On Thursday, 15 September 2022 at 12:20:51 UTC, IGotD- wrote:

Global import is not what i want, it's actually a very bad idea, it encourages poor practices, it'll lead to poor build speed and bloated global scope

What i want is modernizing the builtin types instead of keeping imaginary english names that originate from C era

On Thursday, 15 September 2022 at 13:43:01 UTC, Dennis wrote:

The non-array forms should be deprecated. What is (int i...) even useful for?

With or without Walter's idea of a delegate parameter returning T automatically wrapping an argument of type T into a delegate? That doesn't seem to be implemented:

implicitlazy.d(10): Error: function implicitlazy.f(int delegate() d) is not callable using argument types (int)

It's fine if the class is final.

+1

Are there traits for these instead?

The docs have:
WARNING: The postblit is considered legacy and is not recommended for new code

So we could probably add it to the deprecate.dd list for future deprecation when copy ctor is robust enough.

Redundant because of Phobos? Isn't that going to cause lots of template instantiations?

On Thursday, 15 September 2022 at 17:56:57 UTC, Nick Treleaven wrote:

For my part, without.

I think there's __traits(parent, {}) inside a function body.

On Thursday, 15 September 2022 at 19:19:13 UTC, Dennis wrote:

Why on this god-forsaken piece of rock do we need this abomination while we could easily have a self, __self, scope, __scope, __traits(scope) or whatever to refer to the current scope?