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.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
