[Review] SE-0096: Converting dynamicType from a property to an operator

Evolution Announcements
1

Hello Swift community,

The review of "SE-0096: Converting dynamicType from a property to an operator" begins now and runs through May 30. The proposal is available here:

  swift-evolution/0096-dynamictype.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?

+1. As I said in a previous review, I like that we have decided on keyword naming conventions and are bringing existing keywords in line.

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

N/A

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

Quick glance and participation in the original discussion.

···

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

3

  * What is your evaluation of the proposal?

I think it's a good idea. While the type is in some sense a "property" of the instance, it has always been a bit strange to have it there:

* `dynamicType` acts sort of like an extension of `Any`, but you're not actually allowed to extend `Any`.
* Using property syntax forced the designers to avoid the most obvious name, `type`, because users might want that name for their own purposes.
* Similar "universal" properties, like getting the size of an instance or reflecting it, are exposed as free functions. A fair number of the standard library's free functions could reasonably be exposed as members of `Any` or `AnyObject`, yet `dynamicType` was singled out for this treatment.

I am not convinced, however, by this proposal's argument against renaming to `typeof(_:)`. In a very brief survey of languages with a `typeof` operation (or some extremely similar keyword, like `TypeOf` or `type-of`), I found:

LANGUAGES WITH ONLY STATIC TYPES

* C: Textual substitution (more or less) of static type. (C++ and Objective-C inherit this from C.)

LANGUAGES WITH ONLY DYNAMIC TYPES

* Javascript: Dynamic type (string)
* R: Dynamic type (string)
* ActionScript: Dynamic type (string)
* Common Lisp: Dynamic type

LANGUAGES WITH BOTH

* D: Textual substitution (more or less) of static type, like C
* Crystal: Static type
* C#: N/A; used only with type names, in a similar role to `self` in Swift 2's `SomeType.self`

* Go: Dynamic type
* Visual Basic: Dynamic type
* GNU Pascal: Dynamic type

My conclusion is that, for the most part, languages use `typeof` in one of two ways:

  1) It is part of their type grammar, where it represents a static type.

  2) It is part of their expression grammar, where it represents a dynamic type.

(In Crystal, `typeof` is part of both grammars, and always represents a static type. C# uses it in a weird, idiosyncratic way.)

If Swift were to support category 1, it would almost certainly be considered "compiler magic" and thus be spelled `#typeof`. So I don't think there's much ambiguity in what `typeof(_:)` would mean in Swift.

Given that using it to mean "dynamic type" is highly precedented in other languages, and given that it is much shorter than `dynamicType` and matches an existing pattern in the standard library, I believe we should use the name `typeof` instead of `dynamicType`.

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

Yes. Let's get rid of this compromised weirdness.

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

Yes. We've been clearing out these kinds of cobwebs a lot lately.

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

Most languages where I've used this kind of thing use `class` to return the dynamic type, but this isn't a sensible option in Swift, which has richly-typed instances which aren't classes.

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

I wouldn't quite call this review "in-depth", but I put maybe an hour of work into it.

···

--
Brent Royal-Gordon
Architechies

4

  * What is your evaluation of the proposal?

+1

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

Probably, although I don’t think it’s an essential change.

I do believe strongly that “dynamicType” is better than “typeof", for the reason explained in the proposal: It is unclear whether it’s the static or dynamic type.

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

ObjC, but I don’t think it compares well

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

Read the proposal and some of the previous discussion.

5

I don't understand why the proposal says we can't implement this in the
library today.

  $ swift
  Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
    1> func dynamicType_<T>(_ x: T) -> T.Type { return x.dynamicType }
    2> dynamicType_(42)
  $R0: Int.Type = Int
    3> class B {}
    4. class C : B {}
    5. dynamicType_(C() as B)
  $R1: B.Type = __lldb_expr_5.C
    6>

IMO exposing it as a special language feature is a mistake unless
there's something wrong with the implementation above. There are many
ways we can implement the body of the generic function and still remove
the .dynamicType property from the language's user model.

···

on Tue May 24 2016, Chris Lattner <clattner-AT-apple.com> wrote:

Hello Swift community,

The review of "SE-0096: Converting dynamicType from a property to an operator" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.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,

--
Dave

6

Isn't `dynamictype` different from `sizeof` or `typeof` in that it does evaluate it's argument?

I think it's safe to write `typeof(system("rm -rf *"))` *, because `typeof` will return the static type of the expression, without evaluating it. `sizeof(44*x)` will not perform a multiplication, but will only consider the type of `44*x`, which is known at compile time (at least we know (because we need to know) how much space is reserved on the stack for that variable.)

dynamictype(expr) would be the first such keyword that does evaluate it's expression. Maybe that's the reason why the original developer designed it to look like a method?

-Michael

*) all code snippets are supplied without any warranty of any kind. code may clean your hard drive ;)

