<div>I can&#39;t speak to the core team&#39;s motivations, but what I&#39;m hoping for personally is a solution to this problem:<br><br>Currently, there are a bunch of protocols to which integer types conform. However, they aren&#39;t very useful (not really usable) for generic programming. One example: As an exercise, I tried to port a binary greatest common denominator function to Swift, generic over SignedNumber. However, I can&#39;t bit shift. I have to divide by two. Because &lt;&lt; isn&#39;t required or implemented for two SignedNumber values. This proposal arranges the cascade of protocols to which integer types conform, and their requirements, so that useful generic algorithms that use integers can be written without retroactively conforming them to one&#39;s own made-up protocols every time. Every so often one or two minor new facilities are thrown in that complete the picture, but the biggest part of this proposal is the rearranging.</div><div><br></div><div>I don&#39;t read this proposal as having as a goal the implementation of advanced math in the standard library. However, note that it is not possible to retroactively use an existing protocol in the standard library to refine your own protocol in another project. So, what&#39;s important is that the protocols here don&#39;t gratuitously preclude (preclude for no technically justifiable reason) the &quot;plugging in&quot; (conforming) of third-party numeric types to standard library protocols, so that where these types have the semantics required they too can be used with algorithms written to be generic over types conforming to standard library protocols.</div><div><br></div><div>I think the key question about &quot;naming things&quot; that&#39;s left over here is: since our modeling of sets of infinitely many things (e.g. integers) is necessarily imperfect on a machine with finite memory, is it wise to use terms from mathematics that describe those infinitely many things for our imperfect, finite models? For now, the proposal chooses deliberately less &quot;mathy&quot; terms so that Swift doesn&#39;t (a) make these protocols impenetrable to the average user; and (b) it doesn&#39;t overpromise and say that our imperfect model of something is _the_ way to model that thing. Nonetheless, these mathy terms describe some attributes of integers, real numbers, etc., that apply as much to the algorithms we may want to write in Swift as they do to math. Therefore, I think we want to ensure that even as we don&#39;t insist on &quot;mathy&quot; names, we absorb as avidly as we can the insights about integer semantics that the mathematicians have worked out, in the hopes of making our protocols maximally useful.</div><div><br></div><div>But you&#39;re precisely right that a laudable aim is to help, not hinder, third-party library design.</div><div><br></div><div><br><div class="gmail_quote"><div>On Mon, Jan 16, 2017 at 20:25 Jay Abbott via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I barely understand any of this thread, so these might be silly questions, or based on a total misunderstanding the goals here, but it seems to be about: a) clever/advanced mathsy things; b) naming things; and c) the standard library... my questions are:<br class="gmail_msg"><br class="gmail_msg">Do specialised clever advanced mathsy libraries all work exactly the <br><br>same, or do they have slightly different behaviours or conventions or <br><br>semantics in different fields of study?<br class="gmail_msg"><br class="gmail_msg">Is the the goal here to define a common/shared <br><br>sub-set of specialised maths libraries, but in the standard library? Would that be useful by itself?<br class="gmail_msg"><br class="gmail_msg"></div>Could it be possible that &quot;naming things&quot; in the standard library would trample all over possible uses in external libraries, making it harder rather than easier for specialised maths libraries to construct their interfaces in a non-confusing way?<br class="gmail_msg"><br class="gmail_msg"></div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Tue, 17 Jan 2017 at 01:39 Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg"><br><br>on Mon Jan 16 2017, Xiaodi Wu &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br>&gt; Strideable? I didn&#39;t think Strideable itself was going away. I&#39;d be sad if<br class="gmail_msg"><br><br>&gt; it did; for one, all the Unsafe*Pointers are Strideable and that has its<br class="gmail_msg"><br><br>&gt; uses.<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br>Nobody&#39;s proposing to remove Strideable.<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br>--<br class="gmail_msg"><br><br>-Dave<br class="gmail_msg"><br><br><br class="gmail_msg"><br><br>_______________________________________________<br class="gmail_msg"><br><br>swift-evolution mailing list<br class="gmail_msg"><br><br><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br><br></blockquote></div><br><br>_______________________________________________<br class="gmail_msg"><br>swift-evolution mailing list<br class="gmail_msg"><br><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br></blockquote></div></div>