What features of D you would not miss? (page 5)

Settings

Help

Index » General » What features of D you would not miss? (page 5)

September 16, 2022

Re: What features of D you would not miss?

Posted by Mike James
in reply to Walter Bright

Permalink

Mike James

Posted in reply to Walter Bright

Permalink

On Friday, 16 September 2022 at 05:00:31 UTC, Walter Bright wrote:
> On 9/15/2022 5:19 AM, ryuukk_ wrote:
>> On Thursday, 15 September 2022 at 11:24:07 UTC, bauss wrote:
>>> alias uint = u32;
>> 
>> You have then to import the module everywhere, wich makes the feature i want a painful nightmare
>
> C has stdint.h, which I've seen very little uptake on.

Unless you have to write a lot of code that conforms to MISRA C... :-)

-=mike=-

September 16, 2022

Re: What features of D you would not miss?

Posted by RazvanN
in reply to Dennis

Permalink

RazvanN

Posted in reply to Dennis

Permalink

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

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

There are not a lot of bugs, there are exactly 5 bugs that affect copy constructors exclusively (there are others that manifest in conjunction with a copy constructor, but those manifested with the postblit as well):

https://issues.dlang.org/show_bug.cgi?id=22614 (arguably, not a problem of copy constructors - see comments in bug report)
https://issues.dlang.org/show_bug.cgi?id=22239 (not obvious how to fix)
https://issues.dlang.org/show_bug.cgi?id=21613 (PR submitted)
https://issues.dlang.org/show_bug.cgi?id=20876 (doesn't necessarily block migration, it's just that the error message is not ideal)
https://issues.dlang.org/show_bug.cgi?id=20208 (affecting c++ interoperability)

From the list above, the only issue that is blocking the transition from postblit to copy constructor is 22239. So there is exactly 1 bug that impedes the deprecation of postblits in favor of the copy constructor, so please do not spread fear of using the copy constructor.

September 16, 2022

Re: What features of D you would not miss?

Posted by Luhrel
in reply to Dukc

Permalink

Luhrel

Posted in reply to Dukc

Permalink

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 ?)
@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.

@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

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)

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.

September 16, 2022

Re: What features of D you would not miss?

Posted by H. S. Teoh
in reply to Luhrel

Permalink

H. S. Teoh

Posted in reply to Luhrel

Permalink

On Fri, Sep 16, 2022 at 09:24:40PM +0000, Luhrel via Digitalmars-d wrote: [...]
> I would also remove `wchar` and `dchar` (and [`d`/`w`]`string`), and go full Unicode for the `char` type, like in Rust.

wchar/wstring is occasionally useful for interfacing with some Windows APIs.

`dchar` is needed for representing a full Unicode code point (which can go up to 0x10_ffff). But `dstring` is pretty much useless.

> However, this would be a little challenging when slicing :
>  1. Panic when slicing in the "middle" of a character (Rust does it
>  this way)

The problem is that what we think of as a "character" is *not* what the Unicode standard calls a "character". Well actually, Unicode doesn't even use the word "character"; it has something called "code points", which people mistakenly assume is the same as our concept of "character" (unfortunately, this is not true). A `char` corresponds with a "code unit" in UTF-8; one or more code units correspond with a single code point.  However, what we think of as a "character" may consist of *multiple* code points: for example, the sequence \u0041\u0301 consists of *two* Unicode code points, but a single displayed character (which Unicode calls a grapheme).

The problem of slicing in the "middle" of a "character" will occur even if you don't allow breaking apart code units that encode a single code point. For example, the above sequence "\u0041\u0301" can be legally split into two separate code points, but that would also break the grapheme.  The only way to avoid this is to allow slicing only between grapheme boundaries...

... unfortunately, computing grapheme boundaries is non-trivial in Unicode and introduces a big performance hit if you overuse it.

Most code actually should *not* care about any of the above; they should treat strings as opaque binary data and only use Unicode library functions to manipulate them. In the rare case when you actually need to parse individual elements in the string, you can iterate over graphemes with std.uni.byGrapheme. (Or iterate over code points, depending on what your code is trying to do.)

>  2. Throw an Exception

