On Sun, Jun 14, 2020 at 7:56 AM Frank Zingsheim <f.zingsheim_at_[hidden]> wrote:

> Thank you for your comments.
> (See an updated version on
> <https://github.com/zingsheim/ProposalTernaryFold/blob/progress/ProposalTernaryFold.md>
> https://github.com/zingsheim/ProposalTernaryFold/blob/progress/ProposalTernaryFold.md
> )
>
[...]

> (2) You say "initial value" several times when you mean "final value".
>
> The reason why I called it initial is the recursion which is build up to
> generated the code for ( C ? E : ... : I )
>
> (I)
> (C(N) ? E(N) : (I))
> (C(N-1) ? E(N-1) : (C(N) ? E(N) : (I)))
> (C(N-2) ? E(N-2) : (C(N-1) ? E(N-1) : (C(N) ? E(N) : (I))))
> ...
>

What I notice about each of those expressions is that (I) appears *last *in
each of them. Hence, it's the "final" subexpression in every single one.
"Initial" means "first/leftmost"; "final" means "last/rightmost."

Furthermore, in the first proposal P1012R0
> https://github.com/zingsheim/ProposalTernaryFold/blob/P1012R0/ProposalTernaryFold.md there
> was a comparison to binary fold expressions and in a fold like (values +
> ... + 0) you would call the 0 the initial value and not the final value.
>

I certainly would not!
I don't see any precedent-making use of the term "initial value" in
http://eel.is/c++draft/expr#prim.fold either, although I just glanced
briefly at it.

However, since the conditional operator is the only ternary operator in C++
> the wording "*final expression*" might be more suitable or even "*default
> expression*", since it is comparable to the "default:" of a "switch"
> statement. What do you think?
>

I think "default [sub]expression" or "default value" would also be
reasonable.

To you comments to the + on the string_view you are right (what should the
> + return, definitely not a string_view).
> But do you know why std::string + std::string_view does not work and one
> has to use std::string.append instead?
>

I don't know for sure, but I suspect that it has to do with overload
resolution. If you permit string + string_view, then you also permit
string + (anything implicitly convertible to string_view), which means that
if someone has a QString that is convertible to *both *string and
string_view, then suddenly (string + QString) becomes ambiguous.
Implicit conversions are the devil.


> [...]
> For the hyperlinks I tried to add them. They work on Typora (a markdown
> editor) but unfortunately they do not work on Github (
> https://github.com/zingsheim/ProposalTernaryFold/blob/progress/ProposalTernaryFold.md).
> Do you know what might be wrong with their formating?
>

Right now you have this:

It can be emulated by the fold on operator|| [[5]](######[5]
foonathan::blog(): Nifty Fold Expression Tricks: Get the nth element
(where n is a runtime value)
https://foonathan.net/2020/05/fold-tricks/).

You should have this instead:

It can be emulated by the fold on operator||
[[5]](#5-foonathanblog-nifty-fold-expression-tricks-get-the-nth-element-where-n-is-a-runtime-value-httpsfoonathannet202005fold-tricks).

I got the name of that HTML anchor by clicking on the "chain link" icon
that appears to the left of note 5 when you mouse over it, and then cutting
and pasting from the browser address bar.

–Arthur

>