原理主義的に C++ の文字列の扱いを根本から変えるにはどうするべきか

@Cryolite 納得した。その上で、新しい単位幅の文字列型に対しても歴史的なcharあるいはwchar_tとの整合を取るほうがよい(リテラルは配列)、と考えるので新しい要素型は必須という立場を取る。
2018-12-23 12:54:54
私の意味不明な主張に牛が納得しただと……!?!?!? (この後,「リテラルが wstring だと余計なコストが~」みたいな鋭いツッコミに対して「リテラルを表す特別な型を用意して何とか~」みたいなしどろもどろの防衛線が展開するはずだったのだが……)
2018-12-23 13:02:48
@Cryolite 原理主義なんだからwstringも今のbasic_stringじゃなくてもっとクールでスマートなやつでしょ
2018-12-23 13:04:40
@kikairoya いや,だって wchar_t[N] って wchar_t とほとんど何も変わらいんじゃ……
2018-12-23 13:07:12
@kikairoya あ,ごめん. ×「いや,だって wchar_t[N] って wchar_t とほとんど何も変わらいんじゃ……」 〇「いや,だって wchar_t[N] って wchar_t * とほとんど何も変わらいんじゃ……」
2018-12-23 13:08:37
むしろ江添さんや qiita.com/yumetodo/items… みたいな一見原理主義っぽい人たちが「『1文字』を表す型」にこだわるのが全く理解できないんだよな.本当に原理主義的に現在の C++ の文字列の扱いを根本から変えるなら明らかにそこじゃないでしょ,っていう.
2018-12-23 13:12:25
@kikairoya wchar_t[] を受け付けることを許した瞬間にほぼ無条件にすべてを受け付けてしまうので,「wchar_t[] のリテラル」のみを受け付けるまでしか妥協できない.
2018-12-23 13:16:52
なんか、そのレイヤーの仕事にC++使おうっていう方が間違いなんじゃないかなあ…っていう感想はある。何とは言わんが
2018-12-23 12:04:02
UTF-8 における「一文字」ってプリミティブで扱えるほど単純な概念ではないし、「文字列」を扱う中で陽炎のように現れる概念でしかなくて、その中の「一文字」に焦点をあてて扱おうと思うとすぐドツボにハマる、という認識なんだけれども
2018-12-23 12:15:06
「文字型」の「列」として「文字列型」が表せる、という発想が幻想だったのだ、というところを認めるところから始めないといけないのだけど、まあ既存の文字列型がその前提で組まれてると難しいよねえ、というのはわかる
2018-12-23 13:08:26
UTF-8の文字列をcode unitの配列として表現したいことがあるかどうかがポイントなんだろうか。なければchar_8tいらないってなっちゃいそう… twitter.com/Cryolite/statu…
2018-12-23 12:31:46
「UTF-8文字列である」というinvariantsは文字列のレベルで表現するべきで,「UTF-8のcode unitである」というinvariantsとして補償すべきものがほとんど何もないように思われるので,焦点はUTF-8文字列型をどう実装すべきかであり,UTF-8のcode unitをどう実装すべきかではないように思われる.
2018-12-23 10:25:53