Видео

thanks! what did you like about it?

check out the original video: Sam goes into (more) pretty extensive technical depth as to why what he's describing is different from semver

@@MichiganTypeScript ok, thanks

this one really is special, isn't it?

@@MichiganTypeScript yes. Firstly I try to solve by myself, but when it takes too much time I suppose there should be some trick. This one is too tricky)))

@@СвятославКобывников-щ7г that's definitely the best way to do it!

Distributive conditional types are only applied when testing against generic arguments I believe. If you don't pass in PropertyKey as a generic argument, then you are testing if (string | number | symbol) extends IndexSignatureType which will always fail, except in the case that the index signature is (string | number | symbol) because a broader type cannot extend a more narrow type. However, if we pass in PropertyKey as a generic argument, then union members of PropertyKey get distributed on the conditional type so that it looks more like this (assuming the index signature type is string): string extends string | number extends string | symbol extends string. 'string extends string' passes, which removes it from the mapped type. // "foo" type Foo = PropertyKey extends string | number | symbol ? "foo" : "bar"; // "bar" type Bar = PropertyKey extends string ? "foo" : "bar"; // "foo" | "bar" | "baz" type FooBarBaz<T = PropertyKey> = T extends string ? "foo" : T extends number ? "bar" : T extends symbol ? "baz" : never;

❤

My full solution (the same as yours, but with extra branch to check empty object) type AnyOf<T extends readonly any[]> = T extends [infer Head, ...infer Tail] ? Head extends 0 | "" | false | [] | null | undefined ? AnyOf<Tail> : {} extends Head ? AnyOf<Tail> : true : false;

Thanks! We're really happy with how it turned out, too!

Dan is 🥇 for sure! We're always happy to have him back on the channel!

that's fantastic feedback to have! we care a lot about quality of these discussions so please continue to share your most candid feedback. also.. yeah...😅 I guess we did set the bar quite high by starting off with Dan and this particular feature!

we're toying around with the idea of doing a series of videos covering the 83 specific things mentioned in his book. but Dan _is_ also speaking at SquiggleConf (in Boston, October), so who knows: maybe he'll do a deep dive on something there.

@@MichiganTypeScript My Proposals would be:Titian Cernicova-Dragomir, gabriel vergnaud, Stefan Baumgartner

@@hansschenker thanks for the suggestion! We reached out to Titian and we're meeting with him late next week to do a similar video on Isolated Declarations

@@MichiganTypeScript Very good - Titian is a real expert!

if that works for you then full support from us!

same... I think it's a big misconception with types is that it pays off compared to the investment. my observations (and I was dealing with types even before typescript - back when google closure compiler was using es4-like types) is that the overall benefit does not contend the extra effort.

Let statements inside block scope is an intrinsic feature of JavaScript. However when the same thing is done in ReScript as shown in 33:54 it's a no no for you? Double standards. Give it a chance before you spread negativity.

@@SubhashishPradhan That's not a closure that's an object statement.

ReScript language documentation disagrees with you.

He was referring to type guards

Type guards were shown in 55:08. I haven't commented on that.

haven't used Kotlin: which parts seem similar?

@@MichiganTypeScript how the code is structured, in kotlin functions we can omit the open and closing bracket and all the logic will be inside as a scope of it and the last item will be returned as a value... You could Google and see how it is or to save some time just google for how to use "when expression in kotlin" and you will realize what I want say🙂🙂

are you saying magic is good or bad?

@@MichiganTypeScript it's bad

@@MichiganTypeScript Bad. When you’re trying to convince engineers magic is the last thing you want to mention 😀

we've been thinking of making a video on writing machine code with a quill. would that be interesting?

there's still time. after all: at this point, we don't need "winners" and "losers" because it's not zero-sum. e.g. If webassembly opens a lot of doors

would you agree that, ultimately, it's JavaScript that's the mashed together little monster and TypeScript makes it more bearable (although, we understand the "lipstick on a pig" vibes some people get from it)? And thanks: we really want to surface things like ReScript (and others!) because of the whole "rising tide lifts all boats" thing.

