ticki

One thing that's important is consistencies. HKT is a very powerful concepts, and will probably be used a lot when (if?) they're introduced. Having syntax and semantics which is consistent...

Relevant: https://gist.github.com/14427/af90a21b917d2892eace

@antonkatz Right, HKTs might render big parts of the API obsolete, so sure adding HKTs is a big thing. But they provide a really nifty abstraction allowing very clean API....

> What I meant by my comment, is that it's hard to ask a functional programmer to write code without HKTs. I see. I must have misunderstood the comment.

@nikomatsakis has some interesting thoughts about HKTs here: https://github.com/rust-lang/rfcs/pull/213#issuecomment-65756753

:+1:, I wasn't aware this wasn't already done.

@sfackler I imagine two ways of doing it: 1) Using a restricting virtual environment. 2) Restricting the code to a subset of Rust. The former is probably the easiest. However,...

In any case, this should be done in such a manner that it does not cause very inconsistent libraries, perhaps by letting the named parameters be optional? For example the...

Also, this feature could easily be misused by taking named parameters instead of structs, which, I think, is a bad thing.

I see, but that's why we got macros. If you want heterogenous variadicity, you gotta go with macros, after all the Rust macro system is very powerful.