D1.5 anyone? (page 4)

April 17, 2023

Re: D1.5 anyone?

Posted by ryuukk_
in reply to Dmitry Olshansky

Permalink

ryuukk_

Posted in reply to Dmitry Olshansky

Permalink

On Saturday, 15 April 2023 at 10:29:10 UTC, Dmitry Olshansky wrote:

On Friday, 14 April 2023 at 18:33:50 UTC, ryuukk_ wrote:

On Tuesday, 11 April 2023 at 13:32:53 UTC, Dmitry Olshansky wrote:

[...]

With choose, for a new keyword, something very ugly?

[...]

One word - backward compatibility. Keywords with __ are reserved by the compiler.

If it's reserved by the compiler, it shouldn't be available for me to type, nor should it be providing a workaround to a poor design (tls)

What the user supposed to do?

> >

[...]

Maybe.

[...]

It will be an experiment, a backwards compatible one.

disappears, 0 compatibility with that code

Why backward when we can move forward? maintaining bad design is not desirable, at least to me, i'd rather move forward

This is a disconnect in D, the expectation that everyone is a compiler dev, and everyone should subscribe to maintaining the existence of poor design

As a result i have to type __gshared all over my code base, wich i hate so much that i'm willing to work D to rename that to notls, or @notls, unfortunatly i am not a compiler dev, so i have to cope with it, wich frankly is not something i want to deal with forever, at some point i'll move on and embrace a different language, unfortunatly, there is nothing on the market that's good enough to justify me porting over my code, again..

On 18/04/2023 3:54 AM, ryuukk_ wrote: > As a result i have to type __gshared all over my code base, wich i hate so much that i'm willing to work D to rename that to notls, or @notls, unfortunatly i am not a compiler dev, so i have to cope with it, wich frankly is not something i want to deal with forever, at some point i'll move on and embrace a different language, unfortunatly, there is nothing on the market that's good enough to justify me porting over my code, again.. We need that for fibers/coroutines to be safe so at some point it needs to be added anyway. However TLS in -betterC should be fixed in ~master.

On 4/13/2023 5:59 PM, Richard (Rikki) Andrew Cattermole wrote: > - Remove ``shared(T)`` > - Add ``atomic(T)`` so that ``a++;`` works, rather than a failure mode (like -preview=nosharedaccess introduces, or having to cast away shared). That looks like the way C11 does it.

On 18/04/2023 2:12 PM, Walter Bright wrote: > On 4/13/2023 5:59 PM, Richard (Rikki) Andrew Cattermole wrote: >> - Remove ``shared(T)`` >> - Add ``atomic(T)`` so that ``a++;`` works, rather than a failure mode (like -preview=nosharedaccess introduces, or having to cast away shared). > > That looks like the way C11 does it. Yeah that covers atomic variables, but doesn't cover any sort of concurrency safety. In a way its very similar to our simd stuff in the language. Although in saying that the simd stuff should be on the deprecation path, its not needed and is a distraction to getting your code performant. Modern backends are just too good, you can 100% do everything you want with just static arrays and almost certainly do it without writing a single intrinsic. gdc/ldc can do things that clang cannot, they are amazing! Also array ops <3

On Wednesday, 12 April 2023 at 07:33:00 UTC, Walter Bright wrote:

On 4/12/2023 12:05 AM, Walter Bright wrote:

> >

Templates without extreme precautions and Unqual!T all around will get instantiated up to 3x(!) times.

I'm not sure why Unqual!T exists. cast()T will remove all the head qualifiers, no templates involved.

Oops. That is, cast()E will remove all the qualifiers from the type of E. So Unqual!T needs to exist. My mistake.

Example? My quick-and-dirty tests say that cast() x removes only the head qualifiers. Well if you have a struct with default-mutable members, immutable will be removed from the fields too (I think) but I don't think Unqual!X is different in that regard.

I believe the primary difference is that cast() x works on the value, while Unqual!X works on the type.

Forums