CohenArthur
CohenArthur
This issue we have of bindings/typed values being weirdly linked together by name resolution is really annoying. how do we deal with that. we need to clarify exactly what is...
> @Skallwar actually, the clippy-check action is [already being used in our CI i](https://github.com/jinko-core/jinko/blob/master/.github/workflows/clippy.yml#L17)n the `clippy.yml` workflow. We should probably either drop this file or remove the cargo check from...
(or `cargo check`)
```rust type Record(a: int, b: int); where foo = Record(a: 1, b: 2); where bar = foo with a = 15; where baz = foo with a = 16 with...
this means that flattening ambiguities in the typechecker would now be allowed, which I'm not a big fan of. so this is more of a design question than an actual...
I think overall it would be better to have helps around designing sum types. the above problem can be avoided by creating a sum type instead of an union type,...
so having a shorthand for creating these types in the same scope would work well: ```rust type Result[T, E] = type Ok[T](T) | type Err[E](E); // maybe? very verbose ```...
so probably it would be better to have `Maybe` be defined as a "sum type" as well - ```rust type Just[T](T); type Nothing; type Maybe[T] = Just[T] | Nothing; ```...
> What this will looks like when `f` take more than 1 arg? > > ```rust > func map[T, U, V](value: Maybe[T], f: T, V -> U) -> Maybe[U] {}...
it just looks less nice to me, I'd rather type `int -> string` than `func(int) -> string`