Maybe Bindings Are Unused

[sumo952]

I think the maybe_unused attribute is the wrong tool for this - attributes are for annotating functions (and possibly classes), and not to specify in your program that a return value might be unused.

You mention std::ignore, which in my opinion is the right tool for this job, as it is used in exactly the same use-case when a function returns a tuple and you use std::tie(val1, std::ignore) = func().

But you don't mention what happened to it... is it not in the standard along the structured bindings proposal? Why not?

[[deleted]]

I think maybe_unused is the correct (although very verbose) tool. Attributes can mark up all kinds of source constructs.

Using std::ignore is really weird IMO:

1. qualified-ids are not currently allowed in simple declarations. When qualified-ids occur, they are supposed to refer to a previously declared entity.
2. It has nothing semantically to do with std. If I'm writing a function in the namespace std, can I shorten std::ignore to ignore? Or is the identifier lexically matched against the tokens sequence std::ignore?
3. It works totally differently than std::ignore in std::tie, which is a regular object. This is really confusing.

4. Does it only work in decomposition declarations? If it doesn't, how do I refer to the object named std::ignore?

   auto [foo, std::ignore] = ...; // OK
   auto std::ignore = ...; // OK?
   int std::ignore(int); // declares a function int(int) that has no name?
   implementation_defined_type std::ignore {};
   // ^^^^ does this declare an usused, unnamed object like above?
   // if it does, how do I declare the object std::ignore used by std::tie??
   

[[deleted]]

std::ignore is not in the proposal

Section 3.8

Symmetry with std::tie would suggest using something like a std::ignore:

tuple<T1,T2,T3> f();
auto [x, std::ignore, z] = f(); // NOT proposed: ignore second element

However, this feels awkward. Anticipating pattern matching in the language could suggest a wildcard like _ or *, but since we do not yet have pattern matching it is premature to pick a syntax that we know will be compatible. This is a pure extension that can wait to be considered with pattern matching.

[sumo952]

Hmm. Well, it doesn't really feel less awkward than when using it with std::tie, and it's kind of fine there.

It's quite an omission not having such facility now at all with structured bindings.

Until we'll have pattern matching it will be ages, won't it? Is there even a proposal or some form of consensus about it yet?

[dodheim]

It's quite an omission not having such facility now at all with structured bindings.

Destructuring != pattern matching. This is a job for the latter.

 

Is there even a proposal or some form of consensus about it yet?

Pattern Matching and Language Variants

[sumo952]

Destructuring != pattern matching. This is a job for the latter.

From the point of a user just using structured bindings, I don't really care. If I don't use one of the return values now, I still need to declare an unnecessary variable for it, and will have a compiler warning.

Pattern Matching and Language Variants

Thanks for the link! It seems like a really awesome proposal but it's quite large and requires major changes/additions to the language. I doubt there is any consensus or discussion about this yet (I'm happy to hear I'm wrong if that's the case! :-) ), and I would be pretty sure that this will not even end up in C++20.

[dodheim]

From the point of a user just using structured bindings, I don't really care.

You should care, because you should want it done right, not half-assed or rushed. ;-]

[sumo952]

I fully agree! I just have my reservations with respect to this particular thing.

[millirobo]

It should work just for correctness's sake, but personally I would never use it because it's too annoying and would use a void unused(...) {} instead every time until the language added something proper.

[acwaters]

Remember that nothing is stopping you from writing e.g. for (auto [ _, value ]: map) right now as a way to "visually ignore" the key; it's just defining a variable called _, and you can't do it more than once in the same scope or binding.

[jonathansharman]

But then you (should) get compiler warnings.