<div>Thanks for your feedback Doug.</div><div><br></div><div>With regards to your first concern, I think that we won't actually lose any symmetry because if the user actually wants backward conversions they will define it themselves and so we won't ever have the case where we are giving this behavior for "free" and so the compiler will only have to do a one level check of an implicit conversion. And while we want to support the castingFrom implicit initializer (which can be failable if need be) it will always be user defined and never generated by a protocol extension or the compiler so things will still be Swifty. </div><div><br></div><div>From a technical standpoint I can't say much because I have no compiler experience whatsoever (yet). But I can see how this might mess around with the type checker and I can understand why this might be too difficult to implement for swift 3. However, I strongly believe the current numbers model of explicit conversion is too verbose and very non swift like. One of the biggest problems is the way that Int types are imported from C libraries and you have to keep converting back and forth between for example a UInt32 and an Int or something similar. Would you be open to restricting the feature to only work with number types and "hard code" that behavior into the compiler for swift 3 or do you think that's something we should not proceed with, or have a different solution for solving the numbers problem?</div><div>
<br> <div id="bloop_sign_1449906416752326" class="bloop_sign">
<div>
<div>
<div><font face="HelveticaNeue">Regards,<br>Manav Gabhawala</font><br></div>
</div>
</div>
</div> <p class="gmail_quote" style="color:#000">On December 12, 2015 at 1:57:10 AM, douglas gregor (<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>) wrote:</p> <blockquote type="cite" class="gmail_quote"><span><div style="word-wrap:break-word" class=""><div></div><div>
<title></title>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Dec 6, 2015, at 11:48 PM, Manav Gabhawala via
swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class="">I created a pull request with the proposal: <a href="https://github.com/apple/swift-evolution/pull/37" class="">Implicit Initializer proposal</a> (<a href="https://github.com/apple/swift-evolution/pull/37" class="">https://github.com/apple/swift-evolution/pull/37</a>). Feel free
to respond with suggestions/ideas with improvements to the proposal
and things that may be missing.</div>
</div>
</blockquote>
<div><br class=""></div>
<div>I have two comments. The first is on the suitability of this
proposal for Swift as a language; the second is about technical
feasibility of the proposal.</div>
<div><br class=""></div>
<div>Regarding suitability for Swift: for the most part, Swift’s
type system has a set of subtyping relationships that allow
implicit conversions (during compilation) that can be safely
reversed via conditional downcasting (the “as?” operator). For
example, say I have:</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>protocol P { }</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>struct X : P { }</div>
<div><br class=""></div>
<div>I can turn an X into a P:</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>var p: P = X()</div>
<div><br class=""></div>
<div>and then reverse the operation with a cast:</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>if
let x = p as? X { … }</div>
<div><br class=""></div>
<div>It’s a rather beautiful and powerful symmetry to the language.
If we add implicit conversions:</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>struct X {</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span> implicit init(_ y: Y) { … }</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>}</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>struct Y { }</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>var x: X = Y()</div>
<div><br class=""></div>
<div>Should we allow</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>let y = x as? Y { … }</div>
<div><br class=""></div>
<div>to work? If no, we’ve lost some useful symmetry to the type
system.</div>
<div><br class=""></div>
<div>If yes, we first need to figure out how the user can implement
it… perhaps some opposite operation that can fail:</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>extension Y {</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span> init?(castingFrom: X) { … }</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>}</div>
<div><br class=""></div>
<div>but how can we implement this in an efficient manner in the
runtime? We would effectively have to represent the DAG of implicit
conversion relationships in runtime data structures and evaluate
those with every “as?” cast, which implies a heavy runtime burden
for using this feature.</div>
<div><br class=""></div>
<div>On technical feasibility: introducing user-defined conversions
is a major complication to the type system, particularly in a
language with general type inference. We did go down this route
(there are vestiges of it still remaining in the expression type
checker), and it added a huge amount of complexity to the type
checker that compromised it’s ability to provide good type
inference. We would need a massive improvement to the expression
type checker for this to become technically feasible, and I’m not
sure we even can get there. Swift has a complicated type system
already—general type inference, parametric polymorphism, ad hoc
overloading, general subtyping—and the type checker is one of the
weaker areas of the implementation in part because of that
complexity.</div>
<div><br class=""></div>
<div>I don’t think we can bring a proposal up for review when there
is a significant chance that it cannot be faithfully implemented.
Obviously, asking you to “go implement a revolutionary new type
checker” isn’t a great response, either, which leaves us in the
unfortunate position of looking for some kind of assurance that,
should we decide we want to go in this direction, we actually *can*
go in this direction.</div>
<div><br class=""></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>-
Doug</div>
<div><br class=""></div>
<blockquote type="cite" class="">
<div class=""><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div id="bloop_sign_1449474489480073984" class="bloop_sign" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div class=""><font face="HelveticaNeue" class="">Regards,<br class="">
Manav Gabhawala</font><br class=""></div>
</div>
<br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<p class="airmail_on" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
On December 6, 2015 at 5:33:37 PM, Matthew Johnson via
swift-evolution (<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>) wrote:</p>
<blockquote type="cite" class="clean_bq" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span class=""></span>
<div class=""><span class=""></span>
<div class=""><span class=""></span></div>
<div class=""><span class="">I would be happy with any solution
that provides failable conversion so I would support that as
well.<span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">
<br class="">
Any chance we could see something like this in Swift 2.2 or Swift
3? I was hoping the failable initializers might be low hanging
fruit but it seems like the scoped feature would be more than
that.<br class="">
<br class="">
Sent from my iPad<br class="">
<br class="">
> On Dec 6, 2015, at 4:04 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>>
wrote:<br class="">
><span class="Apple-converted-space"> </span><br class="">
> Could definitely be interesting. I’d personally like to turn
it into a scoped feature along the lines of this post
though:<br class="">
><span class="Apple-converted-space"> </span><br class="">
> <a href="https://lists.swift.org/pipermail/swift-evolution/2015-December/000292.html" class="">https://lists.swift.org/pipermail/swift-evolution/2015-December/000292.html</a><br class="">
><span class="Apple-converted-space"> </span><br class="">
> -Chris<br class="">
><span class="Apple-converted-space"> </span><br class="">
>> On Dec 6, 2015, at 5:29 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class="">
>><span class="Apple-converted-space"> </span><br class="">
>> Related to this, but maybe easier to do in the short term:
what do you think of adding failable overloads to the numeric
conversion initializers Chris?<span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">
>><span class="Apple-converted-space"> </span><br class="">
>> They would throw or return nil if the runtime value could
not be preserved rather than trap, truncate, etc. Floating point
types might allow a tolerance for small value changes due to
precision, although I'm not sure if that would be good or not.
These initializers would be very useful when processing data from
an external source such as JSON that has an expected type but
cannot be trusted.<br class="">
>><span class="Apple-converted-space"> </span><br class="">
>><span class="Apple-converted-space"> </span><br class="">
>><span class="Apple-converted-space"> </span><br class="">
>> Sent from my iPad<br class="">
>><span class="Apple-converted-space"> </span><br class="">
>>>> On Dec 6, 2015, at 1:02 AM, Chris Lattner via
swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>>>><span class="Apple-converted-space"> </span><br class="">
>>>> On Dec 5, 2015, at 4:27 AM, Jonathan Hull
<<a href="mailto:jhull@gbis.com" class="">jhull@gbis.com</a>>
wrote:<br class="">
>>>> I understand why you can’t auto-convert from a
Double to a Float or Int32 to Int8. It is good that we have to add
the cast explicitly and think though the implications.<br class="">
>>>><span class="Apple-converted-space"> </span><br class="">
>>>> …but I don’t think through the implications
because we currently have a boy who cried wolf situation where we
have to explicitly cast everything (even the safe stuff).<br class="">
>>>><span class="Apple-converted-space"> </span><br class="">
>>>><span class="Apple-converted-space"> </span><br class="">
>>>> I think all of the numeric types should be able to
auto-convert if the conversion is safe (without loss of precision
or overflow).<br class="">
>>>><span class="Apple-converted-space"> </span><br class="">
>>>> For example:<br class="">
>>>> • If an Int is casting to a larger size (Int16
-> Int32)<br class="">
>>>> • Float -> Double<br class="">
>>>> • Float -> CGFloat<br class="">
>>>> • Int -> Float, Double, or CGFloat (but not the
other way)<br class="">
>>>><span class="Apple-converted-space"> </span><br class="">
>>>> I don’t see why these aren’t allowed. The forced
casts make my code much less readable. Are the casts above
dangerous in a way I am not aware of?<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>> I agree that the current Swift numerics model is
suboptimal, I personally would like to see small integers
implicitly promote to large integers (when they are known
lossless), have Float promote to Double, and have both Float and
Double promote to CGFloat (yes, I know that the Double ->
CGFloat promotion would be lossy on 32-bit apple platforms). I
personally don’t think that integer -> floating point promotions
are a good idea even if value preserving, since their domains are
so different.<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>> The problem with doing this today is that there are a
lot of dependencies we need to get resolved first.<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>> 1. The type checker is really slow, partially because
of too-many and too-crazy implicit conversions. We also get very
surprising behavior when they kick in. Specifically, IMO, we need
to reevaluate the T! <-> T and T to T? conversions. We have
thoughts on this, but should be discussed in a separate thread if
you’re interested.<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>> 2. These promotions should be expressible in the
library, not hard coded into the compiler. This means that we would
need a language feature to (e.g.) be able to define subtype
relationships between structs. Such a feature would be generally
useful and could allow us to push some of our existing compiler
magic out to the stdlib.<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>> 3. We want the existing work to revise the numerics
protocols to be better understood and hopefully
implemented.<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>> There are also a ton of unrelated specific problems
that should be addressed in various ways: e.g. macros like M_PI get
imported as Double instead of a typeless literal, forcing tons of
casts in code that wants to use it (e.g.) with Floats. These issues
are separable, and blocked on things like generic properties not
being in place.<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>> It would be great for interested contributors to start
pushing on any of the above issues to help unblock progress on
improving the numerics model.<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>> -Chris<br class="">
>>><span class="Apple-converted-space"> </span><br class="">
>>>
_______________________________________________<br class="">
>>> swift-evolution mailing list<br class="">
>>> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
><span class="Apple-converted-space"> </span><br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div>
</div>
</blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=XbU4wxnU83GyR7TGhOdBtBOchMF7PYvaYPXWDKda2ffzqnCyssPs1QYctIpuDX82e-2B6LQU05HrQ4V-2BvuaPmTmy-2BsNqf96JJwqXMCWQOpLC5pZYc4ZCb75lOuUn3i5VXCiZZ9w23oZUu-2BqKQL3Zc1hFbH0sXM-2FB9g180rXy7snMw0U-2FAvY2hBo0MK6nCsSqfEF3KHnfXE3-2FsGKvd9HNqPFCwLxpuTm8sPkyMVoFsCXFU-3D" alt="" width="1" height="1" border="0" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class=""><span class="Apple-converted-space"> </span>_______________________________________________</span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<span style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">swift-evolution mailing list</span><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">swift-evolution@swift.org</a><br style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div>
</blockquote>
</div>
<br class="">
</div></div></span></blockquote>
</div>