···

Am 24.05.2016 um 20:17 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:

Hello Swift community,

The review of "SE-0096: Converting dynamicType from a property to an operator" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.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

7

Isn't `dynamictype` different from `sizeof` or `typeof` in that it does evaluate it's argument?

`sizeofValue(_:)` in Swift also evaluates its argument.

···

--
Brent Royal-Gordon
Architechies

8

I'm going to defer to Joe Groff to respond specifically to this. I believe the
issue was that the type signature could not be described in today's Swift
but would be possible in future Swift, as the current type system wouldn't
work for protocol metatypes.

-- E

···

On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I don't understand why the proposal says we can't implement this in the
library today.

$ swift
Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
   1> func dynamicType_<T>(_ x: T) -> T.Type { return x.dynamicType }
   2> dynamicType_(42)
$R0: Int.Type = Int
   3> class B {}
   4. class C : B {}
   5. dynamicType_(C() as B)
$R1: B.Type = __lldb_expr_5.C
   6>

IMO exposing it as a special language feature is a mistake unless
there's something wrong with the implementation above. There are many
ways we can implement the body of the generic function and still remove
the .dynamicType property from the language's user model.

9

I don't understand why the proposal says we can't implement this in the
library today.

$ swift
Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
  1> func dynamicType_<T>(_ x: T) -> T.Type { return x.dynamicType }
  2> dynamicType_(42)
$R0: Int.Type = Int
  3> class B {}
  4. class C : B {}
  5. dynamicType_(C() as B)
$R1: B.Type = __lldb_expr_5.C
  6>

Now try it with a protocol type, or Any:

(swift) var x: Any = 1738
// x : Any = 1738
(swift) dynamicType_(x)
// r0 : Any.Protocol = protocol<>

`dynamicType` is really two operations: For normal concrete types, it produces concrete metatypes, and for existentials, it produces existential metatypes. There's no way to express the latter for an arbitrary unknown protocol type in the language today.

-Joe

···

On May 25, 2016, at 11:42 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

IMO exposing it as a special language feature is a mistake unless
there's something wrong with the implementation above. There are many
ways we can implement the body of the generic function and still remove
the .dynamicType property from the language's user model.

I'm going to defer to Joe Groff to respond specifically to this. I believe the
issue was that the type signature could not be described in today's Swift
but would be possible in future Swift, as the current type system wouldn't
work for protocol metatypes.

-- E

10

Can't we detect in the runtime library that we've got an existential and
do the right thing?

···

on Wed May 25 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On May 25, 2016, at 11:42 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I don't understand why the proposal says we can't implement this in the

library today.

$ swift
Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
  1> func dynamicType_<T>(_ x: T) -> T.Type { return x.dynamicType }
  2> dynamicType_(42)
$R0: Int.Type = Int
  3> class B {}
  4. class C : B {}
  5. dynamicType_(C() as B)
$R1: B.Type = __lldb_expr_5.C
  6>

Now try it with a protocol type, or Any:

(swift) var x: Any = 1738
// x : Any = 1738
(swift) dynamicType_(x)
// r0 : Any.Protocol = protocol<>

