[Development] Feature freeze exception for QTBUG-95587

[Ulf Hermann]

>> However, if we nail down the meaning of @"string" to "create and
>> resolve a URL", then we cannot use a plain '@' for much else.
>>
> it would be kinda logical for @ applied to a structure to mean resolving
> all urls inside it, which would be a clear clash with
> https://bugreports.qt.io/browse/QBS-58 (i was once told that this would
> be interesting for declaring state machines in quick as well).

The way it's implemented now, it only reacts to types that can easily be 
converted to url. That is strings, QVariant of QUrl, and the JavaScript 
URL object. Furthermore, I've added provisions that allow specific 
semantics for '@' to be specified via a prefix in the future. Plain '@' 
is now a shorthand for 'url@'. So, QBS could define a 'str@' or similar 
to do its array thing, or even give '@' a special meaning for arrays of 
strings (_that_ sounds a bit wasteful, though).

See https://codereview.qt-project.org/c/qt/qtdeclarative/+/369987

> the @ is about the only punctuation char that has no syntactical meaning
> in js (or at least didn't when i checked last time), so it does seem
> perfect for language extensions, and therefore a waste to use for just
> a single thing.

With the prefixes we retain the capability for generic extension of the 
language. I would still like to make '@' a shorthand for 'url@' so that 
people actually use it.

> specifically for urls, one could do something more extreme to limit the
> impact on the "syntax space", e.g., use @<url>, i.e., replace the
> quotation chars as well. of course, this may be even more confusing for
> tooling that doesn't natively speak the new qml version.

It should not only work for literals, but also for other expressions. 
Therefore, special quotes won't do.