TypeScript part3

1 ：デフォルトの名無しさん：2018/04/26(木) 21:48:23.07 ID:mMDBzDaB.net

http://www.typescriptlang.org/

JavaScript that scales.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

part1
https://peace.5ch.net/test/read.cgi/tech/1349187527/
part2
https://mevius.5ch.net/test/read.cgi/tech/1430386649/

896 ：デフォルトの名無しさん：2021/11/18(木) 13:22:17.68 ID:In+gpp4R.net

根本的な勘違いとして、それはTypeScriptの責務では無い。TypeScriptはJavaScriptにモダンな型を付与するもの（一部例外はある）で、APIの提供はしない。
例に出てきたFileReaderの様なAPIはブラウザとNode側で求められる機能もセキュリティレベルも異なり、それぞれが提供するものだ。それを統一はできない。ましてnpmのバッケージで提供されているものはパッケージ作者が責務を負うものだ。
自分の勉強不足を棚に上げて言語に文句を言うのは筋違いも良いとこ。

897 ：デフォルトの名無しさん：2021/11/18(木) 14:09:39.19 ID:3dlOBCKi.net

そこがTSの限界であり、使いにくい原因なんだろなぁ

FileReaderなんてのはたまたま出てきた一例でしかないが
リンク先のポストを読めば、トピ主のやりたいことはストリームから文字列への変換とわかるだろう

その程度はどのプラットフォームでもサポートできる
使用頻度もそこそこだから、標準ライブラリとして用意されていて当たり前

encode(s: string, format: string): Blob
decode(b: Blob, format: string): string

これでいいだろ？
セキュリティやハードウェアに依存するものが標準化されないのは許されるだろう
しかしなぜ簡単にできるものすら標準化しない？

898 ：デフォルトの名無しさん：2021/11/18(木) 16:35:20.00 ID:In+gpp4R.net

そのストリームってのは何のストリーム？
ひょっとして用語を間違えてるから調べても出てこないのでは？

899 ：デフォルトの名無しさん：2021/11/19(金) 07:13:45.00 ID:UKAZMSSR.net

>>893
型演算に末尾再帰最適化（みたいなの）追加されるやん！

900 ：デフォルトの名無しさん：2021/11/21(日) 12:03:30.92 ID:lhVIl0/s.net

型の@types だけインポートするにはどうしたらよいでしょうか。

leafletという地図のjsライブラリがあって、グローバルでL という変数をnamespaceとして使っています。
npmの層を薄くしたくて、地図ライブラリはnpm を使わずにhtmlにscriptタグを直接書いて読み込んでいます。
でも型補完は欲しいので、"@types/leaflet"はnpmでインストールしています。

この状態で変数L に型補完を動作させるにはどうすればよいでしょうか。
何もしないと、変数Lは未定義だよ というエラーが出ます。
(エラーを消すだけなら適当なd.tsを作って declare const L: any; とでも書けばいいんだろうけど)

901 ：デフォルトの名無しさん：2021/11/21(日) 12:42:32.36 ID:9+9LY8kt.net

import type * as Leaflet from 'leaflet'
declare const L: typeof Leaflet

902 ：デフォルトの名無しさん：2021/11/21(日) 12:53:04.47 ID:lhVIl0/s.net

ありがとうございます

903 ：デフォルトの名無しさん：2021/11/23(火) 00:51:46.26 ID:6fLWx+hU.net

空配列ってどうやって定義すればいいんでしょうか？

904 ：デフォルトの名無しさん：2021/11/24(水) 20:42:59.28 ID:KtJ2oMe7.net

Dateが使いにくいのどうにかする最高のライブラリ教えてよ
date-nfs、momentあたりは試したけどしっくりこんかったわ
JSONが非対称ってのもSo Badやでほんま
よくこんな罠だらけの言語でやってられるなー
フロントエンド勢の忍耐力には尊敬の念を禁じえんわい

905 ：デフォルトの名無しさん：2021/11/24(水) 21:53:47.96 ID:mN6taiyI.net

>>904
> JSONが非対称
とは？
JSON.parse, JSON.stringify 知ってるか？

906 ：デフォルトの名無しさん：2021/11/24(水) 22:01:40.70 ID:zBacYw4i.net

>>904
date-nfsで駄目ならオススメは無いかなぁ。
ご指摘の通り罠も多いけどC++とかに比べたらずっと楽な言語だと思うな

