Dave Mitchell wrote: >The more I think about this, the more I think that attributes should >be allowed in *either* position, with a warning or croak for specific >attributes found in the "wrong" location: That would be a bad idea. Although it would make it possible to put :lvalue in the right place, possibility isn't enough. The idea has most of the other downsides of signatures preceding attributes. It still breaks the attribute abstraction, by forcing a visible distinction between attributes that are permitted to follow signatures and those that are not. This distinction would have to be documented, and remembered by programmers, who would no longer be able to just compose features in an orthogonal manner. Any attribute that has been classed as permitted to follow a signature would be barred from ever being reimplemented in a way that alters compilation of ordinary code. That kind of reimplementation is an option that is otherwise open to attributes. In the likely event that we later want to apply non-core attributes early enough to affect body compilation, of course non-core attributes would labour under these same burdens. But further, we'd have to introduce some extra API for non-core attributes to declare which category they fall into. Under these conditions, we couldn't really say that signatures were playing nicely with the existing stable feature of the :lvalue attribute. They would certainly be impeding likely future developments. This could bar the blessing of signatures, in that form, as a stable feature. Relative to the present situation of having signatures after all attributes, the proposal for double helpings of attributes has only one advantage, namely compatibility with the 5.22-5.26 version of signatures. There certainly would be some benefit there, but it's quite limited, because the compatibility is only with an experimental feature (marked as such) in its early releases. The same kind of compatibility benefit with respect to 5.20 didn't dissuade people from moving signatures into the wrong place for 5.22. In this case, we must weigh against this temporary gain the permanent damage that dual location would do to attributes, as described above. The balancing exercise is easy: compatibility that was disclaimed can't outweigh long-term language coherence. It is fortunate that we had the formalised concept of experimental features in time for signatures, in order to make it this easy. -zeframThread Previous | Thread Next