Currently if there is an Add_Named defined in an Aggregate aspect, Add_Unnamed is not permitted (see RM 4.3.5(5/5)). This seems like an unnecessary restriction. In particular, the only ambiguity is in an aggregate of the form:
[for I in 1 .. 10 => expr]
whether Add_Named or Add_Unnamed would be used. It is pretty easy to argue that Add_Unnamed should be used here, and Add_Named would only be used if there were an explicit "use Key" present, as in:
[for I in 1 .. 10 use Key_Tab(I) => Val_Tab(I)]
By allowing both Add_Named and Add_Unnamed, it would be easier to define a type representing a heterogeneous structure like a JSON object, and Add_Named would be used to create a map-like object, while Add_Unnamed would be used to create an array-like object.
Currently if there is an Add_Named defined in an Aggregate aspect, Add_Unnamed is not permitted (see RM 4.3.5(5/5)). This seems like an unnecessary restriction. In particular, the only ambiguity is in an aggregate of the form:
[for I in 1 .. 10 => expr]whether Add_Named or Add_Unnamed would be used. It is pretty easy to argue that Add_Unnamed should be used here, and Add_Named would only be used if there were an explicit "use Key" present, as in:
[for I in 1 .. 10 use Key_Tab(I) => Val_Tab(I)]By allowing both Add_Named and Add_Unnamed, it would be easier to define a type representing a heterogeneous structure like a JSON object, and Add_Named would be used to create a map-like object, while Add_Unnamed would be used to create an array-like object.