@Archivist are you a gcc alt? stop gaslighting meeee >.<

otherwise, please elaborate, good sir, what is your objection? o.O

@namark nah, I am just accustomed at how confusing the standard is

@Archivist don't make me read the standard, I'll defect report :<

@namark

The basis for my questioning here is that primitive operators in C++ are not functions, so whenever they warrant implicit conversions or not with a behaviour similar to an actual function is questionable

I will actually investigate that a bit and tell you my findings

@namark

I confirm that this is a bug of GCC linked to templates. You can circumvent that bug using concepts in a portable fashions (see here: https://godbolt.org/z/PzT9eeTj4)

@Archivist concepts are nice... the ranges and modules baggage though... also not going to use a standard that's barely not even done implemented yet so far.

The real workaround is

template<typename T, size_t D>
int operator+(int, One<T,D>);

and so on, and if that's all you needed maybe making the conversion explicit, not that gcc respects explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87820

@Archivist *cough* I mean
template<typename T>
T operator+(T, One<T,1>);
and so on

@namark

well, that is quite a work around the wrong thing (and it doesn't actually work in all circumstances) which is why it would definitely favour the concept approach (which also allows me to not use enable_if ever again)

I try to always work with the latest validated version of C++, though I understand your reasons for not liking the incomplete module system (I don't quite get the point of view on ranges though, those are quite nice)

@Archivist
> working with the latest version
gotta love not compiling your code then

> ranges
library is experimental and not fully baked by the admission of the author, has several major issues at the design and technical level. I was under the impression that only time proven common practises can get into the standards, but apparently if you are friends with the higher-ups anything goes.

@namark

I use features when they get fully supported by clang (I don't care a lot about msvc or gcc) so stuff compiles

Ranges are no longer an experimental feature since C++20. The features that were approved are all very straightforward and rather useful, in particular when it comes to avoiding raw loops and in writing simpler and more readable code when using standard algorithms

@Archivist
> I use features when
so basically you ar working with some unspecified intermediate standard

> get fully supported by clang
and you like lagging behind

@Archivist also where is it that the user defined operators don't work, tell me so I fix my code please

@namark they do work but are cumbersome and make the code harder to read which is why I would not use them

Also this bug triggers with other things for which the operator overload will not be a solution

@Archivist yeah, operators are generally cumbersome, but I already have some heavy machinery set up to deal with them... it's macros ok? the language left me no choice!

@ercadio I'm gonna pretend you didn't say msvc, but wanna see clang crash and burn? I'm gonna show you anyway:
http://ix.io/2nlF/cpp

@iron_bug this is like c++98 level code in terms of language features involved... and don't you come at me with C I'll shred you :V