907 ：デフォルトの名無しさん：2021/11/24(水) 23:40:29.12 ID:FcSkbZGe.net

>>904
> Dateが使いにくいのどうにかする
そんなあなたに Temporal

908 ：デフォルトの名無しさん：2021/11/26(金) 22:12:29.88 ID:+KFAtmTP.net

Effective TypeScript
ちと古いが読んだ方がいい？

909 ：デフォルトの名無しさん：2021/12/02(木) 17:06:08.00 ID:kge1UpiO.net

あーくそ
なんでstrictをOFFにできるんだよ
VB.NETか！

910 ：デフォルトの名無しさん：2021/12/02(木) 18:20:28.57 ID:Kt63btcl.net

いやなんでfalseにするんだよ

911 ：デフォルトの名無しさん：2021/12/02(木) 22:30:30.27 ID:Ki4y/ScD.net

既存の JavaScript を段階的に移行したい時かな

912 ：デフォルトの名無しさん：2021/12/07(火) 10:10:01.42 ID:rXzUIf2/.net

非同期がよーわからん
ワーカーを考えない場合
ブラウザでもモバイルでもバックエンドでも基本的に一本のキューにジョブを入れてって順次処理するモデル
promiseやawaitを使うと処理の前後関係は保障されるけど間に他のジョブが割り込む可能性がある
処理そのものはシングルスレッドで行われるのでpromiseやawaitを挟まない限り全てのJSコードがアトミックに実行される
fetchなどJS外の処理についてはアトミックは保障されない
こんな感じであっとる？？？

913 ：デフォルトの名無しさん：2021/12/07(火) 22:24:43.13 ID:aDEs4G8x.net

JavaScript Visualized: Event Loop
https://dev.to/lydiahallie/javascript-visualized-event-loop-3dif

914 ：デフォルトの名無しさん：2021/12/08(水) 07:25:06.20 ID:ff6DaDGr.net

>>912
だいたい合ってる。基本的には処理の予約と考えるだけで済む。
JS外の処理はWebWorker含めてJS環境に干渉してこないんだから（戻り値以外）ほぼイベントとか割込と同質で特殊なものだと考える必要もなくないかな？

915 ：デフォルトの名無しさん：2021/12/09(木) 14:21:48.83 ID:h+aQCsXU.net

なんかプロジェクトでtypescript使う流れになって今から勉強してるんだが、これ何に優れてるの？
javascriptの拡張言語で型の宣言できるぐらいがメリット？
実行するためにいちいちコンパイルもどきなことをしないといけないしデバッグ面倒で正直やりづらいとしか思えないんだが

916 ：デフォルトの名無しさん：2021/12/09(木) 14:29:35.72 ID:lTugl+ha.net

「正直、特別優れた言語設計でもないし、基本的なライブラリ貧弱だし、なんか色々と不安定なので、他の言語を使えるならそっちのがいい。
でもJavaScriptよりかは遥かにマシだからターゲットプラットフォームがブラウザ、ReactNativeなら積極的に使っていこうぜ」ぐらいの認識ですかね

型パズルとかゆるゆるなインターフェースとか最初はこりゃ楽チン、便利だなと思うけどメンテナンス性は疑問
あとTypeScriptは生のJavaScriptよりanyの凶悪さが増してると思う

所詮はALT JSですね

917 ：デフォルトの名無しさん：2021/12/09(木) 16:46:11.49 ID:V/6JaBTF.net

>>915
watch使うとわざわざコンパイルする手間が省けるので楽だよ。あとmapファイルも出力するようにすればデバック時も面倒じゃなくなるよ。
型だけじゃなくて、同じコードで古い環境でも動くソースを吐くこともできるよ。
でも、型にメリットを見いださない人向けの言語で無いね。

918 ：デフォルトの名無しさん：2021/12/09(木) 20:23:42.31 ID:/vSkUWU0.net

動的型付け言語しか使ったことがない人ならそんなものだよね

919 ：デフォルトの名無しさん：2021/12/10(金) 13:52:02.48 ID:+cpc+hgB.net

個人開発だとTypeScriptガンガン使ってる
型パズルたのちい

920 ：デフォルトの名無しさん：2021/12/10(金) 16:44:26.21 ID:IDIER0Zn.net

型パズルはアンチパターンだ
ほどほどにしとけ
人類はC++を教訓にしなければならない

921 ：デフォルトの名無しさん：2021/12/10(金) 17:18:46.95 ID:AY2SRHbF.net

