Ich habe es gerade geschafft, mit Swift (Xcode 7.3; Swift 2.2) folgenden Compiler-Error zu erzeugen:


Das finde ich besonders humorvoll. Aus zwei Gründen.

1.) In Swift soll der Index in einem CollectionType ja gerade etwas anderes als ein völlig freischwebender Integer-Wert sein. Wieso sagt mir der Compiler dann, ich soll einen Index aus solch einem Integer erzeugen!?

2.) Foundation ist Objective-C basiert. Warum soll ich letztendlich Objective-C-API einbinden, um etwas anzusprechen, was es nur in Swift gibt!?

Vielleicht verstehe ich da auch was falsch, aber ich fand's gerade ganz amüsant. Das Problem im Code werde ich schon noch lösen...

Hat sonst jemand noch kurzweilige Compilermeldungen zu bieten..?

@ #1 Ich Dummerchen! Ich bin ja derjenige, der den Integer überhaupt erst ins Spiel gebracht hat. In Swift muß es natürlich (?) statt delimiter.utf16[0] delimiter.utf16[delimiter.utf16.startIndex] heißen. Wie konnte ich nur? Das ist ja viel klarer, prägnanter und... *reicht eine Tüte Ironie rum*

Gute Frage. An anderer Stelle brauche ich den zugrunde liegenden Codepoint als Zahlenwert. Da frage ich mich, ob der UTF16-View oder UnicodeScalars besser geeignet sind... Hier an dieser Stelle brauche ich das eigentlich noch nicht. Da könnte ich tatsächlich mit dem Character-View arbeiten.

Gibt es doch in gewisser Weise. Die value-Property eines UnicodeScalar-Typs liefert den unicode code point als UInt32 zurück.

Wo wir beim Thema UnicodeScalar waren...

Ich sehe gerade in der Swift-Doku:

typealias CWideChar = UnicodeScalar

The C++ 'wchar_t' type.

Interessant. Kannte ich auch noch nicht. Man lernt nie aus...

Da gibt es auch noch:

[*]typealias CChar16 = UInt16
[*]
The C++11 'char16_t' type, which has UTF-16 encoding.

[*]typealias CChar32 = UnicodeScalar
[*]
The C++11 'char32_t' type, which has UTF-32 encoding.

wchar_t war mir natürlich ein Beriff. Hallo!?
Diese typealias-Definitionen und Entsprechungen in Swift, die waren mir so aber noch nicht untergekommen. Ich dachte das paßt jetzt ganz gut, weil gritsch ja nach UTF-32 in Swift gefragt hatte.


PS: Wenn man sich mit Ostasiatischen Zeichen auseinandersetzt, dann kann man das 'auch nur' auch wieder... *seufz* mit CJK und Unicode läuft da irgendwas nicht so...

Ich dachte da mehr an sowas wie die Han-Vereinheitlichung (han unification).

Beispiel 海 (Japanisch 'umi', "Meer"):

In der 1. Tabelle des Links wird das Zeichen (U+6D77) je nach Sprache unterschiedlich interpretiert und dargestellt.

Im Quelltext sieht das dann so aus:
Ein und derselbe Codepoint. Wenn ich hier jetzt 海 schreibe, denke ich ans Japanische, aber wie es verstanden und dargestellt wird, hängt vom Browser und OS ab. Gut möglich, daß das bei vielen hier Chinesisch dargestellt wird. Auf Android ist m.W. Chinesisch Standard, früher dominierte allgemein Japanisch.

Was passiert nun, wenn ein Japanischer Text ein Chinesisches Zitat enthält? Ist es Aufgabe eines Strings, eine Sprachanalyse durchzuführen..? Bzw. wenn eine separate Analyse noch notwendig ist, erfüllt die Zeichenkette dann noch ihren Zweck?

In anderen Fällen haben die Zeichenvarianten ganz klar unterschiedliche Codepoints. Z.B. 計 (U+8A08) Japanisch und Traditionelles Chinesisch und 计 (U+8BA1) Vereinfachtes Chinesisch. Das sind die gleichen Zeichen, nur nicht die selben.

Bei 海 wirds absurd. Ich weiß zwar nicht, wie es vom Browser interpretiert und dargestellt wird, aber die Variante gibt es trotzdem noch als zusätzlichen Codepoint: 海 (U+FA45).

Das ganze ist durchaus ein Unicode Problem. Mal werden Zeichenvarianten unter dem selben Codepoint implizit als Sprachvarianten aufgefaßt und die Interpretation unterliegt dem Font, also der Darstellung. Manchmal sind Varianten explizit erfaßt. Und das Sahnehäubchen: Manchmal gibt's beides! Siehe 海. WTF!?

Klar. Das Problem entsteht, weil die Sprachen und die Zeichen der Sprachen so ihre Problematik mitbringen, aber ich bin mir sicher, man hätte es auch anders lösen können. Ich bin mir aber nicht sicher, ob dann noch 32 Bit ausgereicht hätten...