Hi,
Thanks for taking the time out to write this! It seems like there is motivation, but I can't quite place my finger on it. If a variable isn't going to be used again, and can't be referenced, what are the benefits of its persistence have over `Foo{bar};`?
Cheers,
Chris
--
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/985b9b2a-c734-45eb-95f4-db4dc0d309a1%40isocpp.org.
On segunda-feira, 27 de março de 2017 13:27:11 PDT Alberto Barbati wrote:
> Hello,
>
> this is a draft for a proposal to add a special meaning to the identifier
> __ (double underscore) so that it can be used (even repeatedly in the same
> lexical scope) for all variables whose name is not important and that is no
> longer needed after declaration. The draft includes a few examples.
>
> Is there any interest in this?
Just remember that there are already existing codebases using __ as identifier
or macro names.
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/BTVwFqDkhXk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACL3gUVC1R9occL7vwiNTb9s4rD-%2Baemb4AprquTjQvr-xRjwg%40mail.gmail.com.
Em segunda-feira, 27 de março de 2017, às 23:47:55 PDT, Alberto Barbati
escreveu:
> > And yet it's in use.
> > https://github.com/v8/v8/blob/master/src/x64/codegen-x64.cc#L33
>
> Thanks Thiago for the pointer. According to my (possibly incorrect)
> interpretation this code raises undefined behavior because __ is reserved
> "for any use", which I would expect includes the use as a macro name. I may
> be wrong, but I'd expect little sympathy in the committee about potentially
> breaking it. By the way, this code might possibly not break, because they
> were clever to put #undefs in it. Incidentally, the code would indeed break
> if we defined __ to be a macro...
Right. We can say it's V8's own fault for using a reserved identifier. It's
like when Qt (qlalr) had an identifier called _Nullable, but that got
repurposed by a recent Clang change.
I'm just saying it's known to be in use in a fairly major project. You know,
the one that is behind Node.js and a whole ecosystem. The argument in the
paper that says it's little used is incorrect: it's not like pre-C++11 "auto",
which had exactly one use in the entire Microsoft source code.
I guess we could convince GCC and Clang to print a warning about it if it
looks like this is going forward, so the V8 developers start fixing it. Maybe
we'll get some of these fixed too:
http://lxr.free-electrons.com/source/include/linux/compiler.h#L115
http://lxr.free-electrons.com/source/include/asm-generic/fixmap.h#L73
However I believe P0577 does not address the issue of decomposition declaration
--
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/985b9b2a-c734-45eb-95f4-db4dc0d309a1%40isocpp.org.
just like std::ignore, I don't expect __ here
> to issue a call to get(obj), nor an access to a subobject.
> I don't think the *preserving* semantics can fulfill the
> *ignoring* demand.
It has no difference, because the structured binding is actually a *binding*,
so there's difference to object creation or retention. The result from
get_tuple is assigned to an anonymous object and all its members are retained.
Then it's decomposed into two elements: an anonymous one (can't be accessed)
and a.
On Tue, Mar 28, 2017 at 11:43 AM, Thiago Macieira <thi...@macieira.org> wrote:just like std::ignore, I don't expect __ here
> to issue a call to get(obj), nor an access to a subobject.
> I don't think the *preserving* semantics can fulfill the
> *ignoring* demand.
It has no difference, because the structured binding is actually a *binding*,
so there's difference to object creation or retention. The result from
get_tuple is assigned to an anonymous object and all its members are retained.
Then it's decomposed into two elements: an anonymous one (can't be accessed)
and a.
Whether a call to get<0>(anon) being made
certainly has difference, because it can have
observable effect. And, just like I showedin a previous discussion, the purpose of the
anonymous object is for decomposition. If
nothing is decomposition it, it needs not to be
created, thereforeauto [__, __] = get_tuple(...);should be physically equivalent toget_tuple(...);thus, the result object is dropped on the floor.
On segunda-feira, 27 de março de 2017 15:16:58 PDT 'Jeffrey Yasskin' via ISO C
++ Standard - Future Proposals wrote:
> > Just remember that there are already existing codebases using __ as
> > identifier
> > or macro names.
>
> They're not allowed. "_" is ok outside of the global namespace, but "__" is
> reserved by [lex.name].
I know it is.
And yet it's in use.
https://github.com/v8/v8/blob/master/src/x64/codegen-x64.cc#L33
auto [__, name] = expr;
On terça-feira, 28 de março de 2017 02:09:54 PDT Alberto Barbati wrote:In this particular instance, V8's programmer could and probably should haveused a non-reserved name (for example "m_" would have been a better choiceregardless). Even the choice of _Nullable was ill-conceived, sinceidentifiers beginning with an underscore and an uppercase letter are alsoreserved.
The reason for __ is that it looks unintrusive, which allows for code
generation in a way that is easy to read:
// Fetch the instance type of the receiver into result register.
__ movp(result, FieldOperand(string, HeapObject::kMapOffset));
__ movzxbl(result, FieldOperand(result, Map::kInstanceTypeOffset));
On Tue, Mar 28, 2017 at 4:23 AM, Alberto Barbati <alberto...@gmail.com> wrote:However I believe P0577 does not address the issue of decomposition declarationBecause these two "use cases" imply different semantics.When you writeauto __ = lock_guard(m);here you mean to *preserve* the result object, but when
you writeauto [__, a] = get_tuple(...);you mean to *ignore* a part of the result object, so
physically, just like std::ignore, I don't expect __ here
to issue a call to get(obj), nor an access to a subobject.
I don't think the *preserving* semantics can fulfill the
*ignoring* demand.
On Tuesday, March 28, 2017 at 1:29:57 PM UTC-4, Matthew Woehlke wrote:On 2017-03-28 13:03, Thiago Macieira wrote:
> On terça-feira, 28 de março de 2017 09:53:51 PDT Zhihao Yuan wrote:
>> auto [__, __] = get_tuple(...);
>>
>> should be physically equivalent to
>>
>> get_tuple(...);
>>
>> thus, the result object is dropped on the floor.
>
> This should be equivalent to:
>
> auto __ = get_tuple(...);
I would argue it should be equivalent to:
auto __magic__ = get_tuple(...); // note: same as today
auto __ = get<0>(__magic__);
auto __ = get<1>(__magic__);
...so that in case of side effects, there is no observable behavior
difference. (The compiler is free to elide bits of the above if there
are provably no side effects.)
This almost makes me think we need "unnamed" and "ignored" to be
implemented separately :'(...
The question is this: will people actually want side effects of ignored parameters? Or more to the point, why exactly would you want those side effects?
I can't think of a case of a type that is decomposable where the decomposition `get` function has side effects. Well, with one exception: variant types. And the side effect there is that you get a thrown exception.
The decomposition case I think would be best solved by allowing empty and
nested declarations. See
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gg3_eUhCuqo/HcippDFiBgAJ
and following posts in the thread. This would let you write:
auto [] = get_lock(); // no name
auto [x, [], y] = get_tuple(); // middle element is unnamed
auto [x, [a, b], y] = get_tuple(); // nested decomposition
Both solve the simple case, but both also have additional but
non-overlapping usefulness. I'm inclined to think that both are useful.
auto [[a, b], c] = get_tuple();
Instead of __, I'd propose using ?. For example auto ? = scope_guard{...}. ? isn't allowed in identifiers so it shouldn't conflict with existing nonconformant code. ? is also shorter :)
On terça-feira, 28 de março de 2017 09:53:51 PDT Zhihao Yuan wrote:
> Whether a call to get<0>(anon) being made
> certainly has difference, because it can have
> observable effect.
It does not, so it cannot have an observable effect.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2235919.4GAIbDEcRC%40tjmaciei-mobl1.
Wouldn't it be much better to have a concept of Context?
Wouldn't it be much better to have a concept of Context? I am taking inspiration from python (I know they use it for RAII, but that is a different discussion).The code might look like:
void foo() {// do stuff
with (unique_lock{mutex}) {// critical code}// other stuff}
Then, for prettiness and to avoid unnecessary indentations, when the Context extends till the end of the parent scope, it can just be a declaration:void foo() {with unique_lock{mutex};// critical code}You can also nest Contexts:void foo() {with unique_lock{mutex1};with unique_lock{mutex2};// etc}Also, by having a proper concept of Context, compilers and static analysis tools would have more information available.
I don't know about the decomposition side of things, but perhaps using, say @ instead? But I have to admit I still haven't understood the difference with std::ignore (perhaps I have homework to do):auto [x, @, z] = expr;
--
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/3760122.IY8cFr858X%40tjmaciei-mobl1.
Ah. But I forgot now that with structured binding there's a hidden local variable anyway for the tuple itself. I was thinking the compiler was smart and applied RVO to the individual elements directly.
Hello,
this is a draft for a proposal to add a special meaning to the identifier __ (double underscore) so that it can be used (even repeatedly in the same lexical scope) for all variables whose name is not important and that is no longer needed after declaration. The draft includes a few examples.
Is there any interest in this?
Thanks in advance,
Alberto
--
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/985b9b2a-c734-45eb-95f4-db4dc0d309a1%40isocpp.org.
On sábado, 1 de abril de 2017 21:19:37 PDT Richard Smith wrote:
> Have you considered that possibility? It would give a better name (_ rather
> than __) and avoid "breaking" existing code that uses __.
_ is not reserved to the compiler and is VERY often #defined to gettext.
Let's use __.
At least we can point to V8 developers and tell them it's their
own fault.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/1491170458.9U0G8TLsOk%40tjmaciei-mobl1.
On 2 April 2017 at 11:03, Thiago Macieira <thi...@macieira.org> wrote:On sábado, 1 de abril de 2017 21:19:37 PDT Richard Smith wrote:
> Have you considered that possibility? It would give a better name (_ rather
> than __) and avoid "breaking" existing code that uses __.
_ is not reserved to the compiler and is VERY often #defined to gettext.Only as a function-like macro.Let's use __.Let's use the thing that works best for C++, sure. I am not (yet) convinced that's __.
namespace foo
{
constexpr int _ = 20;
}
__ seems somewhat safer and less controversial.
On Sunday, April 2, 2017 at 3:28:54 PM UTC-4, Richard Smith wrote:On 2 April 2017 at 11:03, Thiago Macieira <thi...@macieira.org> wrote:On sábado, 1 de abril de 2017 21:19:37 PDT Richard Smith wrote:
> Have you considered that possibility? It would give a better name (_ rather
> than __) and avoid "breaking" existing code that uses __.
_ is not reserved to the compiler and is VERY often #defined to gettext.Only as a function-like macro.Let's use __.Let's use the thing that works best for C++, sure. I am not (yet) convinced that's __.
Well, let's look at the options.
You can't use nothing; that would create parsing ambiguities. So you have to put something there: either an identifier or something that is not an identifier.
If it is not an identifier, then it must be a keyword (new or old) or some form of punctuation. Adding a new keyword for something like this is rather silly. And I don't know of an old keyword that would make for a good placeholder.
You could use `[]` as I once suggested, piggybacking off of structured binding rules. But most other punctuation would be confusing or otherwise unexpected in a variable declaration.
If it is an identifier, then it must be a reserved identifier, to minimize code breakage when we change its meaning.
The shortest reserved identifier is `_`, which is currently reserved for use by the implementation, but only for names in the global namespace. Which means that right now, this is 100% legal:
namespace foo
{
constexpr int _ = 20;
}
So changing the meaning of that code is a non-starter.
The second shortest reserved identifiers are of the form `_*`, where `*` is an uppercase letter or `_`. These are reserved by the implementation for any use. And implementations are more easily changed than user code.
So from my perspective, `__` is the most viable identifier.
--
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/10c2c556-b6bb-4714-83bc-7b0ac8fd4143%40isocpp.org.
Il giorno 02 apr 2017, alle ore 22:10, Richard Smith <ric...@metafoo.co.uk> ha scritto:On 2 April 2017 at 12:56, Alberto Barbati <alberto...@gmail.com> wrote:Il giorno 02 apr 2017, alle ore 20:03, Thiago Macieira <thi...@macieira.org> ha scritto:
>> On sábado, 1 de abril de 2017 21:19:37 PDT Richard Smith wrote:
>> Have you considered that possibility? It would give a better name (_ rather
>> than __) and avoid "breaking" existing code that uses __.
>
> _ is not reserved to the compiler and is VERY often #defined to gettext.
Thank you Richard for your suggestion which is very interesting, since it provides good insights about a possible wording. As for the name, I believe Thiago and Magnus raised valid concerns, though. It's true that the we might choose _ without breaking existing code. However defining _ as a macro is currently valid and apparently widely used. I believe we therefore have only two choices: either we make such uses undefined behavior (upsetting a lot of people) or we choose wording to avoid that (making the feature essentially unusable for users of all libraries like gettext). None of the two approaches seems very good. Is there a third option?As noted, gettext defines _ as a function-like macro, so there seems to be no technical problem for users of gettext (although some might consider overloading the meaning of _ in this way to be a readability problem).
__ seems somewhat safer and less controversial.I would expect you'll find controversy if you pick a worse name in order to avoid collision with a macro name that some would already consider to be poorly chosen, so I don't think it's clear which will be less controversial.
On 2 April 2017 at 12:45, Nicol Bolas <jmck...@gmail.com> wrote:On Sunday, April 2, 2017 at 3:28:54 PM UTC-4, Richard Smith wrote:On 2 April 2017 at 11:03, Thiago Macieira <thi...@macieira.org> wrote:On sábado, 1 de abril de 2017 21:19:37 PDT Richard Smith wrote:
> Have you considered that possibility? It would give a better name (_ rather
> than __) and avoid "breaking" existing code that uses __.
_ is not reserved to the compiler and is VERY often #defined to gettext.Only as a function-like macro.Let's use __.Let's use the thing that works best for C++, sure. I am not (yet) convinced that's __.
Well, let's look at the options.
You can't use nothing; that would create parsing ambiguities. So you have to put something there: either an identifier or something that is not an identifier.
If it is not an identifier, then it must be a keyword (new or old) or some form of punctuation. Adding a new keyword for something like this is rather silly. And I don't know of an old keyword that would make for a good placeholder.
You could use `[]` as I once suggested, piggybacking off of structured binding rules. But most other punctuation would be confusing or otherwise unexpected in a variable declaration.
If it is an identifier, then it must be a reserved identifier, to minimize code breakage when we change its meaning.As I pointed out, this is an incorrect conclusion. There is no necessity for any code breakage here, and there is no need to pick a reserved identifier: the core functionality of this proposal does not require that the identifier be unusable within its scope, and if we don't add that restriction, this is strictly an extension.
On 2 April 2017 at 12:56, Alberto Barbati <alberto...@gmail.com> wrote:Il giorno 02 apr 2017, alle ore 20:03, Thiago Macieira <thi...@macieira.org> ha scritto:
>> On sábado, 1 de abril de 2017 21:19:37 PDT Richard Smith wrote:
>> Have you considered that possibility? It would give a better name (_ rather
>> than __) and avoid "breaking" existing code that uses __.
>
> _ is not reserved to the compiler and is VERY often #defined to gettext.
Thank you Richard for your suggestion which is very interesting, since it provides good insights about a possible wording. As for the name, I believe Thiago and Magnus raised valid concerns, though. It's true that the we might choose _ without breaking existing code. However defining _ as a macro is currently valid and apparently widely used. I believe we therefore have only two choices: either we make such uses undefined behavior (upsetting a lot of people) or we choose wording to avoid that (making the feature essentially unusable for users of all libraries like gettext). None of the two approaches seems very good. Is there a third option?As noted, gettext defines _ as a function-like macro, so there seems to be no technical problem for users of gettext (although some might consider overloading the meaning of _ in this way to be a readability problem).
namespace Name
{
int _ = 5;
};
__ seems somewhat safer and less controversial.I would expect you'll find controversy if you pick a worse name in order to avoid collision with a macro name that some would already consider to be poorly chosen, so I don't think it's clear which will be less controversial.
If it is an identifier, then it must be a reserved identifier, to minimize code breakage when we change its meaning.As I pointed out, this is an incorrect conclusion. There is no necessity for any code breakage here, and there is no need to pick a reserved identifier: the core functionality of this proposal does not require that the identifier be unusable within its scope, and if we don't add that restriction, this is strictly an extension.
On Monday, April 3, 2017 at 3:55:16 PM UTC-4, Matthew Woehlke wrote:
unique_lock auto {lock};
unique_lock default {lock};
This proposal is about having a scope-bound object which cannot be later referenced, which has a name that is generated by the compiler. That's what the proposal is for: "for all variables whose name is not important and that is no longer needed after declaration".
This proposal is about having a scope-bound object which cannot be later referenced, which has a name that is generated by the compiler. That's what the proposal is for: "for all variables whose name is not important and that is no longer needed after declaration".Sorry to have left the thread for so long. After some pondering, although the __ approach is still on the table, I have decided to explore a bit further other options that do not require reserving an identifier, in particular the one suggested by Nicol Bolas. The fact is that I realized C++17 already has a tool that creates an object that cannot be referenced... that tool is decomposition declaration itself. With just three tweaks, which would make for a pure extension, we can achieve both goals of my proposal.Tweak #1Allow identifiers in a decomposition declaration to be omitted. So inauto [x, , z] = func();the second element is not named so the corresponding element needs not be bound and get<1>() is guaranteed not to be called (however, we might still check that it might have been called, for consistency).This tweak alone solves goal #2 of the proposal and is probably more elegant: since there's no name, there's little room for misunderstanding about the semantic.