Bad idea. In fact, we worked really hard to try to get rid of this behaviour in Phobos, and I'm not sure if we're 100% there yet.

>  3. Change `char` size to 4 bytes, so "`char` = `dchar`" by default

This would imply extending autodecoding to every string operation on UTF-8 data.  Autodecoding is something we've been trying to get rid of, not keep, much less extend. :-P

T

-- 
If you're not part of the solution, you're part of the precipitate.

September 16, 2022

Re: What features of D you would not miss?

Posted by Luhrel
in reply to H. S. Teoh

Permalink

Luhrel

Posted in reply to H. S. Teoh

Permalink

On Friday, 16 September 2022 at 21:50:53 UTC, H. S. Teoh wrote:
> On Fri, Sep 16, 2022 at 09:24:40PM +0000, Luhrel via Digitalmars-d wrote: [...]
>> I would also remove `wchar` and `dchar` (and [`d`/`w`]`string`), and go full Unicode for the `char` type, like in Rust.
>
> wchar/wstring is occasionally useful for interfacing with some Windows APIs.
>
> `dchar` is needed for representing a full Unicode code point (which can go up to 0x10_ffff). But `dstring` is pretty much useless.
>
> [...]
>
> The problem is that what we think of as a "character" is *not* what the Unicode standard calls a "character".
>
> [...]
> 
> they should treat strings as opaque binary data and only use Unicode library functions to manipulate them.
>
> [...]
>
> Bad idea. In fact, we worked really hard to try to get rid of this behaviour in Phobos, and I'm not sure if we're 100% there yet.
>
> [...]
>
> This would imply extending autodecoding to every string operation on UTF-8 data.  Autodecoding is something we've been trying to get rid of, not keep, much less extend. :-P
>
>
> T

You're probably right. Some ideas are bad ideas ;)

September 17, 2022

Re: What features of D you would not miss?

Posted by Ogi
in reply to Dukc

Permalink

Ogi

Posted in reply to Dukc

Permalink

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?

Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.

September 17, 2022

Re: What features of D you would not miss?

Posted by 0xEAB
in reply to Dukc

Permalink

0xEAB

Posted in reply to Dukc

Permalink

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?

The (already deprecated) «body» keyword.
BUT: only because it’s already been superseded by «do»

Please consider the breakage that would result from the removal

Legacy code (that doesn’t compile without warnings anymore).
Also it’s one step towards more ambiguity (because «do» got several meanings now).

September 17, 2022

Re: What features of D you would not miss?

Posted by Dennis
in reply to Ogi

Permalink

Dennis

Posted in reply to Ogi

Permalink

On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:

Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.

I don't use non-ASCII identifiers, but you'll have to explain how e.g. using π instead of pi results in bugs or maintenance burden.

September 18, 2022

Re: What features of D you would not miss?

Posted by Paul Backus
in reply to Dennis

Permalink

Paul Backus

Posted in reply to Dennis

Permalink

On Saturday, 17 September 2022 at 20:08:26 UTC, Dennis wrote:

On Saturday, 17 September 2022 at 07:37:24 UTC, Ogi wrote:

Non-ASCII characters in identifiers. There is no good reason to use this “feature”, unless your goal is bug-ridden and unmaintainable code.

I don't use non-ASCII identifiers, but you'll have to explain how e.g. using π instead of pi results in bugs or maintenance burden.

I would say not being able to easily type an identifier with the keys on one's keyboard counts as a maintenance burden.

September 18, 2022

Re: What features of D you would not miss?

Posted by Nicholas Wilson
in reply to Dukc

Permalink

Nicholas Wilson

Posted in reply to Dukc

Permalink

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

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:

But it doesn't disprove the fact that sometimes, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

People often complain that D has too many features. What features would you say are not worth it?

This is a good question, but would quickly derail the original thread from it's topic, so I decided to start a new one.

real, specifically x86 80-bit,

its slow, you can't vectorise it
the extra precision isn't much use
use is often unintentional, and when it is the intention is almost always misguided. If you have precision problems a couple of bits of extra precision won't make up for a horrible convergence rate and if it does, you probably need an arbitrary precision type anyway.

Top | Forum index | About this forum

Forums