Swift
This is a bit of a stretch. Bear with me.
The source MUST be encoded as UTF-16. Formatting the following as UTF-16:
swift.swift:1:1: error: input files must be encoded as UTF-8 instead of UTF-16
??^@s^@w^@i^@f^@t^@.^@s^@w^@i^@f^@t^@:^@1^@:^@1^@:^@ ^@e^@r^@r^@o^@r^@:^@^@i^@n^@p^@u^@t^@ ^@f^@i^@l^@e^@s^@ ^@m^@u^@s^@t^@ ^@b^@e^@\^@e^@n^@c^@o^@d^@e^@d^@ ^@a^@s^@ ^@U^@T^@F^@-^@8^@ ^@i^@n^@s^@t^@e^@a^@d^@ ^@o^@f^@ ^@U^@T^@F^@-^@1^@6^@
where ^@
is emacs-speak for an embedded NUL
and the ?
characters are genuine ASCII question marks. Outputting to console (cat
doesn't work, being ignorant of UTF16):
$ iconv -f utf-16 swift.swift
swift.swift:1:1: error: input files must be encoded as UTF-8 instead of UTF-16
??swift.swift:1:1: error: input files must be encoded as UTF-8 instead of UTF-16
and compiling:
$ swiftc swift.swift
We get:
swift.swift:1:1: error: input files must be encoded as UTF-8 instead of UTF-16
??swift.swift:1:1: error: input files must be encoded as UTF-8 instead of UTF-16
As desired.
CAVEATS:
- The terminal is taking the 16-bit header BOM
\xFF\xFE
in the error message from swiftc
and degrading it as ASCII ??
in the console.
- When the swift compiler is run in an Emacs shell, the terminal settings do not process the unprintable ASCII characters, instead rendering them in Octal.
- When the source is rendered in an Emacs buffer, which is UTF-16 aware, the first line appears correctly, and the ?? appears correctly, and but the remaining characters are shown interspersed with
NUL
literals rendered as ^@
.
cat
in the Terminal doesn't work either, being unaware of UTF-16.
- A UTF16-aware output utility is needed:
iconv -f utf-16 swift.swift
, where the terminal emulator subsequently discards the interspersed NUL
characters on the second line.
- In MacOS,
swiftc
leverages terminal capabilities to produce bold and color escape codes. To avoid this ambiguity, you can use export TERM=dumb
.
I'm claiming it's a quine as long as the source is rendered with a UTF-16 aware output utility and a terminal that discards ANSI formatting, NULs, and degrades unprintable characters to ?
.
USING TextEdit
You can also make a more visually convincing argument using ˛ˇ
in place of ??
where you keep the input as UTF-16 and let Swift output the (invalid) UTF-8 output with swiftc swift.swift > out 2>&1
and open out
in TextEdit. Side by side, the input and output indeed are rendered identically. No less dubious under the covers, but looks a lot less dubious.
So...when you say exactly identical, what exactly do you mean?
If the output must be re-usable as the input, the quine constraint is indeed violated. And if you argue it's OK to cycle the UTF8 compiler output back to UTF16 source, that seems promising, but doesn't work because the output of swiftc
is neither valid UTF-8 nor UTF-16: it is not valid to embed the BOM header midstream in either encoding. It's just terminal poo. Having fun yet?
It's an interesting foray into encoding and terminals, at the least!
Error: Could not find or load main class Q
\$\endgroup\$