[Review] SE-0090: Remove .self and freely allow type references in expressions

Evolution Announcements
1

Hello Swift community,

The review of "SE-0090: Remove .self and freely allow type references in expressions" begins now and runs through May 23. The proposal is available here:

  swift-evolution/0090-remove-dot-self.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

2

        * What is your evaluation of the proposal?

I suspect few would argue against the premise, namely that .self should go.
One quibble with the details, though:

  useType([Int])         // Passes Array<Int>
  useArray([Int])         // Passes an array, containing Int

This seems a little magical; by contrast, [Int.self] vs. [Int].self is
unambiguous. Moreover (not that I can conceive of a use for it), wouldn't
things get hairy if one tries to express `[[Int].self]`? I'd like to
propose an alternative:

Python has a trailing comma rule for tuples. That is, to distinguish a
parenthesized expression from a single-item tuple, the latter must be
written as `(item,)`. Perhaps the same idea could be used in this case.
That is:

[Int] // Array<Int>
[Int,] // an array, containing one element Int

        * Is the problem being addressed significant enough to warrant a

···

On Tue, May 17, 2016 at 8:33 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

1 Like
3

Could we reconsider rejecting the uppercase and lowercase conventions as a
syntactic requirement? While I still disagree with enum cases not being
UpperCamelCase, that decision narrows the 'approved' enough that the
syntactic requirement would line up with guidance. It would also make
teaching the conventions much easier. New students who, for whatever
reason, prefer naming variables with upper camel case would have immediate
and concrete feedback from the dev tools that that is non-idiomatic.

If that is a non starter, let me try another. Was a disambiguating token
preceding the type reference considered?

···

On Tue, May 17, 2016 at 11:33 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0090: Remove .self and freely allow type references in
expressions" begins now and runs through May 23. The proposal is available
here:

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

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

4

  * What is your evaluation of the proposal?

I am in favor, except that I think we should keep `.self` in the language.

In my years programming, I have on a few occasions found it *very* useful to have an identity method/property automatically available on all instances. For instance, one of my Ruby projects has a model with `last_week`, `last_month`, `last_year`, etc. class methods on it returning subsets of the available models, and I had a screen with a panel summarizing the number of instances in each of these ranges. When I wanted to add an "all time" count, I upgraded to Ruby 2.2 and used its new `itself` method.

To make this actually useful, .self would have to behave like a normal property in all respects—for instance, it would need to have a read-only lens once we support lenses. I don't think this is a tall order, but it *is* something that would need to be done.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. It's a pain to write code that talks about types.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. We don't normally tolerate "load-bearing duct tape" in the syntax like this.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Ruby has first-class, no-muss, no-fuss class objects like this and it's really nice.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading, plus I followed some of the earlier discussions.

···

--
Brent Royal-Gordon
Architechies

5

+1 to this. Never been a fan of that, and it seems more like a workaround then syntactical clarity.

···

On May 17, 2016, at 8:33 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0090: Remove .self and freely allow type references in expressions" begins now and runs through May 23. The proposal is available here:

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

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

6

   * What is your evaluation of the proposal?

+1. IIRC this wasn't always required and I was bummed when the requirement was introduced. Good riddance. That said, I wouldn't mind if .self was kept as an alternative as Brent has requested.

   * Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

   * Does this proposal fit well with the feel and direction of Swift?

Yes.

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Similar response as Brent with regards to Ruby.

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed the discussion and read the proposal.

···

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

7

+1. A lot of (mostly functional) languages that need to disambiguate type constructors from terms enforce this as a requirement to great effect.

~Robert Widmann

2016/05/17 21:56、T.J. Usiyan via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

Could we reconsider rejecting the uppercase and lowercase conventions as a syntactic requirement? While I still disagree with enum cases not being UpperCamelCase, that decision narrows the 'approved' enough that the syntactic requirement would line up with guidance. It would also make teaching the conventions much easier. New students who, for whatever reason, prefer naming variables with upper camel case would have immediate and concrete feedback from the dev tools that that is non-idiomatic.

