roslyn

ving a type system at all." is clearly hyperbolic nonsense. > If we were willing to be unsafe we could just cast to the desired type. But it isn't unsafe! Not specifying a `struct` constraint is a bug. If you provide the constraint then it's safe. Trying to compare that to a dynamic cast where you have no type-system enforcement to one where you do is just idiotic. > I'd sooner pass the module dictionary explicitly, like one does in ML, than adopt a technique that would normalize having "default(...)" in my codebase. At no point was this trying to force you to use this technique. It was a reply to "Once you've got return type polymorphism, you really start to miss it in other languages. The simplest example possible is mempty". I use this technique very successfully a lot, and the exact mechanism (of using `default`) is in the process of being wrapped up into a new type-classes grammar for C# [1]. So, I guess you'd probably prefer to wait for that... [1] https://github.com/MattWindsor91/roslyn/blob/master/concepts...

ing, int>, Lst<string>, Lst<int>>(list); Or an Option: Option<int> res2 = ParseInts<FOption<string, int>, Option<string>, Option<int>>(opt); And it will happily map the bound values. FLst and FOption are essentially the 'class instances'. Functor is the 'type class', it's just a C# interface [2]: public interface Functor<FA, FB, A, B> { FB Map(FA ma, Func<A, B> f); } The key thing is that 'this' won't be used, so the first argument is the value to be mapped. FLst looks like this [3]: public struct FLst<A, B> : Functor<Lst<A>, Lst<B>, A, B> { public Lst<B> Map(Lst<A> ma, Func<A, B> f) => ma.Map(f); } And FOption like so [4]: public struct FOption<A, B> : Functor<Option<A>, Option<B>, A, B>, BiFunctor<Option<A>, Option<B>, Unit, A, B> { public Option<B> BiMap(Option<A> ma, Func<Unit, B> fa, Func<A, B> fb) => ma.IsNone ? fa == null ? Option<B>.None : fa(unit) : fb == null ? Option<B>.None : fb(ma.Value); public Option<B> Map(Option<A> ma, Func<A, B> f) => ma.IsSome && f != null ? Optional(f(ma.Value)) : None; } As you can probably tell, the amount of clutter from specifying generic type-parameters that the compiler could (relatively) easily work out on its own, is pretty annoying. Which limits it's usefulness somewhat. But if you want to write truly generic code, it's doable (with some caveats of course. you'll notice that the Functor type isn't quite as strict say the definition in Haskell). I'm currently updating my language-ext project to add type-classes [5] and class-instances [6], in the hope that the C# team will take pity on me and make this technique a language feature (it's been seriously turning my head inside out trying to make it work with higher-order types like monads). This is already being investigated by some Roslyn team members [7]. I figured this feature was unlikely to move seriously in the near term without some indication of real world need. [1] https://github.com/louthy/language-ext/blob/type-classes/Lan... [2] https://github.com/louthy/language-ext/blob/type-classes/Lan... [3] https://github.com/louthy/language-ext/blob/type-classes/Lan... [4] https://github.com/louthy/language-ext/blob/type-classes/Lan... [5] https://github.com/louthy/language-ext/tree/type-classes/Lan... [6] https://github.com/louthy/language-ext/tree/type-classes/Lan... [7] https://github.com/MattWindsor91/roslyn/blob/master/concepts...