Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reveal a subset of TypeScript that is 100% guaranteed type-safe #13003

Closed
zpdDG4gta8XKpMCd opened this issue Dec 17, 2016 · 14 comments
Closed

reveal a subset of TypeScript that is 100% guaranteed type-safe #13003

zpdDG4gta8XKpMCd opened this issue Dec 17, 2016 · 14 comments
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript

Comments

@zpdDG4gta8XKpMCd
Copy link

this is ridiculous: #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

@zpdDG4gta8XKpMCd zpdDG4gta8XKpMCd changed the title reveal a subset of TypeScript that is 100% guaranteed type-safety (maybe at the cost of some features) reveal a subset of TypeScript that is 100% guaranteed type-safe Dec 17, 2016
@RyanCavanaugh RyanCavanaugh added Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript labels Dec 17, 2016
@RyanCavanaugh
Copy link
Member

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

@zpdDG4gta8XKpMCd
Copy link
Author

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?

@zpdDG4gta8XKpMCd
Copy link
Author

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

@RyanCavanaugh
Copy link
Member

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Dec 17, 2016

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

@RyanCavanaugh
Copy link
Member

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.

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Dec 17, 2016 via email

@RyanCavanaugh
Copy link
Member

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.

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Dec 17, 2016 via email

@zpdDG4gta8XKpMCd
Copy link
Author

zpdDG4gta8XKpMCd commented Dec 17, 2016

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.

@zpdDG4gta8XKpMCd
Copy link
Author

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?

@iam3yal
Copy link

iam3yal commented Dec 18, 2016

@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.

@zpdDG4gta8XKpMCd
Copy link
Author

Quote any of my word being disrespectful for start.

@iam3yal
Copy link

iam3yal commented Dec 18, 2016

@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.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

3 participants