Should expression templates be enabled by default as of 2024?

[marcovc]

Hi,

I just spent a couple of days hunting a bug that was caused by using "auto" with this library. I then found out that this is expected:

I wonder if it is a correct decision today, where "auto" is now very well established into the language, to ship a library that by default computes complete wrong results when using it with "auto".

[ckormanyos]

spent a couple of days hunting a bug that was caused by using auto with this library.

Yes this is a known feature. You raise a really good question.

• Enable ExpressionTemplates by default (i.e., leave the library alone)?
• Disable ExpressionTemplates by default? Do we have issues with a breaking change?
• Eliminate ExpressionTemplates entirely? Wow lots of typing and do we have issues with a breaking change?

The final, most obtrusive, option being one I'd preferably not engage on.

I wonder what John thinks of this. We worked hard to get those big numbers. Your intuition might be right from today's perspective. Maybe one day down the road a compiler switch that actively enables legacy could do the trick to get auto working from this point forward...

I wonder what @jzmaddock thinks of such evolutions. I'm kind of a leave it alone and documetn it guy.

[jzmaddock]

+1 on leave it alone, rationale:

1) It's a pretty well known issue, there is a proposal to fix this: https://isocpp.org/files/papers/p0672r0.pdf which uses expression templates as it's motivating factor. The issue even effects proxy objects like std::vector<bool>::operator[], so we are hardly alone here. 2) I know we have people that rely on the expression templates for performance reasons - for some of the science applications which can take days to run, even a few percent speedup is vital. 3) It is documented, and while I realise it's fairly well down the page, there's a big "caution" in the intro that mentions this: https://www.boost.org/doc/libs/1_85_0/libs/multiprecision/doc/html/boost_multiprecision/intro.html. Of course if you're anything like me, you may well skip the docs entirely if you can ;)

[jzmaddock]

I've pinged Joel to see if there's any news on the issue (or an alternative fix in C++17/20/23).

[jfalcou]

P0672 has been left out to die for various reason. I had a comprehensive discussion with various people, including Chandler Carruth, that :

• this problem needs a solution.
• Changing auto is not the way to do it.

I have been not very active for health reasons but it get better since. So if you're interested, we can try to think about a proper solution. I have a bunch of other ideas that may fly further.

The biggest opposition we may face (even if I think it is a bad argument) is that "reflection will fix that anyway". Which is obviously incorrect.

As for language solution, I have now migrated to have constexpr only expression template so that issue happen less. We can also discuss this.

[jzmaddock]

I have been not very active for health reasons but it get better since. So if you're interested, we can try to think about a proper solution. I have a bunch of other ideas that may fly further.

I'm happy to discuss ideas, but I confess my interest in committee stuff is tiny these days (and I confess I'm out of date with the new language features post C++17).

The biggest opposition we may face (even if I think it is a bad argument) is that "reflection will fix that anyway". Which is obviously incorrect.

As for language solution, I have now migrated to have constexpr only expression template so that issue happen less. We can also discuss this.

I'd be interested in knowing how that works.