!standard 6.6(5) 18-01-12 AC95-00303/00 !class Amendment 18-01-12 !status received no action 18-01-12 !status received 18-01-05 !subject Restricting overload of concatenation operator !summary !appendix !topic Restricting overload of concatenation operator !reference Ada 2012 RM6.6(172) !from Author John-Eric Söderman 18-01-05 !keywords &-operator concatenation container !discussion FROM RM4.5.3(119) The concatenation operators & are predefined for every nonlimited, one-dimensional array type T with component type C . They have the following specifications function "&"(Left : T; Right : T) return T function "&"(Left : T; Right : C) return T function "&"(Left : C; Right : T) return T function "&"(Left : C; Right : C) return T Extension to RM6.6 to legality rules after 5 { The concatenation operators & are predefined for every nonlimited, one-dimensional array type T with component type C (from RM4.5.3). A container type Y (A sub package of Ada.Containers or a type inherited from a sub package of Ada.Containers) with components type C. W stands for any type. Overloading of &-operator is restricted for types C, T and Y to function "&"(Left : C; Right : C) return T (in RM4.5.3) function "&"(Left : C; Right : T) return T (in RM4.5.3) function "&"(Left : C; Right : W) return T function "&"(Left : T; Right : C) return T (in RM4.5.3) function "&"(Left : T; Right : T) return T (in RM4.5.3) function "&"(Left : T; Right : W) return T function "&"(Left : Y; Right : W) return Y } By restricting Ada.Containers &-overloading makes it possible to code & & & & … and the result will be of the type of , except if is of C-type then the result will be an array of C, T-type. To get as result of Y-type you can code & & *************************************************************** From: Randy Brukardt Sent: Friday, January 5, 2017 9:10 PM He had previously tried to post a much longer version of this message, which was too big for the list. Perhaps it will help understand his request. Find it in the Grab-Bag at http://www.ada-auth.org/ai-files/grab_bag/JES-concat.pdf. *************************************************************** From: Randy Brukardt Sent: Friday, January 5, 2017 9:50 PM > !topic Restricting overload of concatenation operator > !reference Ada 2012 RM6.6(172) > !from Author John-Eric Söderman 18-01-05 > !keywords &-operator concatenation container > !discussion The reason that we (the ARG) always ask for clear problem definitions is so that we can evaluate both the problem (is it real, or just a misconception) and the proposed solution (does this really solve the problem, and is there a better way). I'm having a hard time figuring out what problem is supposedly being solved here. The only clue here seems to be in this statement: > By restricting Ada.Containers &-overloading makes it possible to code > & & & & ... > and the result will be of the type of , except if is of > C-type then the result will be an array of C, T-type. Given the standard rules for predefined "&", this is always true, and it would help a lot to know why JES thinks it is not true. I had hoped to get something from the paper, but it seems confused: > Facts and the standard > The “&” operator should result in an array type. Not really. Like any operator, it can result in anything that author wants it too. I've seen some pretty bizarre uses. Outside of the predefined uses of 4.5.3, ascribing too much semantics to any operator is going to get one into trouble. > Here are some not so clear questions > 1. if left argument is a non-array type and right argument is an array type > or a container type then the result should be an array type of the left > argument (and not a container type) "container type" here makes no sense. The only predefined container that defines any "&" operators is Vectors. A vector supposed to act as much as possible like an array, so it defines the same operators as an array would. If you do have a concatenation of a vector container to its element type, the result has to be a vector, as no matching array type is available in the generic. (What else could the result be in general?) > 2. if left argument is an array type and right argument is of the a array > type or a container type then the result should be of the same array type as > the left argument There are no such "&" defined by the container or anywhere else unless the container element type is an array type. In which case, returning an object of the array type would be nonsense (it would collapse many elements into one, which not what "&" means). >3. if left argument is a container type and right argument is of the a array > type or a container type then the result should be of the same container type > as the left argument Again, this can't happen unless the element type is of an array type, but here he has the correct answer. Apparently, his view of "&" isn't communitive?? > 4. the container types are not array types. Because you cannot specify > a simple array indexing to a container type (ct.Element(I) is not the same > as ct(I) ) Well, actually, the Vector container is supposed to be a close to an array as we can make it. The above is true, but only because ct.Element(I) is a constant while usually you can assign into ct(I)! Specifically, the Ada.Containers use the Constant_Indexing/Variable_Indexing aspects to define user-defined indexing for container types (specifically vectors). Ada 2020 may even add aggregates for Vector containers! The only array operations not allowed on a Vector container is slicing. --- Best I can figure, JES is running into some conflict when he has an array type and a vector type with the same element/component type and then uses (in a use clause) both. That hardly seems to be a new problem, in that the same thing happens if one defines two distinct array types with the same component type (again, with conflicting use clauses). The usual answer is to not do that! And incompatibly changing the operators available would potentially break many existing programs. That requires a pretty important problem to consider. But it's hard to tell how important the problem is as he didn't give any example of the problem he wants to solve. ***************************************************************