<div dir="ltr">On Mon, Jan 16, 2017 at 3:32 PM, Karl Wagner <span dir="ltr"><<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On 16 Jan 2017, at 20:53, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-5095674634874927888Apple-interchange-newline"><div><div dir="ltr">On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Really glad to see this coming back :)<br>
<br>
I have a couple of questions:<br>
<br>
1) How does Strideable relate to Arithmetic?<br>
<br>
My understanding is that Strideable allows non-numeric types to express different-type addition and subtraction, and that Arithmetic is for numeric types only (derives from ExpressibleByIntegerLiteral) and allows then to express same-type operations. Is that correct?</blockquote><div><br></div><div>My understanding was that heterogeneous addition and subtraction using operators are not supported not merely due to compiler limitations but as a fundamental philosophy, because the type of the intended result can be unclear to human readers and unintentional promotion is to be avoided? In that vein, my understanding was that having those operators available for Strideable was inconsistent and overdue for removal, and `advanced(by:)` is the intended spelling for advancing a value by a distance of a different type.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If so, it would be nice to add it to the proposal so people know when they should conform (or set their generic constraints) to one or the other.<br>
<br>
2) Can SignedNumber get some operators now?<br>
<br>
Strideable.Stride is bound to this weird protocol ‘SignedNumber’. You can create instances of it out of thin air via an integer literal, but you can’t accumulate Strides to find the overall distance between some adjacent Strideables.<br></blockquote><div><br></div><div>I understood these new protocols to mean that SignedNumber is headed for deprecation?</div></div></div></div></div></blockquote><div><br></div></span><div>It would be nice if the proposal said that, then (and mentioned the corresponding change to Strideable.Stride). I assume it will be replaced with SignedArithmetic, then.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, #1 is why I don’t like the Strideable operator deprecation being part of the proposal (and therefore part of the language specification). It doesn’t solve the underlying issue, which is that our integer literal protocols aren’t really good enough - they’re not useful enough outside the standard library (see: <a href="https://bugs.swift.org/browse/SR-920" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/<wbr>SR-920</a>), and evidently the compiler isn’t able to use them to infer types correctly. Perhaps fixing it is a low priority, and that’s fine, but what about if somebody else defines this operator in their library? They start of break lots of valid code because the compiler can’t do the right thing. Improved literal protocols may be the better way to resolve that problem.<br></blockquote><div><br></div><div>I agree totally that literals are aching for improvements as outlined in SR-920. Not sure how it relates to integer protocols though. What are some examples of valid code that get broken today because of compiler limitations?</div></div></div></div></div></blockquote><div><br></div></span></div>The PR that implemented this fixed a bug with integer literals - basically, the thrust of it (as I understand) is that the compiler can’t figure out which is the preferred overload. It doesn’t know to prefer same-type arithmetic when resolving literals involved in operators.</div></blockquote><div><br></div><div>Yes, that's a compiler shortcoming and a practical reason to remove + for the moment. However, there's also the other reason to remove +, which is that Swift doesn't have a promotion model for integer types, and until it does heterogeneous operations shouldn't be spelled using + whether the compiler knows how to pick a preferred overload or not...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>My problem with just fixing the problem by removing that operator is that anybody could add it back in their own code, and that should be perfectly allowable, but if they did so basic expressions would fail to compile.</div></div></blockquote><div><br></div><div>This would only break their own code unless it's also exported in a library. For the former, if we fix something because it's broken, the fact that someone can put it back into their own code to break it isn't a reason for us not to fix it :) As to the latter scenario, clashes between libraries that export different implementations of the same operators and the inability for end users to choose not the import them with the rest of the library _is_ actually an annoying issue that needs improvement. This is getting away from the topic of integers and distinct from the topic of literal protocols, but tackling this topic is sorely needed IMO.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>To me it sounds preferable to leave this as a implementation artefact until we get a chance to make the literal protocols better.</div><div><br></div><div>Strideable isn’t some esoteric protocol just for collection indexes, you know. It’s very useful for any quasi-numeric type whose absolute value is semantically different from a difference. For example, I have strongly-typed wrappers for a ByteOffset within a binary file and a LineNumber inside a text file. These wrappers allow me to write extensions (for example to clamp to the bounds of a particular file), and ensure that I don’t accidentally mix semantically different values. They are both Strideable by Int, which is a better semantic fit than Arithmetic (LineNumbers are absolute, should you be able to add them? What does LineNumber * LineNumber mean?).</div></div></blockquote><div><br></div><div>`advanced(by:)` is still there, yes? It's not as terse, but neither is `truncatingRemainder(dividingBy:)` that replaced `%` for floating point types. I think the motivation is similar in both cases (i.e. to distinguish two subtly different operations from each other).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>So my point is basically that it’s an important protocol (maybe not so much in the standard library, but certainly beyond).</div></div></blockquote><div><br></div><div>Strideable? I didn't think Strideable itself was going away. I'd be sad if it did; for one, all the Unsafe*Pointers are Strideable and that has its uses.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div>- Karl</div><div><br></div></font></span></div></blockquote></div><br></div></div>