@JohnDlugosz
Slides 44 and 45, before 35:00 in the video: Rather than over a hundred compiler built-ins named after type traits, I'd like the general ability to define such things in the source files. E.g. just as we nominate each trait to be available with the _v variation, declare that this is "in" the new dotted lookup namespace. Just bikeshedding here, but perhaps it can be done by putting an attribute on any suitable declaration.
@Sebanisu
I like the way he simplified working on parameter packs.
@jonohiggs
You could reduce the boilerplate for `template <typename ... auto> typename Template` to just `template Template`
@CuriousCauliflowerX
Modern C++ makes me want to cry.
@Voltra_
I love Circle
@isitanos
Ha ha ha, "the standard library should be an advertisement for the language, but in C++, it's a warning" - so true.
@dexterman6361
This is god so amazing
@sanjaygatne1424
Nice talk.
@raymundhofmann7661
Wouldn't it be good to have a "circle pre processor" to ease use and experimentation when fixed to popular compilers?
@den007trof
I hope project will find support (patreon, maybe?) or become opensource, otherwise it will be risky to use with big production code bases. A very interesting project but no serious company would ever allow this to touch their internal codebases unless the code is open source and/or reviewed by the community - which is sad.
@Anon-z4h
That std::tuple is implemented in library space at all is honestly a travesty. Lot of nice ideas here.
@svirfneblin
Relational instead of just equality operators for types would be nice to implement efficient sets of types
@maksymiliank5135
Some of the things presented here are really great, but having to remember all that additional syntax would be a nightmare. I think that something like constexpr for, or inline for would be much more readable than all the permutations of ... operator.
@DerDoMeN
A really nice talk.
I'm still not completely sold on these features but do find this view interesting (I'm really surprised that people seemed to talk more about that Carbon-mess than Circle...).
There is one reason why I find generic better to specific - generic is thinking in steps on how to mutate something, specific is remembering specific keyword/syntax (e.g. I use fold operations but I'm still doing the trial and error approach when figuring out how to write the ... syntax correctly for a specific case).
I also have a friend that even in C# prefers non-syntactic-sugar syntax over a bit longer non spiced one as he finds it not worth remembering what the newer stuff does and to some extent I can relate to that.
But here quite a lot of talk was regarding control flow and if/for/while etc. are also just syntactic sugar over goto... So introducing some more seems like a direction worth considering.
in the { if T == Ts => p ... } example I saw the least benefit compared to the reflection example (I found both as need more polish) but yeah... I see the appeal.
The issue with that exact example that I have is that it went into the opposite extreme (packing too much into one if statement + introducing injection to outside-outside-of-if context.
What I'd prefer would be e.g. to rewrite the left, more generic, part to:
std::vector<T> result;
for( std::size_t i = 0; i < sizeof...(Ts); ++i )
{
if( Ts[i] == T )
result.push_back( p[i] ) );
}
So more or less just let the standard if/for/etc. control flow commands work on types as well and variadic templates allow access to elements via [] (both types and values) - preferably without additional template prefix in front of the control flow commands (as I don't know why you shouldn't be allowed to write: if( Ts[i] == T && i%2 == 0) as long as you don't mix types and values in one part of bool operation - even though it could be argued that I'm already doing that with Ts[i] :) ).
I'd say that that'd be the best of both worlds that were shown from the code writer perspective but would be interesting to see the compile times :) (but in reality those are really problematic only for big companies and people that prefer experimenting before thinking about the algorithm but I'm certainly biased here :) )
@cemgecgel4284
I think it is great that C++ can be improved this much (especially Type.stuff is very ingenious), but I think it just creates yet another set of syntax rules in an already huge language. I would prefer a new, clean language written with the lessons learned from C++.
@Cons-Cat
Why is this unlisted?
@piotrarturklos
It's a very nice language to use, I'm just a little concerned about the size of the language specification and the time it takes to learn such language. Sometimes better is the enemy of the good and I wonder if it's true in this case.
@arthurararuna
19:46 How does this `index_of` interact with the negative value being used as index? He said negative index values index from the end, so would this be a footgun if used immediately to index the pack (because it would return the last type)? What would be a "safe" alternative in case it is?
@uncoherentramblings2826
Cool ideas but it the ugliest thing ever and that's important...
@japedr