Refactor core.atomic : cas into a two-level template

[Geod24]

This should reduce the amount of boilerplate needed in the implementation,
and hopefully make the code easier to read for everyone.

I want to see how it shows up in the doc though, before we merge this.

[dlang-bot]

Thanks for your pull request, @Geod24!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + druntime#3095"

[Geod24]

@TurkeyMan : Alright I have to admit when I started refactoring this I missed the point that this was essentially both compare-and-set and compare-and-exchange (as in, ifThis might get written to).

Combining this with templates leads to a very unintuitive API IMO. Things blew up for me when I tried to use compare-and-set with pointers (basically initializing a shared immutable(T)*). Thoughts ?

[TurkeyMan]

This is terrifying. Does argument inference work exactly the same with this arrangement?
I have no feel for what the semantics are with this change :/

I don't have time right now to think this through, but I'd like the opportunity to understand this before it's merged.

[Geod24]

This is terrifying. Does argument inference work exactly the same with this arrangement?

As long as one does not explicitly specify the type of arguments, and relies on IFTI, everything works the same. This pattern is very helpful when one needs to have some template parameters part of the interface and others not.

I don't have time right now to think this through, but I'd like the opportunity to understand this before it's merged.

Any chance you could give it a look now ?

[Geod24]

Ping @TurkeyMan

[n8sh]

The change to a two-level template will cause any existing fully-parameterized uses of cas to fail to compile!

[Geod24]

The change to a two-level template will cause any existing fully-parameterized uses of cas to fail to compile!

Indeed but fully-parameterized cases of IFTI is not usually something we cater for, unless there's a special-case for cas I'm not aware of ?

[Geod24]

Ping @TurkeyMan

[n8sh]

I don't see documentation indicating to library users that core.atomic.cas is not supposed to be explicitly parameterized, but as the parameterization was changed a year ago without objection I can't on principle say this is a blocker.

[Geod24]

Well it's been more than 72h so adding auto-merge.

[Geod24]

I don't know what's up with FreeBSD... It doesn't seem spurious, however this was seen in other unrelated PR. Will investigate next week.