Extending structured bindings to be more like variable declarations

[Nicolas Lesser]

This is a bit larger proposal than the last one. It proposes various clarifications and extensions to structured bindings that are currently disallowed or unclear, like `static, `inline`, `constexpr`, what their linkage is, and a bit more.

I even added some proposed wording, although as I'm not a language lawyer, it might be completely bad.

Any feedback welcome! :)

[Nicol Bolas]

I think there may have been a snafu in your attachment. It isn't HTML. Well, it tries to be ;) But it doesn't have the HTML headers and so forth. That makes it pretty difficult to read, at least in Firefox which renders it as plain text.

[Nicolas Lesser]

On Mon, Apr 30, 2018, 6:20 AM Nicol Bolas <jmck...@gmail.com> wrote:

I think there may have been a snafu in your attachment. It isn't HTML.

Well, it tries to be ;) But it doesn't have the HTML headers and so forth.

I think adding a html and body tag should be enough. It works on my machine both ways, but I don't know whether that's also true in your case.

That makes it pretty difficult to read, at least in Firefox which renders it as plain text.

You can have a look at the Markdown version instead, because I currently can't transform it into HTML.

https://github.com/Rakete1111/cpp-standards-proposals/blob/master/extending%20structured%20bindings%20to%20be%20more%20like%20variable%20declarations 

--
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/bfb83dce-0bf1-400a-a3ec-207aea4087e8%40isocpp.org.

[bastie...@gmail.com]

On Monday, April 30, 2018 at 9:49:30 AM UTC+2, Nicolas Lesser wrote:

On Mon, Apr 30, 2018, 6:20 AM Nicol Bolas <jmck...@gmail.com> wrote:

I think there may have been a snafu in your attachment. It isn't HTML.

Well, it tries to be ;) But it doesn't have the HTML headers and so forth.

I think adding a html and body tag should be enough. It works on my machine both ways, but I don't know whether that's also true in your case.

That makes it pretty difficult to read, at least in Firefox which renders it as plain text.

You can have a look at the Markdown version instead, because I currently can't transform it into HTML.

You didn't add the .md extension to the file the we have the same problem here 

[Nicolas Lesser]

On Tue, May 1, 2018 at 12:29 AM <bastie...@gmail.com> wrote:

On Monday, April 30, 2018 at 9:49:30 AM UTC+2, Nicolas Lesser wrote:

On Mon, Apr 30, 2018, 6:20 AM Nicol Bolas <jmck...@gmail.com> wrote:

I think there may have been a snafu in your attachment. It isn't HTML.

Well, it tries to be ;) But it doesn't have the HTML headers and so forth.

I think adding a html and body tag should be enough. It works on my machine both ways, but I don't know whether that's also true in your case.

That makes it pretty difficult to read, at least in Firefox which renders it as plain text.

You can have a look at the Markdown version instead, because I currently can't transform it into HTML.

You didn't add the .md extension to the file the we have the same problem here 

Whoops, fixed: https://github.com/Rakete1111/cpp-standards-proposals/blob/master/extending%20structured%20bindings%20to%20be%20more%20like%20variable%20declarations.md

 

https://github.com/Rakete1111/cpp-standards-proposals/blob/master/extending%20structured%20bindings%20to%20be%20more%20like%20variable%20declarations 

--
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/bfb83dce-0bf1-400a-a3ec-207aea4087e8%40isocpp.org.

--
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/60c5dff8-1cb4-4d15-a54e-198971cb7322%40isocpp.org.

[Alberto Barbati]

Il giorno domenica 29 aprile 2018 20:06:30 UTC+2, Nicolas Lesser ha scritto:

Any feedback welcome! :)

(Nitpicking) In the "constexpr" section, you say that "std::get<0>(__sb) is not a constant expression due to [expr.const]p6.2." The reference is slightly incorrect, since p6.2 is about prvalues of pointer type, but in this context std::get<0>(__sb) is a glvalue (by [expr.call]p14) and not of a pointer type. I'd simply write p6, instead.

By the way, I don't understand the rationale to drop the constexpr on the binding. Without the constexpr on the binding, you could end up calling a get<> accessor that is not marked constexpr and I'm not sure we actually want that. Do we? Is there anything else I'm missing?

Alberto

[Nicolas Lesser]

Thank you for your response! :)

On Wed, May 2, 2018, 8:47 AM Alberto Barbati <alberto...@gmail.com> wrote:

Il giorno domenica 29 aprile 2018 20:06:30 UTC+2, Nicolas Lesser ha scritto:

Any feedback welcome! :)

(Nitpicking) In the "constexpr" section, you say that "std::get<0>(__sb) is not a constant expression due to [expr.const]p6.2." The reference is slightly incorrect, since p6.2 is about prvalues of pointer type, but in this context std::get<0>(__sb) is a glvalue (by [expr.call]p14) and not of a pointer type. I'd simply write p6, instead.

True, will fix.

By the way, I don't understand the rationale to drop the constexpr on the binding.

This is was pretty controversial to everyone I told it to, because the reference would refer to a different object on each call.

Without the constexpr on the binding, you could end up calling a get<> accessor that is not marked constexpr and I'm not sure we actually want that.

Oops, I forgot this. I'll add it.

Do we?

No.

Is there anything else I'm missing?

Don't think so, but that's the reason I posted my proposal here.

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-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/f1239796-f394-4118-8e8a-3e82d7cf8c62%40isocpp.org.

[T. C.]

Since you are giving the underlying variable(s) external linkage, under what circumstances do two namespace-scope structured binding declarations in different TUs declare/define the same underlying variable(s)?

[Nicolas Lesser]

On Sun, May 6, 2018 at 2:08 PM T. C. <rs2...@gmail.com> wrote:

Since you are giving the underlying variable(s) external linkage, under what circumstances do two namespace-scope structured binding declarations in different TUs declare/define the same underlying variable(s)?

When the bindings are named the same and are in the same order, so an `inline` is needed to have only one definition, provided that the initializer is the same or else that would be an ODR violation.  I'll make that clear in the paper..

Apart from allowing a clean inline wording for SBs, I don't really see the point in doing so (as you can't name that underlying variable anyways). Maybe I'll change it.