This looks good to me. I would like to phrase the new rules as defining what is provided by the implementation by default. Ditto about the phrasing of record assignment in the spec.
IMO the users are welcome to add whatever assignment operators they please. Also, if the user declares a proc =(ref a:R, b:R), it should replace the compiler-generated one. Vass On 04/09/14 10:46, Tom Hildebrandt wrote: > All: > > Please consider and comment on the following proposed language change. > > Thanks, > Tom Hildebrandt > > > STATUS QUO > --------------- > Currently, the Chapel compiler automatically generates an implementation of > assignment for each record type defined in the input (including internal > modules and any standard modules used). The signature for each of these > assignments is > > proc =(ref a:R, b) > > where R is the type of the LHS argument. As you can see, the type of the RHS > argument is unconstrained. This is to support the semantics currently > described in the specification, in which assignment between two objects of > arbitrary record type is accomplished through a field-by-field copy where the > fields are selected by name. The layouts of the two records must be > compatible to the extent that assignment of like-named fields from the type > of the right-hand operand to the type of the left-hand operand is a legal > assignment. If not, a compile-time error is issued. > > Unfortunately, the above signature allows 'b' to bind to 'nil' and other > objects of class type. Since 'nil' cannot be assigned to a variable of > record type, that case must be captured explicitly and flagged as an error. > > PROPOSED CHANGE > ----------------------- > The implementation would be simplified somewhat if the above signature were > replaced with one that constrains the right-hand argument to be of the same > type as the left-hand argument: > > proc =(ref a:R, b:R) > > In that case, the operand on the right-hand side of a record assignment must > be coercible to the type of the left-hand operand. Since 'nil' cannot be > coerced to a record type, that case is automatically rejected. This proposal > would also reject the proposed support for assignment from class objects to > record object described in Section 16.9.2 in the specification. That section > would be removed. > > This change would mean that records were only assignment-compatible if the > right-hand operand is coercible to the type of the left-hand operand. Unless > a user-defined cast is supplied, the supported coercions are only from a > derived record type to a base record type. Field-wise (by name) assignment > between unrelated record types would be specifically prohibited. As an > example, the proposed change would cause the test case > $CHPL_HOME/test/classes/bradc/records/assignRecord3.chpl to fail. > > Aside from simplifying the implementation, the proposed change also enables > an optimization. When records are in the same inheritance hierarchy, the > implementation can arrange that they are layout-compatible. In that case, > the implementation can replace trivial assignment (assignments having no > side-effects) with the equivalent of a memcpy() call. > > Since assignment between class objects is already constrained in this way, > the proposed implementation brings the definition of record types and class > types into closer alignment. That can help programmers to understand and use > both classes and records effectively. Arguably, permitting assignment > between objects of unrelated record types could be confusing. However, the > likelihood of this is small, since resolution of the assignment will fail if > the type of the right-hand operand does not have fields with names covering > all the fields in the left-hand operand, and all of those assignments must be > valid. > > A further argument in favor of the change is that it appears this feature is > not relied upon, at least within the Chapel development team. Only the one > test case mentioned above fails due to the proposed change. > > PROS > ------ > * Simplifies the conceptual model > * Simplifies the implementation > * Enables the "trivial assignment" optimization > * Has limited negative impact > > CONS > ------ > * Eliminates field-by-field (by name) assignment between objects of unrelated > record types > * Eliminates the proposed class object to record object assignment semantics > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > > > > _______________________________________________ > Chapel-developers mailing list > Chapel-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/chapel-developers > ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Chapel-developers mailing list Chapel-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/chapel-developers
