What features of D you would not miss?

[Luhrel]

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:
> What features could be removed from D if it were up to you? 
> Please consider the breakage that would result from the 
> removal, don't settle on thinking what shouldn't have been 
> added in the first place.

IMO, some function's attributes should be removed (honestly, they 
just spoil my view when coding) :
- `@nogc` : I would love a Rust-style (dip1000 ?) "automatic 
free" system, or even better, we could implement a way to decide 
how the memory is managed :
   1. Free the memory (call `free()`) once the pointer's lifetime 
has ended (Rust's style)
   2. Do not free memory at all (DMD's compiler style), the 
pointer is added to the GC's list. Like that we can manually call 
`GC.free()` when we want to.
   3. Reuse memory : instead of calling `free()`, store the type 
and the pointer a list, and reuse the pointer if a `new` class of 
the same type is created. ([Zink's 
style](https://www.supergoodcode.com/SP33D/) ?)
- `@safe` : Should be the default
- `@system` & `@trusted` : I would entirely remove them, 'cause 
currently I just add `@trusted` when I want to call an unsafe 
function from a `@safe` function (mostly when it's an external C 
function). (Maybe I just don't see the goal of these attributes.)

I would also remove `wchar` and `dchar` (and [`d`/`w`]`string`), 
and go full Unicode for the `char` type, like in Rust. However, 
this would be a little challenging when slicing :
  1. Panic when slicing in the "middle" of a character (Rust does 
it this way)
  2. Throw an Exception
  3. Change `char` size to 4 bytes, so "`char` = `dchar`" by 
default

Also, I won't miss any implementation defined feature.

But obviously, these are ideas and removing any of these will 
break people's code.

----

My answer to other people's points of view :

On Thursday, 15 September 2022 at 09:11:15 UTC, Dukc wrote:
> - All the stuff that is deprecated already, according to the 
> removal schelude.
>
> - `@live`. It's a good experimental concept for a future DIP to 
> build on, but does not currently justify it's complexity in a 
> real project.
>
+2

> - `@property`, as said in another thread. well maybe not 
> removed, but changed to a no-op. With a deprecation period, 
> warnings given for uses that depend on current semantics of it.
>
Don't remove it, improve it ! It would be very useful when 
creating a class which internally calls some C functions.

> - `lazy`, if DIP1033 is awaken and accepted. With a deprecation 
> period of course.
>
+1, I never ever used it.

>  - Old alias syntax `alias originalName Alias`. I'd prefer 
> `alias this` to also use the new syntax. Again, deprecation 
> period needed.
+1, I also would love a `alias this = x;` syntax.

On Thursday, 15 September 2022 at 09:12:52 UTC, JN wrote:
> I'd remove templates, but since you mention breakages... in 
> such case I'd say contracts, finalizers and possibly exceptions.

WTF, no ! Templates are why I use D instead of Java or C++ : they 
are well made.


On Thursday, 15 September 2022 at 10:50:11 UTC, ryuukk_ wrote:
>
> - Class as reference type without the *, it should have been 
> like Go since day 1, so no confusion instead of trying to be 
> Java or C#
>
> - Exception Handling (taking inspiration from Swift would be 
> interesting)
>
> - @property apparently, i forgot this was a thing until i saw 
> the post yesterday
>
> - enum, replace this and make better enum with pattern matching 
> and .Enum
>
> - byte, short, int, long, give me (u\*8, u\*16, u\*32, u\*64, * 
> = either nothing or int)

I don't agree with you, at all. Just use Rust.

On Thursday, 15 September 2022 at 13:43:01 UTC, Dennis wrote:
> - Typesafe variadic arguments 
> (https://github.com/dlang/dmd/pull/11124)
> - `lazy`

+2

> - `alias this` inside a class

No.

> - 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__`

I agree. However, D doesn't have a `__FUNCTION__` equivalent. 
(`__FUNCTION__` returns `mymodulee.func` and 
`__traits(identifier, func)` returns `func`)

> - `this(this)` (postblit is superseded by copy constructor, 
> though there are still a lot of bugs)

+1

> - Redundant `__traits` such as isFloating, isIntegral, 
> isScalar, isStaticArray, isUnsigned
>

Maybe.

On Friday, 16 September 2022 at 00:41:25 UTC, Guillaume Piolat 
wrote:
> On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:
>>
>> What features could be removed from D if it were up to you?
>
> real, pure, synchronized, invariant, contracts, @safe, const, 
> TLS, unsigned integers :)
> [...]
> alias this, template specialization, union, @property
> Thank god it's not up to me.

Thank god.