`dynamicType` is really two operations: For normal concrete types, it
produces concrete metatypes, and for existentials, it produces
existential metatypes. There's no way to express the latter for an
arbitrary unknown protocol type in the language today.

--
Dave

11

Not within the constraints of the type system. P.Protocol and P.Type are different types, and the former isn't a model of the latter (since P has no methods of its own so can't satisfy P's static requirements).

-Joe

···

On May 25, 2016, at 12:28 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed May 25 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On May 25, 2016, at 11:42 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I don't understand why the proposal says we can't implement this in the

library today.

$ swift
Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> func dynamicType_<T>(_ x: T) -> T.Type { return x.dynamicType }
2> dynamicType_(42)
$R0: Int.Type = Int
3> class B {}
4. class C : B {}
5. dynamicType_(C() as B)
$R1: B.Type = __lldb_expr_5.C
6>

Now try it with a protocol type, or Any:

(swift) var x: Any = 1738
// x : Any = 1738
(swift) dynamicType_(x)
// r0 : Any.Protocol = protocol<>

`dynamicType` is really two operations: For normal concrete types, it
produces concrete metatypes, and for existentials, it produces
existential metatypes. There's no way to express the latter for an
arbitrary unknown protocol type in the language today.

Can't we detect in the runtime library that we've got an existential and
do the right thing?

12

I mean at runtime, in C++ code.

···

on Wed May 25 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On May 25, 2016, at 12:28 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed May 25 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On May 25, 2016, at 11:42 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I don't understand why the proposal says we can't implement this in the

library today.

$ swift
Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> func dynamicType_<T>(_ x: T) -> T.Type { return x.dynamicType }
2> dynamicType_(42)
$R0: Int.Type = Int
3> class B {}
4. class C : B {}
5. dynamicType_(C() as B)
$R1: B.Type = __lldb_expr_5.C
6>

Now try it with a protocol type, or Any:

(swift) var x: Any = 1738
// x : Any = 1738
(swift) dynamicType_(x)
// r0 : Any.Protocol = protocol<>

`dynamicType` is really two operations: For normal concrete types, it
produces concrete metatypes, and for existentials, it produces
existential metatypes. There's no way to express the latter for an
arbitrary unknown protocol type in the language today.

Can't we detect in the runtime library that we've got an existential and
do the right thing?

Not within the constraints of the type system. P.Protocol and P.Type
are different types, and the former isn't a model of the latter (since
P has no methods of its own so can't satisfy P's static requirements).

--
Dave

13

When you substitute 'T = P' into 'T.Type', which specifies a concrete metatype, you get 'P.Protocol'. We can't return P.Type without breaking the type of the function.

-Joe

···

On May 25, 2016, at 12:58 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed May 25 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On May 25, 2016, at 12:28 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed May 25 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On May 25, 2016, at 11:42 AM, Erica Sadun <erica@ericasadun.com> wrote:

On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I don't understand why the proposal says we can't implement this in the

library today.

$ swift
Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> func dynamicType_<T>(_ x: T) -> T.Type { return x.dynamicType }
2> dynamicType_(42)
$R0: Int.Type = Int
3> class B {}
4. class C : B {}
5. dynamicType_(C() as B)
$R1: B.Type = __lldb_expr_5.C
6>

Now try it with a protocol type, or Any:

(swift) var x: Any = 1738
// x : Any = 1738
(swift) dynamicType_(x)
// r0 : Any.Protocol = protocol<>

`dynamicType` is really two operations: For normal concrete types, it
produces concrete metatypes, and for existentials, it produces
existential metatypes. There's no way to express the latter for an
arbitrary unknown protocol type in the language today.

Can't we detect in the runtime library that we've got an existential and
do the right thing?

Not within the constraints of the type system. P.Protocol and P.Type
are different types, and the former isn't a model of the latter (since
P has no methods of its own so can't satisfy P's static requirements).

I mean at runtime, in C++ code.