<div dir="ltr">supporting checking if code uses some (org / team / project)  policy of "class X with Type T" linting/checking/warning  as some sort of plugin/warning flag def would be useful. <div><br></div><div>I think we'd want to warn on the use site of the combination when that flag is set, rather on the definition site</div><div><br></div><div>a sort of "-fWarnSubtleInstanceUsage" thats off by default and would take pairs of class and type names?</div><div><br></div><div>are we collectively saying the objections come down to visibility of tracking down a "whys this size calculuation always 1, am i going insane" bug?</div><div><br></div><div>or is the issue moreso that length is a constant / fixed size for tuple, and this acts unexpected in nested data structures?</div><div><br></div><div><br></div><div>to reiterate ,my perspective is: +1 from me, one of the people who are concerned about the user impact should contribute a not in -wall linting/checking flag that warns on tuple invocations of length from foldable as the motivating use of some new warning pragma that can support other opt in examples.  let someone who wants that warning for (,) contribute it, lets not let it block having instances for higher arity tuples.</div><div><br></div><div>i realize "go write the patch" might be a strong (or sometimes even toxic) stance to take, but caring about an issue personally is the best motivator, and it sounds like the fundamental problem already exists with stuff already in base! adding these instances does not change the existence of the issue thats the root of the mild controversy here.  it already exists, give us tools to make it easier for users to suss out ! </div><div><br></div><div>let the higher tuples have their instances! :) </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 3, 2019 at 11:30 AM <<a href="mailto:amindfv@gmail.com">amindfv@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div><br></div><div><br>El 3 abr 2019, a las 02:59, Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>> escribió:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">A strong -1 from me for the exact same reasons given 2 years ago: <a href="https://mail.haskell.org/pipermail/libraries/2017-March/027883.html" target="_blank">https://mail.haskell.org/pipermail/libraries/2017-March/027883.html</a>  Nothing has changed since then, we don't even have a warning flag yet (see #11796). Just 2 remarks:</div><div dir="ltr"><br></div><div>   * "Doesn't break existing code" is an invalid argument: Removing e.g. type checking won't break existing code, either, but this is probably not a worthy goal. And the proposal goes a step towards removing type checking in a very subtle way.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Another strong -1 from me for exactly this reason. I've seen too many bugs where a datatype was changed and suddenly e.g. "length" was being called with a ([x], y) instead of a [x], and we're without warning returning 1 every time.</div><div><br></div><div>I'd also very much appreciate work on the compiler flag for warning on an instance!</div><div><br></div><div>Tom</div></div>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>