Typescript: reveal a subset of TypeScript that is 100% guaranteed type-safe

Created on 17 Dec 2016  Â·  14Comments  Â·  Source: microsoft/TypeScript

this is ridiculous: https://github.com/Microsoft/TypeScript/issues/13002

my problem is that when i see something claimed done "we have readonly properties" i trust this statement and i am eager to use them, it turns out i should have not tried, because well they are not done

there is no reason to lie about what TypeScript can and cannot do

please be honest to your users

there is a sub-set of typescript that works 100% typesafe guaranteed, few people know what it is

the design team can and should be open and explicit about it, hence the request

Out of Scope Suggestion

Most helpful comment

@aleksey-bykov You want people to discuss things with you when you make accusations and respect no one but yourself? I'd suggest you to watch your tone if you want them to take you seriously or even listen to your _feedback_.

Just my 2c.

All 14 comments

Not happening. PureScript, Haskell -> JS, etc are all options if you want to go down this route.

Not happening what? You can't add to the release notes a side note in a fine font saying:

* - overdramatization, not for real use

Why not?

Why can't you be honest about what your features can and cannot do?

i am just asking you a simple fair question, why can't you be honest about known limitations?

We don't lie about what things do and don't do, so please don't accuse us of that. I'm sorry that readonly doesn't meet your expectations, but we made the intentional decision to make it work that way so that it could find real usage in many common scenarios. Given a magic wand to release the first version with built-in readonly support we probably would have gone a different way, but these things are path-dependent.

100% soundness continues to be an explicitly-documented non-goal. I get that you don't agree with that goal - it's understandable - but it's always been the case and asking for two years for the language to move in a 90 degree turn from its explicit goals is not productive.

readonly means only reading, TS did lie (see #13000) or is horrible at
giving names, I understand I can't have all, I don't understand loud
statements proved to be wrong

On Dec 17, 2016 4:21 PM, "Ryan Cavanaugh" notifications@github.com wrote:

We don't lie about what things do and don't do, so please don't accuse us
of that. I'm sorry that readonly doesn't meet your expectations, but we
made the intentional decision to make it work that way so that it could
find real usage in many common scenarios. Given a magic wand to release the
first version with built-in readonly support we probably would have gone
a different way, but these things are path-dependent.

100% soundness continues to be an explicitly-documented non-goal. I get
that you don't agree with that goal - it's understandable - but it's always
been the case and asking for two years for the language to move in a 90
degree turn from its explicit goals is not productive.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/13003#issuecomment-267787568,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5PzS_h57qOerOGdfmaDGMo2XcxE8CBks5rJFJVgaJpZM4LP-cL
.

Adopting the binary position that a feature is either 100% sound or "useless" would lead to us adding approximately 0 features ever.

readonly prevents direct mutation of the declared property through that reference. That's it. Doesn't go far enough? Fair criticism. A lie? No. It's still useful, e.g. #10097.

Much better

Can't see how it is useful in #10097 or anywhere at all. Truth is you are either readonly or you are not. Anything in between doesn't make any sense, no matter how you put it. It's like saying that a boolean can in fact be true false or something else. Thus there was no single reason to go this way. Especially for a brand new feature that is by definition an opt in thing. It cannot break anything unless you deliberately write damn readonly I front of your otherwise perfectly valid code. So nothing you said makes sense. Let alone you didn't answer the fair and simple question as to why TS can't be honest about limits of their features. You just closed it without consideting to make an effort to answet it or give explanations.

And for the record I said no single word about going 100% sound or any binary position you mention, the request reads: please make an effort to label your imperfect features as safe and unsafe, please be explicit what unsafe is. That's all. Why does it deserve closing?

@aleksey-bykov You want people to discuss things with you when you make accusations and respect no one but yourself? I'd suggest you to watch your tone if you want them to take you seriously or even listen to your _feedback_.

Just my 2c.

Quote any of my word being disrespectful for start.

@aleksey-bykov Just because something isn't written or someone fail to describe something, doesn't mean he/she lie about it, _accusing_ them for lying is not something you would do out of respect.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

siddjain picture siddjain  Â·  3Comments

zhuravlikjb picture zhuravlikjb  Â·  3Comments

manekinekko picture manekinekko  Â·  3Comments

DanielRosenwasser picture DanielRosenwasser  Â·  3Comments

dlaberge picture dlaberge  Â·  3Comments