What programmer hasn't at some point in their career written code like this: throw new Error(`Unexpected value: ${value}. This should never happen!`); ...and then had a user submit a bug report containing that very message. The `never` type is a nice way to model those scenarios and hopefully avoid such an error ever being seen by the user. // Compile error unless we've ruled out // `value` at the type level assertNe…
A complete guide to TypeScript’s 'never' type
51–60 of 64 posts
Re: A complete guide to TypeScript’s 'never' type
#52What programmer hasn't at some point in their career written code like this: throw new Error(`Unexpected value: ${value}. This should never happen!`); ...and then had a user submit a bug report containing that very message. The `never` type is a nice way to model those scenarios and hopefully avoid such an error ever being seen by the user. // Compile error unless we've ruled out // `value` at the type level assertNe…
The first one is a very useful error as a user though. It tells me the unexpected value isn't my fault and I should go report a bug.
Ideally, the user is presented with a general message telling them how to report a bug (link or something?), and include a base64 encoded blob, containing the context of the error (e.g., a stack trace, and may be also the very message in the exception), and ask the user to also submit that blob.
Re: A complete guide to TypeScript’s 'never' type
#53Earlier quoted context omitted.
The first one is a very useful error as a user though. It tells me the unexpected value isn't my fault and I should go report a bug.
it's not a useful message to the laymen. The message is a contradiction, which makes no sense to an untechnical person (who is also unlikely to report it properly, from experience). The will say that the computer is broken, or that the program stopped. Ideally, the user is presented with a general message telling them how to report a bug (link or something?), and include a base64 encoded blob, containing the context…
Re: A complete guide to TypeScript’s 'never' type
#54Earlier quoted context omitted.
it's not a useful message to the laymen. The message is a contradiction, which makes no sense to an untechnical person (who is also unlikely to report it properly, from experience). The will say that the computer is broken, or that the program stopped. Ideally, the user is presented with a general message telling them how to report a bug (link or something?), and include a base64 encoded blob, containing the context…
Wow, I would hate that. Fortunately I've never seen it before. Seems like "the user is too dumb to lay their lowly eyes upon our error message".
Re: A complete guide to TypeScript’s 'never' type
#55Earlier quoted context omitted.
Any sources on poor grammar being a new thing? It's been taught in public/private schools in England for centuries, maybe even millennia.
Sorry, I think I was not clear enough. There have certainly been efforts to draw arbitrary distinctions between groups based on speech for a very long time, probably going almost as far back as language itself. What I was referring to was specifically an effort rooted in a desire to use rules of Latin grammar to restrict constructions in English. This was a big thing relatively recently (likely sometime in the past 1…
Just because those particular rules are silly doesn't mean all linguistic prescription is wrong. Prescriptions that clarify the meaning and relational structures between concepts can be very helpful, and discriminate only against careless users of language.
Grammar poor not does if exist, this like having have conversations fun.
Re: A complete guide to TypeScript’s 'never' type
#56Re: A complete guide to TypeScript’s 'never' type
#57Earlier quoted context omitted.
> That’s not a pun that’s just poor grammar. There is no such thing as "poor grammar" --- it's a myth. Most of the grammatical "rules" we tend to be taught in primary and secondary school English courses were invented relatively recently, and they were created specifically for the purpose of establishing an arbitrary class distinction. Now, there's something to be said about markedness [1]. If the majority of a speci…
Given that the OP has posted to say that it was a mistake and hence isn't "unmarked" as you put it, you've quite missed the point. Not all mistakes (and corrections) are evidence of some classist plot.
Re: A complete guide to TypeScript’s 'never' type
#58Earlier quoted context omitted.
> Do you have any proof that "they were created specifically for the purpose of establishing an arbitrary class distinction"? Apologies; you are correct that my assertion is overly strong. I should rather have said "although we can no longer ascertain for certain the purpose for which these rules were introduced, some believe the origin to be rooted in a desire for creating an arbitrary class distinction." Many of th…
> But "poor grammar" specifically seeks to attribute a negative connotation to the utterance. It says suggest that people who construct such utterances are, somehow, uneducated, or else are outsiders. It says that they've done something that is objectively (not subjectively) incorrect or wrong. You're completely ignoring that people do make mistakes and get corrected. There is nothing in the post you originally repli…
That's literally what the "poor" in "poor grammar" is doing, though. The phrase itself suggests that the speaker is lesser-than simply by virtue of not speaking in the same way as the listener would.
> If I accidentally type "Eat I bread", it's incorrect grammar even if there happens to be some dialect somewhere where it is valid.
It is not "incorrect". It is different. It is marked, maybe, for many native English speakers. But these are distinct things from "incorrect".
I do not understand how you can say "There might be a group somewhere where who find it valid, but I don't find it valid and therefore it is incorrect." Why is your personal dialect the one that determines correct/incorrect? If you are American, is it incorrect to say "to go on holiday"? If you are British, is it incorrect to say "Microsoft is going to X" instead of "Microsoft are going to X"?
The use of the terms "correct" and "incorrect" suggests that there exists a universal ground truth, and my whole point in this discussion is that no such ground truth exists. If there is no universal ground truth, then there can be no correct/incorrect. The only way to get around this is to establish a specific cultural context where a ground truth can be agreed upon (e.g., a style guide used by a particular publication venue). Otherwise, at best you can only say "I would not phrase it in that way", but you cannot say "that is incorrect."
Re: A complete guide to TypeScript’s 'never' type
#59Earlier quoted context omitted.
> But "poor grammar" specifically seeks to attribute a negative connotation to the utterance. It says suggest that people who construct such utterances are, somehow, uneducated, or else are outsiders. It says that they've done something that is objectively (not subjectively) incorrect or wrong. You're completely ignoring that people do make mistakes and get corrected. There is nothing in the post you originally repli…
> There is nothing in the post you originally replied to implying that anyone is uneducated or an outsider That's literally what the "poor" in "poor grammar" is doing, though. The phrase itself suggests that the speaker is lesser-than simply by virtue of not speaking in the same way as the listener would. > If I accidentally type "Eat I bread", it's incorrect grammar even if there happens to be some dialect somewhere…
The universal ground truth is the intersubjective understanding of language norms.
>The only way to get around this is to establish a specific cultural context where a ground truth can be agreed upon (e.g., a style guide used by a particular publication venue).
Yes, and such context exists. The main prestige dialect in the US is General American, all other dialects are marked geographically, culturally, professionally or in some other similar manner.
Re: A complete guide to TypeScript’s 'never' type
#60What programmer hasn't at some point in their career written code like this: throw new Error(`Unexpected value: ${value}. This should never happen!`); ...and then had a user submit a bug report containing that very message. The `never` type is a nice way to model those scenarios and hopefully avoid such an error ever being seen by the user. // Compile error unless we've ruled out // `value` at the type level assertNe…
The first one is a very useful error as a user though. It tells me the unexpected value isn't my fault and I should go report a bug.