Delaying the enforcement of ".self" out of Swift 3?


(Douglas Gregor) #1

Hi all,

While working on some unrelated refactoring, I stumbled across a minor fix that would make use properly enforce “.self” when we want to get the metatype of a named type. For example, the Swift compiler currently (incorrectly) allows

  sizeof(UInt)

which should be

  sizeof(UInt.self)

The fix for this is actually pretty simple (patch attached), but the question is… do we want to fix the problem, if we think that we’ll get SE-0090 that makes “.self” go away?

  https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md

On the one hand, I want to fix the problem:

  * This came out of a desire to make the AST more sane. Essentially, the folding of expressions into TypeExprs—which will go away entirely if/when SE-0090 is implemented—is pulling in the parentheses describing call arguments. Without the fix, we still have weird AST.
  * SE-0090 is labeled as “deferred out of Swift 3”, so having the compiler not implement the stated language for an entire release cycle seems really unfortunate.

OTOH, I don’t want to jerk people’s code around, forcing them to add “.self” now only to remove it a year from now (or whenever).

Thoughts?

  - Doug

enforce-metatype-self.patch (5.89 KB)


(Jordan Rose) #2

We have a bug for this, https://bugs.swift.org/browse/SR-899. I had pretty much the same reaction you did, which is that it's definitely a bug but it's probably not worth changing right now.

Jordan

···

On Jun 2, 2016, at 13:21, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:

Hi all,

While working on some unrelated refactoring, I stumbled across a minor fix that would make use properly enforce “.self” when we want to get the metatype of a named type. For example, the Swift compiler currently (incorrectly) allows

  sizeof(UInt)

which should be

  sizeof(UInt.self)

The fix for this is actually pretty simple (patch attached), but the question is… do we want to fix the problem, if we think that we’ll get SE-0090 that makes “.self” go away?

  https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md

On the one hand, I want to fix the problem:

  * This came out of a desire to make the AST more sane. Essentially, the folding of expressions into TypeExprs—which will go away entirely if/when SE-0090 is implemented—is pulling in the parentheses describing call arguments. Without the fix, we still have weird AST.
  * SE-0090 is labeled as “deferred out of Swift 3”, so having the compiler not implement the stated language for an entire release cycle seems really unfortunate.

OTOH, I don’t want to jerk people’s code around, forcing them to add “.self” now only to remove it a year from now (or whenever).

Thoughts?

  - Doug

<enforce-metatype-self.patch>_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Erica Sadun) #3

1. You just caused me a bunch of extra work. (*shakes fist*)
2. Consistency and correctness are more important than concision.
3. If it can be fixed, fix it. (It is a bug.) And THEN change the language using the normal SE evolution process.
4. I'd like you to settle this as quickly as possible.

-- E, not happy that she's answering this way because see point 1

···

On Jun 2, 2016, at 2:21 PM, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:

Hi all,

While working on some unrelated refactoring, I stumbled across a minor fix that would make use properly enforce “.self” when we want to get the metatype of a named type. For example, the Swift compiler currently (incorrectly) allows

  sizeof(UInt)

which should be

  sizeof(UInt.self)

The fix for this is actually pretty simple (patch attached), but the question is… do we want to fix the problem, if we think that we’ll get SE-0090 that makes “.self” go away?

  https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md

On the one hand, I want to fix the problem:

  * This came out of a desire to make the AST more sane. Essentially, the folding of expressions into TypeExprs—which will go away entirely if/when SE-0090 is implemented—is pulling in the parentheses describing call arguments. Without the fix, we still have weird AST.
  * SE-0090 is labeled as “deferred out of Swift 3”, so having the compiler not implement the stated language for an entire release cycle seems really unfortunate.

OTOH, I don’t want to jerk people’s code around, forcing them to add “.self” now only to remove it a year from now (or whenever).

Thoughts?


(Daniel Dunbar) #4

As just a user of the language, as much as I hate churn I personally wouldn't mind seeing this fixed. In this case, I think the laxness can make it harder for developers to form the right mental model of the language; I know I have personally stumbled over this in the past.

- Daniel

···

On Jun 2, 2016, at 2:00 PM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

We have a bug for this, https://bugs.swift.org/browse/SR-899. I had pretty much the same reaction you did, which is that it's definitely a bug but it's probably not worth changing right now.

Jordan

On Jun 2, 2016, at 13:21, Douglas Gregor via swift-dev <swift-dev@swift.org> wrote:

Hi all,

While working on some unrelated refactoring, I stumbled across a minor fix that would make use properly enforce “.self” when we want to get the metatype of a named type. For example, the Swift compiler currently (incorrectly) allows

  sizeof(UInt)

which should be

  sizeof(UInt.self)

The fix for this is actually pretty simple (patch attached), but the question is… do we want to fix the problem, if we think that we’ll get SE-0090 that makes “.self” go away?

  https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md

On the one hand, I want to fix the problem:

  * This came out of a desire to make the AST more sane. Essentially, the folding of expressions into TypeExprs—which will go away entirely if/when SE-0090 is implemented—is pulling in the parentheses describing call arguments. Without the fix, we still have weird AST.
  * SE-0090 is labeled as “deferred out of Swift 3”, so having the compiler not implement the stated language for an entire release cycle seems really unfortunate.

OTOH, I don’t want to jerk people’s code around, forcing them to add “.self” now only to remove it a year from now (or whenever).

Thoughts?

  - Doug

<enforce-metatype-self.patch>_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(David Sweeris) #5

I thought “Deferred out of Swift 3” meant that it was accepted, but there isn’t enough time to get it done. If so, and a bug lets it work anyway, why not undefer it, leave the bug in, and properly implement the change in 3.1? Assuming that the bug doesn’t affect anything else, of course... obviously that’d be bad.

- Dave Sweeris

···

On Jun 2, 2016, at 3:24 PM, Erica Sadun via swift-dev <swift-dev@swift.org> wrote:

3. If it can be fixed, fix it. (It is a bug.) And THEN change the language using the normal SE evolution process.


(Douglas Gregor) #6

No, “deferred” means we haven’t made a decision. The core team likes the direction of the proposal—we hope it succeeds—but there is nontrivial implementation work to do before it can be reconsidered and (hopefully) approved.

  - Doug

···

On Jun 2, 2016, at 1:38 PM, David Sweeris <davesweeris@mac.com> wrote:

On Jun 2, 2016, at 3:24 PM, Erica Sadun via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

3. If it can be fixed, fix it. (It is a bug.) And THEN change the language using the normal SE evolution process.

I thought “Deferred out of Swift 3” meant that it was accepted, but there isn’t enough time to get it done.


(Dmitri Gribenko) #7

Fully agreed. I would prefer this issue to be fixed. When I read
code affected by it, I'm always thinking "does this code really
compile? is this test accidentally disabled?"

Also, fixing this bug would make ".self" appear in more places, which
can affect the decision on the proposal to remove ".self". If people
don't see ".self" everywhere where it would eventually appear if the
proposal is rejected, their opinion on the proposal might be biased by
the code they saw in the wild.

Dmitri

···

On Thu, Jun 2, 2016 at 2:08 PM, Daniel Dunbar via swift-dev <swift-dev@swift.org> wrote:

As just a user of the language, as much as I hate churn I personally wouldn't mind seeing this fixed. In this case, I think the laxness can make it harder for developers to form the right mental model of the language; I know I have personally stumbled over this in the past.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/