Will there be generics?

[travis-leith]

From here we get

struct Point {
	x Int
	y Int
}

but what about

struct Point<`a> {
	x `a
	y `a
}

In other words will generics be supported? If yes, will there be some sort of system for constraining generics, such as

typeClass ConvertableToFloat {
    toFloat: Int -> Int
}

implement ConvertableToFloat for Int with
    toFloat = someFunction

struct Point<`a where `a:ConvertableToFloat> {
	x `a
	y `a
}

[kendfss]

Honestly, given that the syntax already supports parameters, generics shouldn't actually be necessary. A good example of what I mean in the wild is Zig's comptime separation; I think their implementation is clunkier than necessary. Essentially, all you should need is a way to let the compiler know that you want to declare the exact type later. I think the best way to do this is to use first class functions (as you suggested in an other thread) and something like a later|one|todo type/keyword in order to declare that the exact type will be given by the caller; essentially a generic type placeholder. In a sense, structs declared with that type/keyword would be underlaid by closures, the compiler could be able to use inference on the call to determine how to fill out and verify the type. I think it could tie in well with allowing structs to have default values; that way structs with no defaults effectively become interfaces. Not yet familiar with the compiler internals but a naive implementation may sacrifice memory layout guarantees, however we could use the notions of commutative and associative types; associative types having an invariant memory layout; commutative types would be laid out by the compiler.

instead of

typeClass ConvertableToFloat {
    toFloat: Int -> Int
}

we could just use hasattr (like in python) and typeis/sig(nature)is. These would just be dyadic bool returning functions instead of a whole new language feature. Adding impls to the mix, and using `, is rust-like in ways that a simple language with so much potential should probably avoid.

That said, I'm working on a proposal that's probably quite hypocritical, but I think it safely avoids reproducing the worst aspects of type systems in functional languages; having to have 3 versions of every type you want to use in more than one context (struct/interface/impl).