If that is a non starter, let me try another. Was a disambiguating token preceding the type reference considered?

On Tue, May 17, 2016 at 11:33 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,

The review of "SE-0090: Remove .self and freely allow type references in expressions" begins now and runs through May 23. The proposal is available here:

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

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

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

8

I thought about this, but { $0 } is already a fairly compact way to express the identity function.

-Joe

···

On May 18, 2016, at 3:43 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

I am in favor, except that I think we should keep `.self` in the language.

In my years programming, I have on a few occasions found it *very* useful to have an identity method/property automatically available on all instances. For instance, one of my Ruby projects has a model with `last_week`, `last_month`, `last_year`, etc. class methods on it returning subsets of the available models, and I had a screen with a panel summarizing the number of instances in each of these ranges. When I wanted to add an "all time" count, I upgraded to Ruby 2.2 and used its new `itself` method.

To make this actually useful, .self would have to behave like a normal property in all respects—for instance, it would need to have a read-only lens once we support lenses. I don't think this is a tall order, but it *is* something that would need to be done.

9

Could we reconsider rejecting the uppercase and lowercase conventions as a syntactic requirement? While I still disagree with enum cases not being UpperCamelCase, that decision narrows the 'approved' enough that the syntactic requirement would line up with guidance. It would also make teaching the conventions much easier. New students who, for whatever reason, prefer naming variables with upper camel case would have immediate and concrete feedback from the dev tools that that is non-idiomatic.

Enforcing this at the language level would require us to decide how to handle importing APIs that don't follow the rules. We've put effort into modifying many of the Core Foundation APIs, but not all of them, and there's of course still POSIX and the standard C library. (We'd also need a rule for non-Western scripts that don't distinguish case.)

If that is a non starter, let me try another. Was a disambiguating token preceding the type reference considered?

We expressly wanted to avoid anything like C++'s `typename` and `template` disambiguation hacks.

-Joe

···

On May 17, 2016, at 8:56 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, May 17, 2016 at 11:33 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,

The review of "SE-0090: Remove .self and freely allow type references in expressions" begins now and runs through May 23. The proposal is available here:

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

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

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

1 Like
10

I thought about this, but { $0 } is already a fairly compact way to express the identity function.

It is, but I worry a bit about the core team's tendency to say "Oh, just use a closure" whenever something like this comes up. A function/method/property name can be merely *read*; a closure must be *interpreted*. And writing closures is error-prone—a slip of the keys and you've written `{ 0 }` or `{ 40 }` instead of `{ $0 }`, which look similar and (soon will) work in the same expressions but behave completely differently.

Naming operations is powerful; it helps you understand them better and it helps you avoid fat-fingering them.

···

--
Brent Royal-Gordon
Architechies

11

Could we reconsider rejecting the uppercase and lowercase conventions as a syntactic requirement? While I still disagree with enum cases not being UpperCamelCase, that decision narrows the 'approved' enough that the syntactic requirement would line up with guidance. It would also make teaching the conventions much easier. New students who, for whatever reason, prefer naming variables with upper camel case would have immediate and concrete feedback from the dev tools that that is non-idiomatic.

Enforcing this at the language level would require us to decide how to handle importing APIs that don't follow the rules. We've put effort into modifying many of the Core Foundation APIs, but not all of them, and there's of course still POSIX and the standard C library. (We'd also need a rule for non-Western scripts that don't distinguish case.)

If that is a non starter, let me try another. Was a disambiguating token preceding the type reference considered?

We expressly wanted to avoid anything like C++'s `typename` and `template` disambiguation hacks.

Thank you for this! Those are absolutely horrible.

···

On May 18, 2016, at 11:40 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On May 17, 2016, at 8:56 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-Joe

On Tue, May 17, 2016 at 11:33 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,

The review of "SE-0090: Remove .self and freely allow type references in expressions" begins now and runs through May 23. The proposal is available here:

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

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

       https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

       * What is your evaluation of the proposal?
       * Is the problem being addressed significant enough to warrant a change to Swift?
       * Does this proposal fit well with the feel and direction of Swift?
       * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
       * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

       https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

