<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 5:45 PM, Kelvin Ma <span dir="ltr">&lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <span dir="ltr">&lt;<a href="mailto:2th@gmx.de" target="_blank">2th@gmx.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">a good idea on paper, a disastrous one in practice. What happens if every geometry library declares their own Point type?</div></div></blockquote></span>That would be ugly („disastrous“ imho is a little bit to strong — C++ had/has similar issues, and other languages as well)</div><div>But if there would be a simple Point struct in a library that is popular (could be achieved by shipping it alongside the stdlib), this problem would be solved (there has been a pitch lately, but I guess it faded away silently).</div></div></blockquote></div></div><div class="gmail_extra"><br></div></div></div><div class="gmail_extra">it’s ugly in C++ and disastrous in Swift because C++ has fixed layout guarantees and everyone agrees that z comes after y comes after x, so you can unsafe-bitcast the foreign C++ points into your own points “for free”. you can’t do the same thing in Swift<br></div></div></blockquote><div><br></div><div>ps i remember that pitch because i’m pretty sure i was the one that pitched that. consensus seemed it was too high level for inclusion (even though having it at the stdlib level would do wonders for things like SIMD) and everyone got distracted by “integers as generic parameters” (because we love `<span style="font-family:monospace,monospace">Vector&lt;3&gt;</span>` ig) because everything on this list always devolves into “but this is <i>really</i> a problem with the <i>generics system</i>” and since no one knows how to fix the generics system everyone calls it a day and forgets about the original issue<br></div></div><br></div></div>