Here's some example code showing these features:
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b236289c-3757-4047-a1b4-7781148af265%40isocpp.org.
I would find the feature more useful if it offered slightly less functionality; in particular, I'd like a guarantee that no operation at all can be performed on such variables except the automatic destruction at end of scope.
To these ends, would it make sense to dispense with the variable name altogether, making the objects truly anonymous?
auto = std::lock_guard<std::mutex>(mtx1);
auto = std::lock_guard<std::mutex>(mtx2);
g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
main.cpp: In function 'int main()':
main.cpp:10:9: warning: unused variable 'b' [-Wunused-variable]
int b(0);
Related: I just noticed that it seems compiler writers have to special-case treatment of
std guards to not give unused variable warnings?
_ is already used as a placeholder in the MPL. It's also sometimes used as a local macro name. You have a neat idea, but _ seems pretty well spoken for. It's also unclear that this proposal would solve a real pain point, or whether it's convenience would be outweighed by (arguably) less readable code.
I would find the feature more useful if it offered slightly less functionality; in particular, I'd like a guarantee that no operation at all can be performed on such variables except the automatic destruction at end of scope.
On 10 July 2016 at 15:10, <je...@unbuggy.com> wrote:_ is already used as a placeholder in the MPL. It's also sometimes used as a local macro name. You have a neat idea, but _ seems pretty well spoken for. It's also unclear that this proposal would solve a real pain point, or whether it's convenience would be outweighed by (arguably) less readable code.
I would find the feature more useful if it offered slightly less functionality; in particular, I'd like a guarantee that no operation at all can be performed on such variables except the automatic destruction at end of scope.This is, of course the problem. You are looking to change functionality which has been there since C90 (or even longer). This would break working code and introduce an incompatibility with C. You could possibly mitigate the latter with a complicated rule (for instance, it only has the desired semantics for types with non-trivial destructors), but if you are stealing a name, you cannot help but break the former.
auto [a, b] = ...;
auto &&temp = make_pair(3, 4.5f);
auto &a = temp.first;
auto &b = temp.second;
auto [] = ...;
auto[] = scope_exit(...);
That's interesting Nicol, but what about the other cases? For structured binding itself
for example, how would I let bindings unnamed?
On Sun, Jul 10, 2016 at 6:44 PM, Nicol Bolas <jmck...@gmail.com> wrote:
> Wait a minute. Let's think about what we just added to C++: structured
> binding:
>
> auto [a, b] = ...;
Currently this syntax is outlawed,
Don't try to solve every problem at once.
Besides _ or __ I'm thinking of other possibilities...
@: I know of its presence solely in mangled names but I suspect it won't be an issue.
I dunno, maybe the range of special characters may be of some use here too.
Em domingo, 10 de julho de 2016 23:08:39 UTC-3, Francisco Lopes escreveu:Besides _ or __ I'm thinking of other possibilities...
@: I know of its presence solely in mangled names but I suspect it won't be an issue.
I dunno, maybe the range of special characters may be of some use here too.
If adopting such alternative characters, it would be placeholder only, without referentiability.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%40isocpp.org.
I've been following this with great interest but I disagree with using _, __, @, etc.If the goal of a future proposal is having unnamed variables IMHO they should not use any character or sequence of characters to be... well ... named.
Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:That's interesting Nicol, but what about the other cases? For structured binding itself
for example, how would I let bindings unnamed?
Remember the goal: you want an object to be unnamed, because you want to use its construction and destruction only. The variables created by structured binding are not objects; they're references. Their destructors are irrelevant, so making them unnamed is equally irrelevant to this particular goal.
That may look like the original goal in the previous thread, but to tell the truth it's not my goal. The rationale
here is for unnamed variables. It's just about to cover the intention of not providing names for things
that doesn't need them, as frequently happen (and will happen) in the cases presented.Don't try to solve every problem at once.
Why not? It's a simple solution that covers the relevant problem: having a placeholder. It ends up
solving all in an understandable manner, in a uniform way.
I ask why solve it in a case by case form?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBVUC1ezm7POV8YzDuzTc0Qn6s0amdfbQq_Di1gAxSwYg%40mail.gmail.com.
If I'm following Francisco's line of thought that would not work for:auto [a, register, c] = foo();
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b49da70c-9e69-4a19-8e1e-0afb26e38aeb%40isocpp.org.
On Sunday, July 10, 2016 at 9:53:11 PM UTC-4, Francisco Lopes wrote:
Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:That's interesting Nicol, but what about the other cases? For structured binding itself
for example, how would I let bindings unnamed?
Remember the goal: you want an object to be unnamed, because you want to use its construction and destruction only. The variables created by structured binding are not objects; they're references. Their destructors are irrelevant, so making them unnamed is equally irrelevant to this particular goal.
That may look like the original goal in the previous thread, but to tell the truth it's not my goal. The rationale
here is for unnamed variables. It's just about to cover the intention of not providing names for things
that doesn't need them, as frequently happen (and will happen) in the cases presented.Don't try to solve every problem at once.
Why not? It's a simple solution that covers the relevant problem: having a placeholder. It ends up
solving all in an understandable manner, in a uniform way.
But it is not a "simple solution". Indeed, I would go so far as to say that any placeholder which is currently a valid identifier is not a solution at all.
Breaking people's perfectly valid code should not be considered a solution to a problem. Not without really good reason. And let's face facts: unnamed variables are not that important.
Also, last time we tried to get something "uniform", we got Uniform Initialization. Which very much is not.I ask why solve it in a case by case form?
Because it works. Not only does it work, it makes sense. That's one of the nice things about `auto[]`: based solely on the rules of structured binding, it does exactly what you want.
Indeed, as I think about it, if we ever wanted structured binding to be able to not capture all of the elements, we wouldn't want it to use placeholders. We would probably want `auto [x]` to bind to the first value of any tuple-like type. If that type has 30 variables in it, I don't care; I just want the first one. I shouldn't have to do `auto [x, @, @, @]` or even `auto [x, ...]` or whatever. I said that I wanted the first member, so give it to me.
Given that, `auto []` would bind to none of the values. Therefore, it would either be a compile error or it would work on anything, providing a hidden object that would be destroyed at the end of scope.
So really, I don't see this as a "case-by-case form". It's really the right way to go for both problems ;)
Hi Ricardo, maybe the topic name is improper. First, I'm advocating that if any special character
is to be used besides _ and __, which are already usable as indentifiers, then it would
not be possible to explicitly call member functions on them, they would simpler serve the purpose
of a placeholder name at declaration.
I like this idea of a placeholder variable name better than the current propositions. It's not the
same as truly anonymous for which you don't even give it a name at all, but it's better IMO.
I see no reason for tackling it solely by extending syntax of structure binding and missing the
oportunity for all the possible remaining usecases where the presence of a placeholder name would
solve it. A placeholder doesn't even need to tweak structure binding specification at all, it would be
solved as a consequence of a more general solution about variable naming.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dd3ec780-537c-4167-8947-4c23238554cf%40isocpp.org.
On Sun, Jul 10, 2016 at 11:28 PM, Tony V E <tvan...@gmail.com> wrote:
>
> We could solve each of these independently, but if #3 also solves #2 and #1 *coherently*, then I'd rather have a single solution.
>
> If a single solution is incoherent, then we shouldn't push it. But we need to explore it.
Let's say we use the keyword `register` as the placeholder
for the solution this thread is looking for, RAII will be written
as
auto register = lock_guard(lk);
Lengthy.
And structured binding will be
auto [a, register] = ...;
I want to "ignore", not *not* to ignore.
This way damages both use cases.
>
> I'm not sure solving any one problem is worth it on its own, but if you can solve all three (and more), then you have bang for the buck.
Instead, if we have
register lock_guard(lk);
and
auto [a, std::ignore] = expr;
Hmmm
Maybe we should reserve _ as unusable in structured binding for now?
Em segunda-feira, 11 de julho de 2016 08:20:02 UTC-3, Tony V E escreveu:Hmmm
Maybe we should reserve _ as unusable in structured binding for now?
I consider it a wise move.
Of the solutions presented, many of which I think are useful, I'm
still in favor os something along the lines of the language providing
a placeholder naming mechanism.
My main bias regarding that is because: as you have zero on counting,
on naming you have a placeholder. This is what happens in many other
programming languages, Python, Haskell, Rust, ...
I'd wish C++ moved on and embedded/learned that.
Can someone explain to me what this actually offers over{ std::lock_guard(whatever);// do stuff
}because I must be missing something, as right now, it just looks like adding a new keyword for no reason whatsoever, and eschewing a perfectly valid use of temporary blocks in the process. IOW, completely redundant and counterproductive.so i must've missed an undeniable benefit, right?
sorry, of course I meant to include a variable name in that declaration, e.g. a or b
template <class M, class F>
void with_lock(M& mtx, F f ) {
std::lock_guard _(mtx);
f();
}
with_lock(mtx, [&]{
// stuff locked here...
});
On 2016-07-10 16:33, Francisco Lopes wrote:
> By the way, fyi, the discussion referred by Ville tells about using __
> instead of _
I've probably said this before... what about `.`?
auto . = lock_guard(m_mutex);
Since `.` is not a valid identifier, there are no possible conflicts
with existing code. (Also, I think it looks slightly prettier :-).)
...`:` could be a candidate also...
I was going to propose a similar feature as described in this thread, fortunately, someone on slack mention this discussion thread, so I'll just post this here:https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md
[...]
I'm going to add a concrete example usecase to the document, but I'd like to get feedback on it so far...
auto = make_guard([]{ end_of_scope_action(); });
auto = []{ end_of_scope_action(); };
Auto( end_of_scope_action(); );
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ada9be6d-f9df-49ce-8fe8-641b049c874f%40isocpp.org.
Update:
auto [] = make_guard([]{ end_of_scope_action(); });
auto [] = make_guard([]{ ... });
auto {} = make_guard([]{ ... });
auto [{}, another] = make_pair(...);
auto&& {} = make_guard(...);
auto [{}, another] = make_pair(...);
auto [[], another] = make_pair(...);