Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[range.join.iterator] Rename ref-is-glvalue to account for rvalues #3610

Closed
JohelEGP opened this issue Jan 7, 2020 · 4 comments
Closed

[range.join.iterator] Rename ref-is-glvalue to account for rvalues #3610

JohelEGP opened this issue Jan 7, 2020 · 4 comments

Comments

@JohelEGP
Copy link
Contributor

JohelEGP commented Jan 7, 2020

We want to join rvalues (see ericniebler/stl2#598 (comment)), so the name of ref-is-glvalue is deceptive. I suggest renaming it to deref-is-ref.

@CaseyCarter
Copy link
Contributor

The variable is true if and only if *i is a glvalue for a value i of type iterator_t<Base>, i.e., it's true if that iterator type's "reference type" is a reference type. (It's unfortunate that iterators have an associated type "reference type" which reuses the name of a category of core language types, doubly so given that the "reference type" of an iterator is often but not always a reference type, but that ship sailed decades ago.)

While I don't care much about the (exposition-only) name of the variable, I don't find deref-is-ref to be a substantial improvement over ref-is-glvalue. To avoid confusion - different people will interpret our cryptic abbreviations differently - I think we should pick either a short and meaningless name like potato or a long and descriptive name like has_true_reference_type or result_of_dereference_is_glvalue.

@JohelEGP
Copy link
Contributor Author

JohelEGP commented Jan 7, 2020

The variable is true if and only if *i is a glvalue for a value i of type iterator_t<Base>

It is because that is not true that I opened this issue. *i could be an rvalue and the variable would be true because it uses is_reference_v and not is_lvalue_reference_v.

If ericniebler/stl2#641 was picked up, this exposition-only variable would be replaced with safe_range. In case it isn't, deref-is-ref is not deceptive even if it still uses the overloaded reference term. has_true_reference_type seems like an improvement.

@CaseyCarter
Copy link
Contributor

The variable is true if and only if *i is a glvalue for a value i of type iterator_t<Base>

It is because that is not true that I opened this issue. *i could be an rvalue and the variable would be true because it uses is_reference_v and not is_lvalue_reference_v.

A glvalue is either an lvalue or an xvalue. *i is an lvalue iff is_lvalue_reference_v<decltype(*i)> is true. *i is an xvalue iff is_rvalue_reference_v<decltype(*i)> is true. *i is a glvalue iff is_reference_v<decltype(*i)> is true, so the initializer of ref-is-glvalue uses is_reference_v.

@JohelEGP
Copy link
Contributor Author

JohelEGP commented Jan 7, 2020

You are right. Thank you. Unfortunately, I had already opened an LWG issue for this a while ago rather that choosing this lower barrier venue, as I prefer.

@JohelEGP JohelEGP closed this as completed Jan 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants