[Development] Feature freeze exception for QTBUG-95587
ulf.hermann at qt.io
Mon Sep 13 12:30:24 CEST 2021
>> 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
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).
> 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.
More information about the Development