@@MichiganTypeScript hehe wait, what other boats?

@@adicide9070 programming languages

It’s not elite, it’s just unfamiliar. OOP has tons of jargon for example, and it’s not labeled as “elite”. It’s also a different concept from a “sum type” (and especially from “product type”)

asking for a friend... what's the difference between a polymorphic variant, a sum type, and a product type?

@@MichiganTypeScript Great question! Here's how I think about it: A sum type is a type-level "OR". If a `foo` type is either A | B | C - it has 3 possible states (that's where the "sum" part comes from, 1 + 1 + 1). In typescript terms, this is a discriminated union. A product type is your typical struct/record found in almost all languages, in the case of JS that would be an object. It's called "product", because you have to multiply (cartesian product) all the combinations of the fields to get the number of states. If you have a record User with 3 boolean fields, it would have 6 possible states (2x2x2). A polymorphic variant is similar to a sum type, but solves certain problems where you'd want to use the same variant constructor in multiple places. Probably best to refer to Rescript and OCaml docs for more details, I don't think I can do them justice in this format :) ocaml.org/manual/5.2/polyvariant.html rescript-lang.org/docs/manual/latest/polymorphic-variant

​@@MichiganTypeScript A sum type is basically like an enum, an enumeration type has a limited/fixed number of variations, for example TimeOfDayEnum = PM | AM or LedEnum = Red | Green | Blue. In type theory, a type with a fixed number of variants goes by "sum type". The idea is that the total number of possible values for this type is simply the sum of its variants. TimeOfDayEnum has 2 possible values and LedEnum 3. A product type, on the other hand, is more like a record. For example, a Coordinate record can have entries for X and Y. Coordinate(X, Y). The number of possible values for Coordinate is the product of all possible values for X and Y, i.e., X times Y. Hence, the name product type (for example, Coordinate has 2 x 3 = 6 possible values for values int X = 1..2 and int Y = 1..3). Sum types and product types go also by the name Algebraic Data Type (ADT). Algebraic is math speak for types that combine. Example: take Person(Name, AgeCategory) where AgeCategory = Minor | Adult. Person is a product type combined with a Name and a sum type. Sum Type can also consist of other sum types or product types. Deeply nested or recursive Sum Types and Product types are possible too (json). In OCaml, sum types are also called Variants. For polymorphic variants google up "Polymorphic vs. ordinary variants in OCaml" (Yehonathan Sharvit).

@@akis854 apologies, I was being too dramatic 😆

this came up on twitter: thanks for the clarification. it's genuinely hard to get all of this straight: we're hoping that someone from the ReScript/ReasonML/Melange camps (even one person!) will accept our very-genuine offer to make a quick video breaking it all down, but no bites yet (although some people did some good stuff trying to whiteboard it).

> No one wants to use reasonml, dont associate with it. > But we do need a faster and open source version of something that is like typescript. not arguing (asking humbly): these back-to-back statements seem contradictory. Is it just that you don't like ReScript or that you _do_ like ReScript and want to break any associations between ReScript and ReasonML?

you betcha

the "rag tag group of volunteers" part resonates for sure - it's scary to step into the unknown, especially with your company's techstack at its mercy. would your opinion be different if ReScript has a corporate sponsor/overlord?

@@MichiganTypeScript sadly yes. It’s lame in the sense that I love languages and I want to see them all prosper like i want to adopt all shelter dogs but it’s a different reality when you’re making a decision about what your startup will be built on. I spent time learning OCAML leading up to the events that created Rescript, with the intention of transitioning from OCAML to Reason to build my web application-then I find out about all these changes in the ecosystem. Admittedly i was salty because I really enjoyed OCAML lol but still i would imagine many folks are in my boat and would be deterred by the same factors. Observing an ecosystem in the macro and seeing this kind of odd split is an immediate red flag. I’m sure it’s less scary for those already in it or that have no choice. P.S.- I ended up going with Swift :^|