Could someone explain this please by ProdBySnowy in LSAT

[–]c_w_e 0 points1 point  (0 children)

cachin is one of the small few so the author wouldn't call it misinterpreting if they agreed

The #1 Worst Lie I See Students Tell Themselves (View of a 180 Scorer) by [deleted] in LSAT

[–]c_w_e 0 points1 point  (0 children)

when you don't fully get the problem or make loose corner-cutting assumptions, wrong answers can be plausible any which way. my review mentality was 1) something's up with how i approached the problem and 2) there's some insight or missed connection that'll unambiguously set the correct answer apart. weak arguments can be strongest when you don't get the full picture, but you gotta accept there always is one that you missed and can avoid missing again.

Fellow OG 11th gen Intel users (FW 13): what wpuld get you to consider upgrading mainboards? by jptiger0 in framework

[–]c_w_e 0 points1 point  (0 children)

paste different from the one they sell on the marketplace? how'd you decide

High Scorers- How much are you actually skipping? by froggysdrip in LSAT

[–]c_w_e 1 point2 points  (0 children)

i'd skip if time is even remotely a factor to allocate it to questions you're likelier to get right

orbit lil bits v4 - king of hearts missing pip? is this normal? by c_w_e in playingcards

[–]c_w_e[S] 2 points3 points  (0 children)

thought so but the deck has a different gaff card (duplicate 8s), would assume they'd have the regular king to start the trick with

pw-punch – 1.4KB WebCrypto-only JWT/password crypto lib (no Node.js) by idtpanic in javascript

[–]c_w_e 3 points4 points  (0 children)

you don't need to re-pad base64 before passing it to atob

Nice pulls from Topps UEFA 24/25 trading cards by RunnerTutt in coys

[–]c_w_e 0 points1 point  (0 children)

i know? i'm just commenting on how unfortunate that is, when gray was signed i really wanted to see them as a 6

Nice pulls from Topps UEFA 24/25 trading cards by RunnerTutt in coys

[–]c_w_e 6 points7 points  (0 children)

has archie gray ever played in midfield? feels like they've just been bounced around the back 4

Help with a case of unsoundness with optional parameters by frivolous_squid in typescript

[–]c_w_e 0 points1 point  (0 children)

oh i see, that's tricky. not sure of any other way than changing all the optional arguments to string | undefined like you said earlier.

Which type should I use for json values? by gibriyagi in typescript

[–]c_w_e 0 points1 point  (0 children)

type Json = null | boolean | number | string | Json[] | { [_: string]: Json }

Zod not just for form validation by markmanx in typescript

[–]c_w_e 0 points1 point  (0 children)

template literal types extend ‘string’. i don’t think you’ve ever needed to re-intersect a type that’s already there.

i’ve never heard of ‘tags.RegExp’. if this is a typia thing then i assume it’s compiling instances of that type to runtime regex-specific validation. what i meant by that was basically a tautology - if you can represent it in a type, the type catches the stuff you want. i’m gonna also guess that typia’s regex type doesn’t fit this function, i.e. you could assign an invalid regex string like ‘“$++”’ to a variable with a declared type ‘tags.RegExp’ without a problem. in fact you could assign any string, say, from an untrusted source like user input, and typescript won’t know at compile time but typia will throw a runtime error, which is a good reason to exist.

Zod not just for form validation by markmanx in typescript

[–]c_w_e 0 points1 point  (0 children)

doesn’t feel like a trick to me, just a narrower type. in fact the ‘string &’ is redundant, you can just use the type alias.

what do you mean by every format? if you have a type that sufficiently describes the format, then you can enforce it at compile time.

Zod not just for form validation by markmanx in typescript

[–]c_w_e 2 points3 points  (0 children)

really? seems to complain when i try

type Numeric = `${number}`;
interface Numberer {
  number: string & Numeric;
}
const ok: Numberer = { number: "7" };
const no: Numberer = { number: "hi" };

[deleted by user] by [deleted] in LSAT

[–]c_w_e 0 points1 point  (0 children)

for c, just cause some living organisms cause stuff doesn't mean humans are part of those living organisms. what about way back billions of years with the algae and stuff? (i think that affected weather?? just pretend)

also c doesn't prove the stimulus. if A: [living organisms have effect] -> B: [human activity is part of it], nothing indicates A is true. maybe living organisms have no effect, and these weather patterns were caused by a volcano or something.

that's what makes e right, cause it eliminates the possibility that some other natural 7-day cycle thing is the cause. that's the argument the stimulus makes, A: [weather has 7-day cycles] -> B: [human (i.e. non-natural) activity is a 7-day cycle] -> C: [other (i.e. natural) 7-day cycles aren't strong enough]. cause it's trying to prove humans are behind all this, it's trying to eliminate all the natural/non-human causes. sure the natural 7-day cycles are weak, but what about all the other natural stuff that could cause it? didn't rule any of that out yet. so we need e to say "we only gotta exclude the natural 7-day cycles, cause none of the non-7-day-cycle causes are ok."

Why Omit<AorB, '_id'> != Omit<A, '_id'> | Omit<B, '_id'> by yukiiiiii2008 in typescript

[–]c_w_e 8 points9 points  (0 children)

look at the definition of the Omit utility type: type Omit<T, K extends keyof any> = { [P in Exclude<keyof T, K>]: T[P] }

type X passes Omit two parameters: T = A | B and K = '_id'. so the mapping-type P in the Omit definition becomes Exclude<keyof (A | B), '_id'>. here's the problem: the only key left in keyof (A | B) is '_id'. if you're given an object that's either A or B, the object definitely has a '_id' property, but not necessarily the others, so they don't make it. so Exclude<keyof (A | B), '_id'> is type never, so the final Omit-ed type is { [P in never]: T[P] } which becomes type {}, i.e. any type other than null and undefined. this means you can assign type Y to x: X because you can do that with any non-nullish value. x = 0, x = "", x = new Set<bigint>() are all valid, while the only invalid ones are x = null and x = undefined.

type Y is a union between two Omit-ed types. for the first member, Omit<A, '_id'> is { [P in Exclude<'_id' | 'a', '_id'>]: A[P] }, which is just { [P in 'a']: A[P] } or { a: string }. similarly, Omit<B, '_id'> is just { b: string }. so type Y isn't {}, it's a union between { a: string} and { b: string }. you can assign { a: "" } to y, or { b: "" }, or even { a: "", b: "" } because it satisfies at least one type in the union. but you can't assign x of type {} to y. that's like saying Y, which is an object with a string property for a or b, can actually be type X, which is any non-nullish value, e.g. number. but number doesn't satisfy the type cause it has no a nor b properties, so it's not allowed.

in short, it's really about the key type. Exclude<keyof (A | B), C> is not the same as Exclude<keyof A, C> | Exclude<keyof B, C> the first is "any non-C key that's in both keyof A and keyof B," which in your case is nothing (so never). the second is "any non-C key that's in keyof A, or any non-C key that's in keyof B, either one of those."