TMP refactoring in Kvasir

[odinthenerd]

There are still a good number of things in Kvasir which are not in line with modern TMP style. Especially offending are the uppercase nested Types (rather than lowercase) and the idiom of returning by inheritance. This is actually starting to infect things outside of core like MakeAction in Io and should be refactored soon.

Things could also run much faster if we made many more type empty inside and relied on pattern matching to work on them (instantiating is less costly for the compiler if the struct is truly empty).

[CvRXX]

Another thing that I thought of on my way home, should we use an alias for the brigand stuff. If we want to swap out brigand we have to rename every call now. Like the use of "brigand::list", if a new better library is available w have to change all those lines. I think we should have a mpl::list that points to the brigand list. What do you think @odinthenerd?

…

On 11/30/16 16:03, Odin Holmes wrote: There are still a good number of things in Kvasir which are not in line with modern TMP style. Especially offending are the uppercase nested Types (rather than lowercase) and the idiom of returning by inheritance. This is actually starting to infect things outside of core like MakeAction in Io and should be refactored soon. Things could also run much faster if we made many more type empty inside and relied on pattern matching to work on them (instantiating is less costly for the compiler if the struct is truly empty). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#90>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB0FGlvCaJT1prQ48iwUziaXmxMBUkKrks5rDZA4gaJpZM4LASj5>.

[odinthenerd]

I think a lot of the current TMP elite are involved in brigand, so there is little chance that it will be deprecated without someone coming up with a paradigm shifting change in highly performant meta programming. Therefore its not possible/performant to wrap the whole lib, for example lambdas could drastically change and no amount of wrapping can abstract that. What we could do is alias everything in a kvasir::mpl and only allow trivial eager lambdas MP11 style.

I do agree that peppering the lib with brigand::list is probably not good for long term stability. In a general sense we need to be especially careful with dependencies which come from other domains as they could change in future in ways we cannot support on microcontrollers.