[swift-evolution] Proposal: Add Flags to Disable [Optional] Conversions

Chris Lattner clattner at apple.com
Wed Dec 9 19:07:57 CST 2015


> On Dec 9, 2015, at 3:18 PM, Developer <devteam.codafi at gmail.com> wrote:
> 
> 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.

I’m saying that I’d prefer this to be something “inside” the source file.  If the -W flags were specifiable inside the source file, that would be fine with me in principle, it still needs a concrete design of course.

-Chris

> 
> 
>> On Dec 9, 2015, at 6:10 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>> 
>> On Dec 9, 2015, at 3:01 PM, Developer <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> wrote:
>>> OK, so Optional conversions need to be re-evaluated, but what about passing a flag disabling all implicit conversions entirely?
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> -Chris
>> 
>> 
>>> 
>>>> On Dec 9, 2015, at 5:47 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Dec 9, 2015, at 11:20 AM, Developer via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> Hello all,
>>>>> 
>>>>> 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 (https://github.com/typelift/Swiftz/blob/master/SwiftzTests/EitherSpec.swift#L72 <https://github.com/typelift/Swiftz/blob/master/SwiftzTests/EitherSpec.swift#L72>) to show up.  For the community, the question is threefold:
>>>>> 
>>>>> 1) Would anything break if this were applied?
>>>>> 2) Would it be appropriate to expand the flag by allowing all implicit conversions to be disabled?
>>>>> 3) If you remain unconvinced it should be an error, would implicit conversion warnings be more appropriate?
>>>> 
>>>> Hi Robert,
>>>> 
>>>> 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.
>>>> 
>>>> -Chris
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/b147bbee/attachment.html>


More information about the swift-evolution mailing list