orange
さんがブースト
引数の位置での存在型は、 Interface や基底クラスと関数テーブルのようなものとかなり近く見えますね。
対して戻り値の位置では、 interface そのものを返すことはできない(と思う)し、基底クラスのポインタを返すにせよ「基底クラスのポインタである」という具体的な内部実装は漏れるわけです。
加えて、こういった実行時の多相だとオーバーヘッドが出てしまうけど、存在型ならユーザが名前を示せないだけでコンパイラは具体的な型を知っているので、実行時オーバーヘッドがない
orange
さんがブースト
典型的には「この関数は i64 のイテレータであるような何らかの型を返すことは保証するけど、それが具体的にどのような型であるかは教えたくないよ (i64 のイテレータであること以外の一切の保証を与えたくないよ)」というケースなどで有用。ある種のカプセル化、内部表現の隠蔽ですね
これ読みながら思ったのは、C# Delphi(?)/Java(?)で言う所のInterface・・・？＞＜（ぜんぜん違う？＞＜；）
型システムの理論からみるSwiftの存在型(Existential Type) - Qiita https://qiita.com/ukitaka/items/a993b5d7ed5ae84b1b52
orange
さんがブースト
「具体的に何であるかはユーザに教えたくないが、とにかく何らかの特徴を持つ何らかの型」という型指定を可能にするのが existential type (存在型) で、これは通常の generics における「どのような型についても○○」という全称型と対照的なものとされている
existential type、ぐぐったけどさっぱりわからんになった・・・＞＜
< 🕓そういえば最近気づいたけど、これDelphiっぽさ＞＜
WebRequest.Create Method (System.Net) | Microsoft Docs https://docs.microsoft.com/en-us/dotnet/api/system.net.webrequest.create?view=netframework-4.7.2
単語の短縮形、リーダブルコードとかではどの程度なら許容されてるのか謎＞＜
（例えばさっき話題になったRustのfnも、Pascal脳なので「functionって書けばいいじゃん！？＞＜」って思う＞＜（Pascal一族も短縮形使う部分それなりにあるけど＞＜；））
長すぎる名前のクラス、長すぎる名前のジェネリクスなクラスとの組み合わせになるとさらにとんでもない事になる＞＜；（なってる＞＜；）
最近、型安全に頼って安全にしようとして、名前だけでもミスに気づけるようにしようとした結果、ハンガリアン記法っぽい＆Objective-Cみたいなすごく長い名前になっちゃっててどうしようになっちゃってる＞＜
orange
さんがブースト
型が複雑になってきて手書きするのが面倒ってのもあることを思うと、そっちをなんとかするのがいいのかもな
エラーに気づけるのはなるべく早いほうがいいし、実行時までわからないよりはコンパイルするときにわかる方がいいし、出来ることなら書いてる途中で既にわかる方がいい＞＜
これすごく好き＞＜
orange
さんがブースト
いないないvar
最近の風潮＞＜
var hoge = 1.0;
オレンジ＞＜
double hoge = 1.0d;
（省略可能なのにヒューマンエラー検出用につけてるサフィックスはdoubleとfloatの時だけ＞＜）
狭いスコープの範囲（？）、C# では（極限られた部分で＞＜；）varって書いて、 IDE0008 で明示的な型に一括置換させるようになったから、オレンジのコードからvarが消えた＞＜
orange
さんがブースト
外部に公開される部分は型を明示して、狭いスコープでは推論させるみたいなの、最近ぼちぼち見かける
結局実際にコードに型が書いてなかったら人間から見たら同じじゃんってなる＞＜
（人間が型を推論しなきゃいけない状況が発生するのがすごくむかつく＞＜）
プログラミング言語、Rubyに似てるとかPythonに似てるって言われると、オレンジの場合それだけでかなり試す気が減る＞＜
あと、（最近の言語だいたいそうだけど）型推論が多用されてると「・・・・・・・＞＜」ってなる＞＜
- ＠orange_in_space
2017年 4月に登録
