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 :
- Free the memory (call
free()
) once the pointer's lifetime has ended (Rust's style)
- 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.
- 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 ?)
@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 :
- Panic when slicing in the "middle" of a character (Rust does it this way)
- Throw an Exception
- 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:
>
+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.