[Development] Feature freeze exception for QTBUG-95587

[Shawn Rutledge]

> On 2021 Sep 9, at 17:32, Ulf Hermann <ulf.hermann at qt.io> wrote:
> 
> A user can fix this by explicitly calling Qt.resolvedUrl() in order to resolve the URL in a specific context and make it absolute. As we need URLs rather often in QML, we will see much more Qt.resolvedUrl() in Qt6 than we have seen in Qt5. As Qt.resolvedUrl() is quite a mouthful, there should be a shorthand for it: the '@' operator.

My first impression is that this looks like nice syntax.  However maybe we should discuss a bit how it fits into the language design, since it seems like we’re trying to have a cohesive language design nowadays.  I’m never quite sure to what extent QML is “our” language, or to what extent the rule is “just do what Javascript does”, and then we have to defer to ECMA standards, and common web-development practices (which I don’t know very much about).  But is there any precedent for this “@“ operator, for what it’s worth?

QML has this peculiarity of doing string conversion when binding to properties of specific types, like color: “#123” and point: “5,6” and vector3Prop: “5,6,7”.  Personally I prefer languages in which the syntax for type conversion is definable and extensible rather than being just a side effect of trying to shoehorn a string into some other type; but that’s what we have.  And another peculiarity is putting all those constructor functions into the Qt namespace, like Qt.rgba(), Qt.point(), Qt.vector3d() etc.  (This is probably even less intuitive for JS developers?)  If we were trying to design a language from scratch, without the baggage left from Qt 4, we’d probably be able to do better with the syntax for both of those, right?  But can we evolve toward something better now?

So now it seems like you are introducing a prefix operator on that string-shoehorning, which could potentially become a multi-purpose feature. It causes a bit of bias that this operator is pronounced “at”, so maybe the thought is it fits better with the sorts of conversions that imply some sense of “place”, either a geometric location or in a virtual space like the space of URLs and URIs?

We already have some string conversions in place, but if we define “@“ as giving that conversion some sort of “alternate” interpretation, in how many more contexts does that idea make sense?  Do we need an “alternate” way of converting colors, points, rectangles or something like that?  Or could the “@“ operator be even more general than that, sometimes being applied to other types than strings?  Maybe to convert Euler angles to a quaternion?  Radians to degrees?

If we use the “@“ operator for this-and-that over time, it would still be best if it retains some sort of language-wide cohesive meaning.  On the other hand, it seems a waste to introduce a nice single-character operator and only ever use it for _one_ purpose; of course that’s fine for a range of minor versions if it only does one thing, as long as we know how we can potentially go further with it.

Oh I just got another idea… if we had introduced units into QML (which we IMO should have), as in being able to specify Rectangle { width: 5mm }, we could think of URL resolution as another type of unit conversion; so then I suppose it should be some sort of postfix operator rather than prefix, like maybe Image { source: “my icon.png”csd } (if we define “csd” as meaning “component source directory”).  Using short words rather than punctuation would leave it more open to having several more such conversion operators rather than only one “alternate”.  OTOH I think @“my icon.png” looks nicer for this one usecase, considered alone.  In C++ we have a counter example with string-conversion tokens that are prefixes, as in u”string”.  And the even weirder ones with extra stuff on both ends, as in u"qtbase”_qs.

It’s just a question of which approach leads to more cohesion of the QML language as a whole, and which way is most intuitive for users (those who have mainly prior JS experience, and those who have Qt C++ experience).