incorrect lib folder

[unional]

Hi, I notice that the lib folder does not have the right folder structure. So the types cannot be imported.

It should be a quick fix. I can take a look and file a PR.

[KiaraGrouwstra]

thanks!!

I fear the issues in this repo might be deeper-rooted tho :sweat_smile:, after some TS upgrades I ended up running into non-terminating types, pretty frustrating...

[unional]

No program. I have a similar library (type-plus) and working on something interesting. After I opened this issue, I tried out ts-toolbelt and it seems to do what I need (lazy to implement myself. 🤣 )

[KiaraGrouwstra]

hehe nice, glad you found it! honestly I wonder if the problems in this space have been solved now... I feel like some of the other libs dodged the issue by just lowering their ambition, but given the non-termination I just failed to properly capture the big issues in unit tests, which just made things super difficult...

[unional]

:) I'm just using one of the function it has and the syntax was a bit weird. The interesting thing I'm working on is almost ready.

It is doing something pretty amazing IMO. 🤣

const t = types.object.create({
  a: types.union.create(types.number.create(1), types.boolean.true),
  b: types.string
})
const value: unknown = { a: 1, b: '' }
if (satisfy(t, value)) {
  assertType<{ a: true | 1, b: string }>(value) // <-- type narrowing
}

It probably can be used as a replacement of prop-types.

If you are interested, feel free to checkout the PR: https://github.com/unional/type-plus/pull/71

🌷

[KiaraGrouwstra]

I hadn't even checked prop-types before, but man, looks a bit clunky how we have to do things in TS. like the idea tho. one thing I was interested in at the time was gradually-typed functions -- still need to figure out if any language already kinda brings that for its standard lib by default...

[unional]

What do you mean by gradually-typed functions? implicit any?

[KiaraGrouwstra]

I mean typing functions in such a way that if the types give more info the result type you get has more info, but if any of the input types ends up not offering as much info that would be incorporated into the result type in a sensible way as well. Okay idk how much of the examples listed on wikipedia there actually match what I want... I imagine there's gotta be like some fancy theorem proving language that did things right tho??

[unional]

if any of the input types ends up not offering as much info that would be incorporated into the result type in a sensible way as well.

From your description you seems to refer to "partial" return type inference. I think you can already do that in TypeScript. You can mark part of the function input as any and that's that.

IMO the main problem is there is not much of such needs. If it is a strongly typed language, the types are discrete and inference will just work (e.g. Haskell). If it is a dynamic language, inference would be very limited as the problem is too difficult to solve.

TypeScript is in a special place because it is adding types to JavaScript.

[KiaraGrouwstra]

well, there is stuff in-between types [1,2,3] and any, such as [number] or even just [any]. I feel like right now there we have only just started to see attempts to type functions to take into account the [1,2,3] level of granularity, much less take into account any potential level of granularity for any input parameter for any function in a standard library (tho for me ramda.js sorta is JS's standard library).

[unional]

:) btw I just release type-plus 3.0. It has a new runtime type checker that's quite interesting. Feel free to check it out. 🌷

[KiaraGrouwstra]

love the documentation, looks pretty fun! added a link to it in the readme over here now. :)

[unional]

Thank! :)