TypeScriptにはSFINAEみたいな凶悪な仕様はないだろう。
conditional typeは少し難解かもしれないが自分で使わなければいいだけのことだし。

922 ：デフォルトの名無しさん：2021/12/21(火) 11:07:25.83 ID:vugugi2u.net

any型のデータをそれ以外の型に変換可能かどうか判定する、または変換するライブラリってあります？
↓こんな感じの

type T = { id: number; name?: string; timestamp: Date; }

const data1: any = { id: 1, name: “bob”, timestamp: new Date() }
const t1: = convert<T>(data1); // OK

const data2: any = {
id: “2”, // number format string
timestamp: “2021-12-21T11:00:00Z”, // ISO Date string
}
const t2 = convert<T>(data2); // OK

const data3: any = { // without required field
timestamp: new Date()
}
const t3 = convert<T>(data3); // throw Error

const data4: any = {
id: 4,
timestamp: “hello” // invalid format
}
const t4 = convert<T>(data4) // throw Error

923 ：デフォルトの名無しさん：2021/12/21(火) 11:18:51.59 ID:vugugi2u.net

TypeScriptって型が嘘をつくことが結構あって
Date型なのに実行時には文字列が入ってるとか
型定義では省略不可なのに実行時には省略されてるとか
そういう実行時の型エラーをなんとかして削減したい、というのが根本的な課題です
上でレスしたようなライブラリがもし有れば多少はマシになるかな、と
ランタイムがキャスト例外を投げてくれればそれがベストなんですが、JSに実行時型情報はないのでそれは難しい

924 ：デフォルトの名無しさん：2021/12/21(火) 18:51:42.35 ID:X++9NQ8p.net

> JSに実行時型情報はないので
つ typeof, instanceof

925 ：デフォルトの名無しさん：2021/12/21(火) 19:01:16.33 ID:S4hmWBPH.net

すげー斜め読みしてタイプガードではいかんのかと思った

926 ：デフォルトの名無しさん：2021/12/21(火) 19:16:55.14 ID:ESVu6HO8.net

タイプガードでもいいんですけど数が多いので一発で全部よしなにやってくれるものがほしいって感じですかね
C#のdynamicのように非互換の代入をその場で例外にしてくれれば楽なんですが
なんでかanyは非互換でもエラー無しでスルッと進んでしまうので苦労してます

927 ：デフォルトの名無しさん：2021/12/21(火) 19:39:34.82 ID:S6JYHyb7.net

https://github.com/colinhacks/zod

928 ：デフォルトの名無しさん：2021/12/21(火) 20:01:09.90 ID:ESVu6HO8.net

>>927
どうも
なかなか良さそうだけどちょっと大変そう
普通の型を先に定義してパーサーを生成するのは難しいんですかね?

929 ：デフォルトの名無しさん：2021/12/21(火) 20:08:19.40 ID:fpjBPgEH.net

TypeScriptのtypeやinterfaceからjsonschemaを生成するライブラリがあるから
それを使ってタイプガード書けば楽よ。

930 ：デフォルトの名無しさん：2021/12/21(火) 20:09:36.77 ID:S6JYHyb7.net

https://github.com/azu/create-validator-ts

931 ：デフォルトの名無しさん：2021/12/21(火) 20:12:46.39 ID:S4hmWBPH.net

そういえばAJVがタイプガードに対応してたな

932 ：デフォルトの名無しさん：2021/12/21(火) 20:17:02.00 ID:ESVu6HO8.net

>>930
いいかも
あとはanyの代入を自動的に置き換えることができれば完璧

933 ：デフォルトの名無しさん：2021/12/21(火) 20:28:04.08 ID:S6JYHyb7.net

string -> Date のような transform をしたいなら、型から自動生成を期待するよりもスキーマで変換ロジックを書いて型を導出するアプローチの方が扱いやすい

934 ：デフォルトの名無しさん：2021/12/23(木) 16:09:01.04 ID:qSHzxodN.net

axiosでの（非同期）通信結果から
最終的にpromiseを外した形でresponse扱いたいんだけど
どうやるとできるのでしょうか？

function的な奴で非同期通信して
そのfunction自体はpromiseでない値を返したいんだけど。。。

awaitやろうと思うと
そのfunctionはasyncになって
結局promiseになってしまう

