[libcxx-commits] [libcxx] [NFC][libc++][string] Improve constexpr efficiency (PR #184724)

[Nikolas Klauser via libcxx-commits]

philnik777 wrote:

> > > Sorry, I was traveling and missed the last comment @ldionne @philnik777.
> > > I'll reopen and try once more; if this doesn't convince you, feel free to close it again.
> > > > makes sense for libc++ to start trying to provide guarantees here.
> > > 
> > > 
> > > We don't need to provide guarantees, but this is still a simple compile-time optimization that does less work in the compiler.
> > > Suppose we have two ways to write the same code, with no other tradeoffs:
> > > ```
> > > 1. Takes `N` seconds/steps to compile.
> > > 
> > > 2. Takes `N + M` seconds/steps to compile.
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > Why not pick 1 over 2?
> > > I see the same situation here. There is no downside to landing this PR, and the code is strictly better than before—not dramatically, but better.
> > 
> > I think this is the fundamental disconnect: IMO we _do_ have a tradeoff to be made: We're adding code for the purpose of improving constant evaluation steps. However, these branches have to be evaluated and understood when you read the code. If they don't exist there is nothing to understand. `string` is already the most complicated type in the library. Adding more branches makes it a bit harder to understand, and that's how we ended up with an incredibly complicated type. It's incredibly hard to keep `string` somewhat maintainable as-is. Complicating the implementation for improving and arbitrary counter isn't exactly something I'm thrilled about.
> 
> This logic can justify submitting trivial and readable but very inefficient code?
> 

Yes. There is a trade-off, which is my entire point. You claimed there are no trade-offs AFAICT, which i'm arguing against.

https://github.com/llvm/llvm-project/pull/184724