1. How does pattern matching solve the type safety of structured binding?

2. The proposal is of three parts that work together, these parts are of
limited value on their own.
How would you separate them?

3. Regarding the inline declaration:
If the named-tuple-concept repeats in an API then it should probably be a
named concept/type.

4. Regarding movability, the type is not movable nor copyable - it should
only be used as a prvalue until it is "unpacked".

On Wed, Feb 5, 2020 at 3:49 PM Михаил Найденов <mihailnajdenov_at_[hidden]>
wrote:

> These are 3 proposals in one.
>
> The first will be solved at some time after Pattern Matching. It will not
> be required, but should be possible to supply designators.
>
> The second and third. Much like types, you want to reuse your concepts, so
> inline declaration is of limited value,
> especially considering the concept will need more then you expressed with
> your syntax. For example - is the type copyable, movable etc?
>
>
> On Wed, Feb 5, 2020 at 2:54 PM Omer Rosler via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hi,
>> I've being working on the "dark side of structured binding" which are
>> inherently not type safe.
>> If you get the order wrong, and the arguments are of the same type, then
>> it is an error detectable only at runtime.
>>
>> The solution I propose is adding "named tuples" via anonymous concepts
>> and unnamed structs.
>>
>> In order to get the proposed semantics right, more use cases should be
>> considered and I look to this mailing list for help.
>>
>> The proposal draft is at
>> https://github.com/OmerRosler/named_tuples/tree/0.1
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>