<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 class="">Oh, definitely. So, how about a `-Wconversion`-style thing that you can `-Werror` with to get the same effect? I think this kind of thing satisfies your requirements; It doesn’t create new dialects, is flippable per-file, and doesn’t change the interpretation of valid swift unless the author fully intends to do so.</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 6:10 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Dec 9, 2015, at 3:01 PM, Developer <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:<div class=""><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">OK, so Optional conversions need to be re-evaluated, but what about passing a flag disabling all implicit conversions entirely?</div></div></blockquote><div class=""><br class=""></div><div class="">I don’t like the idea of having different incompatible dialects, and behavior changing modes. That said, I’m personally not opposed to providing functionality that would enable people to use a reduced subsets of the language, and have the compiler enforce it. For example, I don’t have a problem with someone saying they never want to use the x!, as!, try! family and have the compiler tell them if they do.</div><div class=""><br class=""></div><div class="">To relate this to your question, I’d be fine with functionality that causes the compiler to produce an error when code requires an implicit conversion, but I wouldn’t want them to be just “disabled”, because I think this could change the interpretation of valid swift code (in admittedly weird cases).</div><div class=""><br class=""></div><div class="">In terms of how to express this, I’m not in love with modal compiler flags :-). I’d much rather this sort of requirement be specified as a pragma-like construct that applies to an arbitrary scope (e.g. class or function body) or a whole file. This keeps the code self describing.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 5:47 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 11:20 AM, Developer 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=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello all,<br class=""><br class="">Considering what I do with Swift, I recently posted a pull request that adds a flag to the frontend that would disable all implicit optional conversions by making them errors. From my perspective, implicit conversions are convenient, but they allow certain strange behaviors (<a href="https://github.com/typelift/Swiftz/blob/master/SwiftzTests/EitherSpec.swift#L72" class="">https://github.com/typelift/Swiftz/blob/master/SwiftzTests/EitherSpec.swift#L72</a>) to show up. For the community, the question is threefold:<br class=""><br class="">1) Would anything break if this were applied?<br class="">2) Would it be appropriate to expand the flag by allowing all implicit conversions to be disabled?<br class="">3) If you remain unconvinced it should be an error, would implicit conversion warnings be more appropriate?<br class=""></div></div></blockquote></div><br class=""><div class="">Hi Robert,</div><div class=""><br class=""></div><div class="">The rules for implicit conversions are optionals need to be re-evaluated, I expect this to happen for Swift 3 (after Swift 2.2 is out of the door). Once that is done, we can talk about a proposal like this.</div><div class=""><br class=""></div><div class="">-Chris</div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>