12

I thought about this, but { $0 } is already a fairly compact way to express the identity function.

It is, but I worry a bit about the core team's tendency to say "Oh, just use a closure" whenever something like this comes up. A function/method/property name can be merely *read*; a closure must be *interpreted*. And writing closures is error-prone—a slip of the keys and you've written `{ 0 }` or `{ 40 }` instead of `{ $0 }`, which look similar and (soon will) work in the same expressions but behave completely differently.

It seems to me that you could just as easily fat-finger `self` when you meant `.self`. The type system is likely to catch both `{ 0 }` and `self` mistakes.

-Joe

···

On May 18, 2016, at 11:33 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

Naming operations is powerful; it helps you understand them better and it helps you avoid fat-fingering them.

--
Brent Royal-Gordon
Architechies

13

I thought about this, but { $0 } is already a fairly compact way to express the identity function.

It is, but I worry a bit about the core team's tendency to say "Oh, just use a closure" whenever something like this comes up. A function/method/property name can be merely *read*; a closure must be *interpreted*. And writing closures is error-prone—a slip of the keys and you've written `{ 0 }` or `{ 40 }` instead of `{ $0 }`, which look similar and (soon will) work in the same expressions but behave completely differently.

Naming operations is powerful; it helps you understand them better and it helps you avoid fat-fingering them.

+1

···

On May 18, 2016, at 1:33 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

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

14

I thought about this, but { $0 } is already a fairly compact way to express the identity function.

It is, but I worry a bit about the core team's tendency to say "Oh, just use a closure" whenever something like this comes up. A function/method/property name can be merely *read*; a closure must be *interpreted*. And writing closures is error-prone—a slip of the keys and you've written `{ 0 }` or `{ 40 }` instead of `{ $0 }`, which look similar and (soon will) work in the same expressions but behave completely differently.

It seems to me that you could just as easily fat-finger `self` when you meant `.self`.

If I write `list.map { 0 }` instead of `list.map { $0 }`, that's perfectly valid code. If I write `list.map(self)` instead of `list.map(.self)`,

The type system is likely to catch both `{ 0 }` and `self` mistakes.

The type system will immediately (absent some odd overloading) catch `self` instead of `.self` because you're using an instance where a function is expected. But `{ 0 }` is a function `T -> Int` where `T -> T` is expected—a much more subtle difference, particularly since a closure's return value is often generic and used to determine the return value of the function it's passed to. So it's pretty likely that `{ 0 }` will satisfy the requirements of the immediate context; if type-checking is going to fail, it'll be because some later use of the result expects a `T` instead of an `Int`. So the type-checking failure will come in a future expression or statement, if indeed it ever does come at all.

···

On May 18, 2016, at 12:51 PM, Joe Groff <jgroff@apple.com> wrote:

--
Brent Royal-Gordon
Architechies

15

Apologies for resurrecting this ancient thread, but why wasn't this implemented?

To me, the .self is one of the strangest quirks in Swift, otherwise a very elegant language. The problem of disambiguation (e.g. is [Int] a type or array?) can be solved by assuming a type first, which is a much more likely real-world use case, unless the context dictates otherwise.

3 Likes
16

According to the returned for revision thread, this was not rejected, but it must go through a new proposal process before being actually accepted and implemented.

5 Likes
17

The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions. ;-)

8 Likes
18

Let's redefine "reasonable" — Swift Compiler :slight_smile:

But seriously, what should be done to resurrect this proposal?

19

It would be need to be implemented and re-proposed.

Personally I don't see an issue with it, it's explicit and clear about what you want when using types, which is a goal of Swift. Ambiguous code is what we should be trying to move away from

2 Likes
20

I'm not sure about this. You don't say: numbers should be written as 0.number to be explicit about what it is. You know it's a type when you look at Int or MyView, so to me there's no need to be any more explicit, especially that it's not uncommon in programming languages (to have a type name as a reference to itself in expressions).

It's true that the Swift array type brings a bit of irregularity into this, but if we accept [Int]() as normal, so should be accepted [Int] as a type reference I think.

2 Likes