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

September 15, 2022

Re: What features of D you would not miss?

Posted by ryuukk_
in reply to H. S. Teoh

Permalink

ryuukk_

Posted in reply to H. S. Teoh

Permalink

On Thursday, 15 September 2022 at 19:04:33 UTC, H. S. Teoh wrote:

On Thu, Sep 15, 2022 at 01:18:30PM +0000, bauss via Digitalmars-d wrote:

On Thursday, 15 September 2022 at 12:19:28 UTC, 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

Could be added to the runtime module and then simply over a couple years the aliases will be deprecated.

That still requires basically every single D project on the planet to be rewritten to the new type names over the deprecation period.

Not practical.

And seriously, guys, these are just arbitrary names for built-in types. At the cost of wholesale breakage of all existing code? Bikeshedding at its finest. This is DOA.

It could be kept as legacy for C compatibility, and new code could naturally transition to the new types whenever they are ready

I'm not a language dev, so i don't understand the implications of such features

I don't see how it's bikeshedding, it brings consistence for primitives

What's gonna be the name after cent? when other modern languages will have uint256, we will be left alone in the dark with inconsistencies

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.

On 9/15/2022 7:10 AM, bauss 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. That sounds like a good idea, was tried in C++, and didn't work out very well. The trouble is it works great in simple cases, but with more complex overloads nobody can figure out what's happening.

On Friday, 16 September 2022 at 05:18:01 UTC, Walter Bright wrote: > On 9/15/2022 7:10 AM, bauss 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. > > That sounds like a good idea, was tried in C++, and didn't work out very well. > > The trouble is it works great in simple cases, but with more complex overloads nobody can figure out what's happening. Was tried in C# and it works out well. Just because it fails in one language, doesn't mean it does in another.

On Friday, 16 September 2022 at 06:34:01 UTC, bauss wrote: > On Friday, 16 September 2022 at 05:18:01 UTC, Walter Bright wrote: >> On 9/15/2022 7:10 AM, bauss 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. >> >> That sounds like a good idea, was tried in C++, and didn't work out very well. >> >> The trouble is it works great in simple cases, but with more complex overloads nobody can figure out what's happening. > > Was tried in C# and it works out well. Just because it fails in one language, doesn't mean it does in another. Oh and it's certainly much better than alias this.

Forums