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

文字型の列として文字列型が表せるというのは幻想であるが,しかしその幻想は歴史という重みを伴って現にそこに存在する.
27
対鉱物用武装 @kikairoya

@Cryolite 納得した。その上で、新しい単位幅の文字列型に対しても歴史的なcharあるいはwchar_tとの整合を取るほうがよい(リテラルは配列)、と考えるので新しい要素型は必須という立場を取る。

2018-12-23 12:54:54
対鉱物用武装 @kikairoya

@Cryolite (そこを崩すときっとPython3になるから。。。)

2018-12-23 12:56:36
Akso de la Malbono @Cryolite

私の意味不明な主張に牛が納得しただと……!?!?!? (この後,「リテラルが wstring だと余計なコストが~」みたいな鋭いツッコミに対して「リテラルを表す特別な型を用意して何とか~」みたいなしどろもどろの防衛線が展開するはずだったのだが……)

2018-12-23 13:02:48
対鉱物用武装 @kikairoya

「1文字」を表す型はたぶん無いほうがよいんだけども、歴史が許してくれない

2018-12-23 13:03:02
対鉱物用武装 @kikairoya

@Cryolite 主張は納得したが賛同はしません。

2018-12-23 13:03:26
対鉱物用武装 @kikairoya

@Cryolite 原理主義なんだからwstringも今のbasic_stringじゃなくてもっとクールでスマートなやつでしょ

2018-12-23 13:04:40
対鉱物用武装 @kikairoya

@Cryolite 原理主義から一歩譲ってL"hoge"がwchar_t[]であることに妥協するとどうなる?

2018-12-23 13:05:49
Akso de la Malbono @Cryolite

@kikairoya まあ,牛ならそこまで先を読んでくれた上で納得したんだと思ってましたが.

2018-12-23 13:05:55
対鉱物用武装 @kikairoya

@Cryolite クールでスマートなwstringの実装待ってます

2018-12-23 13:06:36
Akso de la Malbono @Cryolite

@kikairoya いや,だって wchar_t[N] って wchar_t とほとんど何も変わらいんじゃ……

2018-12-23 13:07:12
Akso de la Malbono @Cryolite

@kikairoya あ,ごめん. ×「いや,だって wchar_t[N] って wchar_t とほとんど何も変わらいんじゃ……」 〇「いや,だって wchar_t[N] って wchar_t * とほとんど何も変わらいんじゃ……」

2018-12-23 13:08:37
Akso de la Malbono @Cryolite

むしろ江添さんや qiita.com/yumetodo/items… みたいな一見原理主義っぽい人たちが「『1文字』を表す型」にこだわるのが全く理解できないんだよな.本当に原理主義的に現在の C++ の文字列の扱いを根本から変えるなら明らかにそこじゃないでしょ,っていう.

2018-12-23 13:12:25
対鉱物用武装 @kikairoya

(特にUnicodeの文脈では)「1文字」がどういう意味なのかがそもそも難しい

2018-12-23 13:15:43
対鉱物用武装 @kikairoya

ので、文字型に(ただの配列である)文字列リテラルの(数値の配列と区別するための)要素型以上の意味を期待していない

2018-12-23 13:16:27
Akso de la Malbono @Cryolite

@kikairoya wchar_t[] を受け付けることを許した瞬間にほぼ無条件にすべてを受け付けてしまうので,「wchar_t[] のリテラル」のみを受け付けるまでしか妥協できない.

2018-12-23 13:16:52
Dai MIKURUBE @dmikurube

なんか、そのレイヤーの仕事にC++使おうっていう方が間違いなんじゃないかなあ…っていう感想はある。何とは言わんが

2018-12-23 12:04:02
Dai MIKURUBE @dmikurube

UTF-8 における「一文字」ってプリミティブで扱えるほど単純な概念ではないし、「文字列」を扱う中で陽炎のように現れる概念でしかなくて、その中の「一文字」に焦点をあてて扱おうと思うとすぐドツボにハマる、という認識なんだけれども

2018-12-23 12:15:06
Dai MIKURUBE @dmikurube

RubyでいうCSI的な概念の方が、そのレイヤーにはよく合うと思うんだよなー

2018-12-23 12:25:22
Dai MIKURUBE @dmikurube

「文字型」の「列」として「文字列型」が表せる、という発想が幻想だったのだ、というところを認めるところから始めないといけないのだけど、まあ既存の文字列型がその前提で組まれてると難しいよねえ、というのはわかる

2018-12-23 13:08:26
mitsutaka.takeda @MitsutakaTakeda

UTF-8の文字列をcode unitの配列として表現したいことがあるかどうかがポイントなんだろうか。なければchar_8tいらないってなっちゃいそう… twitter.com/Cryolite/statu…

2018-12-23 12:31:46
Akso de la Malbono @Cryolite

「UTF-8文字列である」というinvariantsは文字列のレベルで表現するべきで,「UTF-8のcode unitである」というinvariantsとして補償すべきものがほとんど何もないように思われるので,焦点はUTF-8文字列型をどう実装すべきかであり,UTF-8のcode unitをどう実装すべきかではないように思われる.

2018-12-23 10:25:53