26:07 I like the notion of more flexible algorithm returns, and I think it resonates well with Stepanov “law of useful return”. I don’t understand why you prefer to make the ‘Pack’ strategy a template argument of the algorithms, instead of having the algorithms return an object with all the information, which can be ‘packed’ by the caller however they like.
You save a branch. The `tc::find` does not require any extra branch to distinguish between the element/no element case to implement element_or_null. If you do it afterwards, you need to branch again on the algorithm result.
Regarding the question at the end, it is possible to honor constness for some incarnations of ranges and, in general, for reference-like types. It is not impossible, but just very hard. One needs a disciplined overload of &, &&, and const& member functions and function arguments, even using still unconventionally idioms. The problem is that many experts think it is not worthy of attention and that it is a non-issue, and they justify this by giving a postmodern interpretation of what `const` means or simply giving up. We will pay dearly for this oversight; it will fragment conventions and make it hard, if not impossible, to write generic code (I mean Stepanov's Generic code). It would be great if TC (and others) took on this challenge, given all the other nice research they are doing.
![Better C++ Ranges - Arno Schödl - [CppNow 2021]](http://i.ytimg.com/vi/P8VdPsLLcaE/mqdefault.jpg)
26:07 I like the notion of more flexible algorithm returns, and I think it resonates well with Stepanov “law of useful return”. I don’t understand why you prefer to make the ‘Pack’ strategy a template argument of the algorithms, instead of having the algorithms return an object with all the information, which can be ‘packed’ by the caller however they like.
You save a branch. The `tc::find` does not require any extra branch to distinguish between the element/no element case to implement element_or_null. If you do it afterwards, you need to branch again on the algorithm result.
Regarding the question at the end, it is possible to honor constness for some incarnations of ranges and, in general, for reference-like types. It is not impossible, but just very hard. One needs a disciplined overload of &, &&, and const& member functions and function arguments, even using still unconventionally idioms. The problem is that many experts think it is not worthy of attention and that it is a non-issue, and they justify this by giving a postmodern interpretation of what `const` means or simply giving up. We will pay dearly for this oversight; it will fragment conventions and make it hard, if not impossible, to write generic code (I mean Stepanov's Generic code). It would be great if TC (and others) took on this challenge, given all the other nice research they are doing.