<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Jul 24, 2017, at 9:22 AM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca">felixcca@yahoo.ca</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">There are other alternatives that don't use generics. Last time this came around, the straw man syntax was (4 x Int), and it was merely to be a shorthand for (Int, Int, Int, Int).</div><div class=""><br class=""></div><div class="">Every non-existing feature that needs to be implemented to make fixed-size arrays work are a drag. I've said it before and I'll say it again: major features that this proposal wants to rely on should be brought independently and discussed on their own. There are real problems with monolithic proposals:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">They couple independent features in an all-or-nothing basket</li><li class="">They consume a huge amount of review and design energy</li><li class="">They force sub-features to be viewed through the telescope aimed at the main feature, and make it easier to miss problems or opportunities in the big pictures</li></ul><div class=""><br class=""></div></div><div class="">The last point is especially worrying to me because things like non-type generic parameters are *much bigger* than fixed-size arrays. I think that it's a priority inversion to discuss non-type generic parameters as a bullet point of fixed-size arrays.</div></div></blockquote><br><div>+ all the 1s</div><div><br></div><div>- Dave Sweeris</div></body></html>