イメージ
conct func = (): string => {
// axiosの戻りがstringだとして、このvalを同期的に返したい
axios.get("hogehoge").then(val=>{return val})
}

935 ：デフォルトの名無しさん：2021/12/23(木) 20:50:37.85 ID:aMbIyyBR.net

不可能です
直接 XMLHttpRequest を同期モードで使用してください

936 ：デフォルトの名無しさん：2021/12/23(木) 22:47:01.90 ID:j1Nwu6l7.net

非同期を同期にはできない。
これ、初心者の頃は辛かったけど、気がついたら慣れてたし不便さより便利さを感じるようになったから人間の適応能力ってすごい。

937 ：デフォルトの名無しさん：2021/12/24(金) 11:16:13.19 ID:8YLKxFwi.net

うーんわからん
type X = A & { foo: string}
ってやるとXがanyと判定される現象が起きてて原因が全くわからない
Aはちゃんと型が認識されてる
const a: A = { 略 }
a.
ここまで打てばインテリセンスが出てくる
でも&を挟むとなぜかanyになる
コンパイラのバグかな？

938 ：デフォルトの名無しさん：2021/12/24(金) 12:01:47.45 ID:vCO0x3fk.net

export type X = A & { foo: string }
const x: X
これは型が生きてるしインテリセンスも出る

import { X } from ‘…’
const x: X
これはanyになってしまう

ファイルを跨がなければおkみたい
エクスポート/インポートのプロセスでバグるのかな？
他の型は問題出てないからAだけが特殊なんだろうけど文字列型のフィールド幾つか持ってるだけのなんの変哲もない型なんだよな…

939 ：デフォルトの名無しさん：2021/12/25(土) 12:39:31.39 ID:mJNzEC98.net

色々調べて行き詰まったんだけどこれで合ってる？

babelのpreset-typescriptはTSから形情報を落としてるだけ
なのでtsconfigを無視する
なのでproject referencesも無視される
プロジェクト分割したい場合のオフィシャルな手段がない
なのでプロジェクト分割したければ各自好きな方法でハックするしかない

暫定対応として被参照側のプロジェクトでwatch & buildを仕掛けて
babel側のプロジェクトから被参照側の出力フォルダをimportしてるんだけど正直辛いものがある

940 ：デフォルトの名無しさん：2021/12/25(土) 13:16:26.59 ID:YYlOH5kW.net

babel がどう動くかなんて tsc には関係ないだろ
それともあなたのエディタは babel で型情報を解析しているのか？

941 ：デフォルトの名無しさん：2021/12/25(土) 13:22:25.16 ID:YYlOH5kW.net

コンパイル済みのファイルに型情報がないという話なら、型定義ファイル(.d.ts)も出力しないとそりゃそうだろと

942 ：デフォルトの名無しさん：2021/12/25(土) 13:40:07.40 ID:mJNzEC98.net

プロジェクト分割についてはどう考えますか？

943 ：デフォルトの名無しさん：2021/12/25(土) 13:54:01.89 ID:YYlOH5kW.net

情報を小出しにせず、問題が再現するリポジトリ丸ごと上げるかせめてファイル構造や各種設定ファイルの内容など全部書き出して
& がダメなのかファイルを跨ぐのがダメなのかプロジェクト分割がダメなのか話がどんどん移っててわからんぞ

944 ：デフォルトの名無しさん：2021/12/25(土) 14:17:47.06 ID:YYlOH5kW.net

これ別人の別の話か…そうだったらスマン

945 ：デフォルトの名無しさん：2021/12/25(土) 14:25:06.24 ID:mJNzEC98.net

別ですね
単刀直入に言うとbabel & preset -typescript環境で正しいプロジェクト分割のしかたを聞きたかった

946 ：デフォルトの名無しさん：2021/12/26(日) 11:58:10.04 ID:yczrikVs.net

色々と試して結論が出た
プロジェクト参照は諦めてシンプルに相対パスでimportすることにした
依存パッケージを全てのプロジェクトに入れなければならないのが面倒だけど妥協
ようするに昔VB6やC言語などでよくやってたDLL化せずにコードファイルを共有するスタイル
モダンな言語でやることとは思えないけど何日も調べてできないなら仕方ない

947 ：デフォルトの名無しさん：2021/12/26(日) 12:26:32.69 ID:6ScHvZpk.net

バベるのが悪い

948 ：デフォルトの名無しさん：2021/12/26(日) 16:05:00.89 ID:SvIlyqah.net

