Hacker News new | ask | show | jobs
by tome 3735 days ago
No, forbidding orphan instances is exactly what you need so that both 1) duplicate instances are never defined, and 2) instances written by separate parties never conflict. If you think that should be an error rather than a warning then fine, but in either case code without orphan instances never has breakage due to instance clashes. It's the correct way to solve the problem.
1 comments

I wonder why you feel the need to comment if you haven't understood the issue.
This is needlessly rude.

I believe I've understood the issue, but if I've misunderstood then I feel extra need to comment, that my misunderstanding might be clarified.

From my first reading of what you'd written, tome seemed spot on.

On careful re-examination (after reading this comment), I think when you said "Things you don't receive warnings for:" you did not mean to say that you can write that code and receive no warnings (a reasonable interpretation), but that the warnings would not read as directed at the points you raise (also a reasonable interpretation) - which (you note) are substantially more important than "this is generally a good idea."

Firstly, one tends to believe that one understands before one comments even if one actually doesn't, so admonishment to understand before commenting will typically be redundant. Secondly, if one doesn't understand, blame can often lie on both sides of the conversation.

I claim that if you never have orphan instance warnings then your code has "the guarantees Kmett keeps boasting about". In particular you can never "define the same instance twice", and this of course implies that you cannot "have code which uses both instances".

What exactly is your complaint and why does my claim not address it?