> On Apr 30, 2019, at 23:29, José Valim <[email protected]> wrote: > > Do you have another example of where this functionality would be used? > Because config/config.exs is not really deprecated, we just won’t generate it > by default.
Ah, but the _reason_ you're making this change is that you don't consider it to be a Best Practice. So, even if it's "not really deprecated", you don't want to put programmers into the position of doing it unintentionally. I agree with this, but it doesn't solve the problem of existing code. And code smells accumulate... I haven't been tracking changes closely, so I can't give you any other specifics. And really, that is kind of my point. As a programmer using the Elixir tooling, I shouldn't _have_ to track changes closely: Mix should be able to tell me about questionable practices in my code base. I can then decide what, if anything, I want to do about them. By way of analogy, I disagree with the formatter's handling of inline white space. However, unlike Golang, Elixir allows me to disagree. And, if I am curious about what things the formatter would change, I can simply run it on a copy of my source tree and do a recursive diff(1). So, I get information, but I'm not compelled to do anything I don't want to. My proposed enhancement would be in this same spirit. -r -- 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/C483A5A8-F31F-4573-8347-4C28E0BF5B23%40gmail.com. For more options, visit https://groups.google.com/d/optout.