でもフレームワークがバベれって言うんです

949 ：デフォルトの名無しさん：2021/12/26(日) 16:14:53.21 ID:imvxWhRx.net

これを

babel_proj
webpack_proj
tsc_proj
　tsconfig.json
tsc_lib_1
　tsconfig.json
tsc_lib_2
　tsconfig.json


こうする

babel_proj
　symlink => ../libs
webpack_proj
　symlink => ../libs
tsc_proj
　tsconfig.json
　symlink => ../libs
libs
　lib_1
　lib_2

950 ：デフォルトの名無しさん：2021/12/28(火) 17:28:42.45 ID:X7A0KCIT.net

バックエンドはexpress一択？

951 ：デフォルトの名無しさん：2021/12/28(火) 20:29:49.68 ID:qjWVy58S.net

そんな🍌

952 ：デフォルトの名無しさん：2021/12/28(火) 23:38:51.88 ID:QExnrlZb.net

僕はFastify!

953 ：デフォルトの名無しさん：2021/12/29(水) 02:36:36.80 ID:tTEsT75E.net

nestjsはレガシーなデコレータ依存がなあ

954 ：デフォルトの名無しさん：2021/12/30(木) 13:04:36.50 ID:8IVD/YcY.net

そもそもサーバーサイドにTS選ぶメリットが無い

955 ：デフォルトの名無しさん：2021/12/30(木) 13:42:00.99 ID:XEA11GKy.net

JavaScriptがって話ならわからんでもないが

956 ：デフォルトの名無しさん：2021/12/30(木) 13:49:04.54 ID:8IVD/YcY.net

TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ
フロントエンドでは気楽さと壊れやすさのトレードオフってことで受け入れるけど

957 ：デフォルトの名無しさん：2021/12/30(木) 13:53:13.25 ID:XEA11GKy.net

じゃあC/C++なんかもダメだな

958 ：デフォルトの名無しさん：2021/12/30(木) 14:00:36.67 ID:qk2rIpzk.net

バリデーションもできない奴がなんか言ってら

959 ：デフォルトの名無しさん：2021/12/30(木) 14:01:03.11 ID:8IVD/YcY.net

そうだね
バックエンドでは実質Cと大差ない
ちょっとだけ楽できるけど

960 ：デフォルトの名無しさん：2021/12/30(木) 14:10:38.20 ID:XEA11GKy.net

じゃあ逆にバックエンドで受け入れられる言語ってなんだろう？JavaとかRustくらい？

961 ：デフォルトの名無しさん：2021/12/30(木) 14:23:51.58 ID:8IVD/YcY.net

JavaとC#だね
型安全性がしっかりしてて実績も多い言語って言えばそれぐらいじゃないか？

962 ：デフォルトの名無しさん：2021/12/30(木) 14:42:45.86 ID:XEA11GKy.net

んー、つまり

>TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ

JavaとC#以外の言語を触るたびに同じように思ったってことでいいのかな？

963 ：デフォルトの名無しさん：2021/12/30(木) 15:01:47.81 ID:Q5xANRZc.net

まあ、そうだね

964 ：デフォルトの名無しさん：2021/12/30(木) 16:23:51.89 ID:se0ux0qB.net

C♯やJavaよりはTypeScriptやRust選びますわ

965 ：デフォルトの名無しさん：2021/12/30(木) 16:31:34.51 ID:tab5g/QS.net

そしてバグが出ると

966 ：デフォルトの名無しさん：2021/12/30(木) 16:52:28.72 ID:XEA11GKy.net

まるでTypeScriptやRustを選ぶとバグが出るかのような物言いだが
C#やJavaを選べばバグが出ないというわけでもあるない

967 ：デフォルトの名無しさん：2021/12/30(木) 17:38:29.90 ID:tab5g/QS.net

TypeScriptは型が簡単に嘘をつけるのでバグが出やすい
型安全性がバグ削減に貢献しているのはプログラマの常識

968 ：デフォルトの名無しさん：2021/12/30(木) 17:46:55.74 ID:18t9WvJQ.net

それはあなたがバリデーション書けないからでしょ？

969 ：デフォルトの名無しさん：2021/12/30(木) 17:56:31.58 ID:XEA11GKy.net

>>967
具体的にどういうのを言っている？まさか故意にasでキャストした場合の話じゃないだろうが

970 ：デフォルトの名無しさん：2021/12/30(木) 18:04:13.25 ID:cY7zFSmj.net

