Proposal: Add Flags to Disable [Optional] Conversions


(Robert Widmann) #1

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) 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?

Thanks,

~Robert Widmann (CodaFi)


(Chris Lattner) #2

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

···

On Dec 9, 2015, at 11:20 AM, Developer via swift-evolution <swift-evolution@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) 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?


(Robert Widmann) #3

OK, so Optional conversions need to be re-evaluated, but what about passing a flag disabling all implicit conversions entirely?

···

On Dec 9, 2015, at 5:47 PM, Chris Lattner <clattner@apple.com> wrote:

On Dec 9, 2015, at 11:20 AM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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) 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


(Chris Lattner) #4

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 3:01 PM, Developer <devteam.codafi@gmail.com> wrote:

On Dec 9, 2015, at 5:47 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Dec 9, 2015, at 11:20 AM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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) 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


(Robert Widmann) #5

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.

···

On Dec 9, 2015, at 6:10 PM, Chris Lattner <clattner@apple.com> wrote:

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

On Dec 9, 2015, at 11:20 AM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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) 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


(Kenny Leung) #6

Yes!

···

On Dec 9, 2015, at 3:10 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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.

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 Lattner) #7

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 3:18 PM, Developer <devteam.codafi@gmail.com> wrote:

On Dec 9, 2015, at 6:10 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

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

On Dec 9, 2015, at 11:20 AM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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) 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