<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div class="">The review of "SE-0041: Updating Protocol Naming Conventions for Conversions" begins now and runs through May 16. The proposal is available here:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md</a><br class=""></div></div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""></div></div></blockquote>-1.</div><div><br class=""></div><div>I’m not 100% sure on the names (can we paint the bike shed plaid?) but more importantly, I’m not sure the groupings are adequate</div><div><br class=""></div><div>RawRepresentable seems to represent a sub-type declaring a super type coercion system.</div><div><br class=""></div><div>The various literal-based initializers are not necessarily coercion operators - some operations (e.g. initializing a Set from a literal with repeating elements) are lossy. These initializers also are not given a mechanism to recover from failure (possibly because the literals mean that failure represents a precondition failure in the written code?). That would imply that these literal-based initializers are special - a non-literal needs failure-reporting semantics.</div><div><br class=""></div><div>CustomStringRepresentable is not meant for any sort of type conversion. It returns a user presentation of the object as text (while the Debug variant is meant to return a developer presentation)</div><div><br class=""></div><div>So I don’t feel these represent In, Out, and InOut but instead three different classifications of conversions.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?</div></div></blockquote>Now is a great time for naming consistency</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></blockquote>Future direction there may be another change if coercion is defined as a language feature (such as implicit numeric coercion)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div></div></blockquote>I thought of Ruby and the difference between to_s and to_str. The idea of a representation as a type vs coercion to a type is a hard one to learn.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div></div></blockquote>A quick reading.</div><div><br class=""></div><div class="">-DW</div></body></html>