その返答で書けないということが露呈したゾ

971 ：デフォルトの名無しさん：2021/12/30(木) 19:17:21.94 ID:zuTar3e4.net

>>968
型が嘘をつけることとバリデーションは別次元の話

>>969
明示的キャストなんかしなくてもTSにはいくらでも型が嘘をつく罠がある
代表的なところだとjsonのパース、DBのI/O、api I/O、野良ライブラリのI/O、、、

972 ：デフォルトの名無しさん：2021/12/30(木) 19:25:44.57 ID:zuTar3e4.net

言語仕様を変えるべきなんだろうな
typeで宣言した変数への代入は実行時に型チェック付きのマッピングにトランスレートすべき
ついでに言うとtypeで未定義の属性はマッピングするときにundefinedにすべき
これだけでTypeScriptによくある馬鹿馬鹿しいバグがかなり減るはずだ

type Foo {
x: string;
y: number; }

const foo: Foo = { y: “s” } as any
これはコンパイル時には無視していいが実行時にはエラーになるべきだし

const foo2: Foo = { x: “a”, y: 100, z: “111” }
これはzは消えるべき

973 ：デフォルトの名無しさん：2021/12/30(木) 19:33:44.30 ID:18t9WvJQ.net

>>972
いやそれはそのコードがバカじゃん……

974 ：デフォルトの名無しさん：2021/12/30(木) 19:34:37.32 ID:zuTar3e4.net

Javaは最も優れた設計でそもそもanyみたいな言語仕様がない
Objectは定義できるが暗黙のキャストでスルッと行くなんてことはあり得ないし無理やりキャストしたって実行時に必ず例外が飛ぶ
C#はanyに近いものでdynamicというのがあるがこれも誤ったキャストには実行時に例外が飛ぶ
どちらも型が嘘をつかないように言語基盤がしっかり担保してくれるから型を信用していい
当たり前のことを当たり前にやってくれる堅実な言語だ

975 ：デフォルトの名無しさん：2021/12/30(木) 19:36:08.35 ID:zuTar3e4.net

>>973
このコードは説明のためのスニペットだ
現実的にこんなコード書くわけないだろ
現実的には先に挙げたような状況でanyと戦わなければならない

976 ：デフォルトの名無しさん：2021/12/30(木) 19:44:03.93 ID:18t9WvJQ.net

>>971
>>975
なんの為のバリデーションとタイプガードだよ。
どこで間違った型が入りうるかなんか普通把握できるでしょうに

977 ：デフォルトの名無しさん：2021/12/30(木) 19:48:28.03 ID:pcTvcAXH.net

Javascriptのスーパーセットという最大のセールスポイントを見てなさすぎだろ
構造的部分型も便利だしany型なんて使うときには型ガードするよね
型に関してはJavaより好きだわ

978 ：デフォルトの名無しさん：2021/12/30(木) 19:51:25.70 ID:HvA/IBjD.net

Nullableを長年放置してたり文化的にも言語的にもImmutableを軽視してきたJavaもちょっと信用できないですね

979 ：デフォルトの名無しさん：2021/12/30(木) 19:59:03.54 ID:zuTar3e4.net

>>976
バリデーションってのは値が正しいかどうか検証するものであって型が嘘をついているかどうか調べるためのものじゃない

どこで型が嘘をついているか確実に判断することはむずかしい
自分達の管理するコードベースの外界とのI/Oは全て疑わしい
先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
疑わしい箇所が多すぎる

型が嘘をつかない言語なら外界とのI/Oの型定義が信用できる
信用できない領域がグッと一気に減る
だから型は嘘をついちゃいけないし
簡単に嘘をつける言語仕様は絶対におかしい

980 ：デフォルトの名無しさん：2021/12/30(木) 20:05:16.00 ID:zuTar3e4.net

>>977
構造的部分型もわかりにくいバグの温床だな
anyよりは全然マシだが
まあ楽なのは楽だよそれはわかる
ただ楽なのと安全でりかいしやすいのとは同じじゃないからね

typeは俺が言ったような真の意味で型安全を担保するための仕様
interfaceは構造的部分型でサボるための仕様
こう使い分ければよかったんだろうな

981 ：デフォルトの名無しさん：2021/12/30(木) 20:09:20.24 ID:zuTar3e4.net

>>977
セールポイントであり最大の弱点でもある
思い切って互換性切った方が絶対上手くいってた

