> > Finally the function wouldn’t work in guards, but that’s true of most of > custom functions that are lacking natively in BEAM. >
Which leads to a discussion I had with Eric some time ago about the inclusion of decimal into the standard library: if the package is not going to feel integrated with the rest of the language (like any other native type in the decimal case) then what are the benefits of including it in the language if it is going to provide the same feature set it would as a package? In other words, if won't feel as part of the language as < and >, then why shouldn't it be a package? Do we expect the majority of Elixir developers to use it? Does it considerably change the way we program in Elixir? > Yes. I see big benefit for that function with native calendar types that > ship with elixir. Including it in core makes sense in that regard. > Furthermore, standalone protocols are a mildly bad idea. If the decision of including a protocol in standard library is because of issues for doing conflict resolution for protocols then we need to improve protocols and not add more protocols to the language. The latter solves the issue only for the protocols added as part of the language while we leave everyone else hanging. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LyduWvoTKS6wmxrzupEPUqxNt7vdRFjWGTmk5yyc83sw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