>>978
まあ先発の古い言語だからある程度は仕方ないね
Null安全は対応してきてる
イミュータブルは昔から使えてた(final)

982 ：デフォルトの名無しさん：2021/12/30(木) 20:42:46.31 ID:18t9WvJQ.net

>>979
型さえあってりゃどんなライブラリも安全安心だと思っているのか……

983 ：デフォルトの名無しさん：2021/12/30(木) 20:51:38.40 ID:iK2C+Pgo.net

>>982
ちゃんと読めてます？
「信用できない領域がグッと減る」って書いてあるでしょ？

型安全であれば全てが安全なんてことはない
これは常識
でも型安全ならそうでない場合に比べて大部分が安全になる
これも常識

そしてTSは一見すると型安全であるかのように見えるけれど
型が簡単に嘘をつける言語仕様のせいで実は型安全ではなく安全でない言語である
これが私の主張
よく読んでね

984 ：デフォルトの名無しさん：2021/12/30(木) 21:06:33.94 ID:18t9WvJQ.net

>>983
お、これは失敬

985 ：デフォルトの名無しさん：2021/12/30(木) 21:26:07.36 ID:XEA11GKy.net

>>971
あんたの言う「型が嘘をつく」の意味がよくわからんが。オレオレ用語じゃなくて一般的な用語で説明してくれんかな。

>先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
>疑わしい箇所が多すぎる

嘘をつくもなにも、JSONはそのJSON自体の構造以上の型を主張したりはしないが。
それを勝手に別の型と見做したとしたらそのコードの方に問題があるわけだろう。

986 ：デフォルトの名無しさん：2021/12/30(木) 21:31:50.13 ID:XEA11GKy.net

>>972
ああなるほど。
型の合わせ方がわからなくてasやanyで誤魔化したらバグったってのの逆恨みか。

987 ：デフォルトの名無しさん：2021/12/30(木) 21:32:15.17 ID:yBt1j67p.net

型が嘘をつくってのは
コンパイル時に指定した型以外の値が入ってることがある
入れることが簡単にできるということ

type X = { foo: string }
function xxx(): X

例えば↑こういう定義があったとする
実際にxxx()の戻り値が文字列型のfooという属性を持っているかどうか？
それはソースコードを隅々まで読んで間違いないことを確認するまでわからない

コードはXという型はfooという文字列型の属性を持っていると主張しているわけだが実際にはそうでない場合がある
これを俺は型が嘘をついていると表現する

988 ：デフォルトの名無しさん：2021/12/30(木) 21:33:00.94 ID:yBt1j67p.net

>>986
ちげーよ

989 ：デフォルトの名無しさん：2021/12/30(木) 21:36:23.80 ID:yBt1j67p.net

JavaやC#ではこういう事は起こらない
正確には低レベルAPIでメモリを不正に書き換えれば起こせるが無理すれば起こせないこともないと言った程度
JavaやC#ではXがfooという文字列型の属性を持っていてxxxの戻り値の型がXであると書いてあったらそれを信用していい
JavaやC#は型が嘘をつかないからだ

990 ：デフォルトの名無しさん：2021/12/30(木) 21:37:07.94 ID:XEA11GKy.net

>>987
？
おめーのtscはそれコンパイルエラーにしてくれないの？

991 ：デフォルトの名無しさん：2021/12/30(木) 21:39:39.80 ID:rc2c+xCv.net

>>990
本当に恥ずかしいからお前はもう黙ってろ

992 ：デフォルトの名無しさん：2021/12/30(木) 21:39:49.15 ID:yBt1j67p.net

>>990
しない

993 ：デフォルトの名無しさん：2021/12/30(木) 21:42:03.35 ID:18t9WvJQ.net

そんなにTSが嫌いならずっとJavaなりC♯なり使ってれば良いじゃん

994 ：デフォルトの名無しさん：2021/12/30(木) 21:45:32.05 ID:XEA11GKy.net

>>992
コンパイルエラーにならない function xxx() の例よろ。

995 ：デフォルトの名無しさん：2021/12/30(木) 21:57:10.00 ID:hxNkeOah.net

>>993
そだね
選択権があるプロジェクトなら必ずそうしてるよ

996 ：デフォルトの名無しさん：2021/12/30(木) 21:59:52.63 ID:hxNkeOah.net

>>994
function xxx(): X {
return {
foo: bugLib.getStringValueEvil();
}
}