Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

For those who are interested, this is the latest version of the proposal: https://gist.github.com/DevAndArtist/1332e1458e0791f8f4b1649cbeb4fce5 Casting as written in this proposal works in theory, but I had some problems implementing it, so it does work with protocols conformance We also have

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I’m responding anything that is related to your last version directly on gist rather than here, because it’s me not understanding a few things of that version. That’s why our main version tackles the whole calculation inside Type rather than splitting it into the Mirror type. I’m totally fine

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

It looks like Github does not send notifications. Just in case, I’ve responded here . By the way, I very much like how you recommend to use someType.metatype.staticMethod() and avoid any other usage of metatypes. ​

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I tried to better describe my alternative solution here . The problem with Mirror is that it can only carry a metatype around and thats it. You may be able to extract it from there and than what? You’ll cast it the old fashion way.

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

The problem with Mirror is that it can only carry a metatype around and thats it. You may be able to extract it from there and than what? You’ll cast it the old fashion way. As I may recall I asked the community in the following thread about Hashable ability, which isn’t implementable without

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I will now talk about general design, not specific methods or implementation details. This touches SE-0101. The following are niches for metatype-like types: 1. Explicit specialization of functions and expressing specific static types 2. Dynamic dispatch of static methods 3. Passing

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

One more thing to consider. If we had no Type struct/class there would be no way to get the size of a dynamic metatype after SE–0101 and SE–0096. func dynamicType(_ instance: T) -> Metatype MemoryLayout.size We can not check the size of T because then we might end up with the wrong size if

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

H, currently I’m inserting some changes and tweaks into your last gist update. Metatypes are still in the language; it turned out that they must remain in the language Type wraps around metatypes and will provide better maintenance if ever needed, because metatype instantiation will be

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I took some time to overview the whole idea in general, and I must say (surprisingly) that I don't support it myself. * Metatypes are still in the language; it turned out that they *must* remain in the language * The new primary `Type` struct duplicates semantics and interface of metatypes * But

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Okay but do we need public initializer at all? I think it’s more elegant than factory methods. Plus: I see what you meant - COW optimized type like Foundation types. Yes, it will be an implementation detail like in Foundation types. But here we need it for singleton pattern, not for COW. I’d

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I haven’t noticed the difference between those to at first glance. Okay but do we need public initializer at all? I’d put this into the alternative section so the core team can decide how to implement it (if this gets accepted). I’ll prepare a second implementation gist for this suggestion.

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

To summarize a few things that this proposal should change: Make public .self construct Type via Type.sharedInstance Let SE–0090 do the rest for public .self drop Rename type for metatypes T.Type to Metatype (or at least to T.Metatype) Rename internal .self to .metatype which will return an

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Some corrections on my previous post: 1. class var sharedInstance won’t work because of dynamically created types - We’ll still need a global set. Otherwise, the idea remains the same - The global set will be of type Set<_Type> 2. Advantages of nested _Type: - Type can

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Changed the implementation to this: public var size: Int { return _sizeof(self._metatype) } public var stride: Int { return _strideof(self._metatype) } public var alignment: Int { return _alignof(self._metatype) } public static var size: Int { return _sizeof(T.metatype) } public static var

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Implementation gist updated to reflect everything: https://gist.github.com/DevAndArtist/a5744f21107812b2d4e6baee2c55e0bf I’ll look into size etc. issue now. We should tackle this proposal asap because we’re almost out of time for Swift 3. The public api will look like this: public final

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Consider what I said above, I feel like we should tackle this: - drop init(_ copy: Type) - to keep equality of Type references Agreed. - make all initializer internal and as exchange make sharedInstance public. This would ensure that you will always get a reference from the type

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Done. Personally I don’t care much if it’s .cast(from:) or .cast(_:). Now whenever Type is created and if there is no reference in type storage (which I updated to be a Set instead of a Dictionary) that contains the dynamic metatype from our current instance, it automatically downcasts itself

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

You’ve got two things wrong there: 1. Derived: Base otherwise you cannot cast at all. 2. w === x //=> FALSE The reason why this does not work is because it’s impossible to cast a type to an different type with the help of an initializer. As I cleaned up the current implementation I though

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Think of metatypes as standalone types, which they actually are. To get a metatype in Swift 2.2 we use this TypeName.self which return an instance of TypeName.Type. Crystal clear right? Int.self -> Int.Type UIView.self -> UIView.Type But there is one type which is bugged: Any Any.self -(is

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

You’ve got two things wrong there: Derived: Base otherwise you cannot cast at all. w === x //=> FALSE The reason why this does not work is because it’s impossible to cast a type to an different type with the help of an initializer. As I cleaned up the current implementation I though about

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-15 17:21 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > >- > >If it’s possible to drop T.Metatype, sure why not to make it >Metatype, but I have no idea hod the core team will build this. We >should consider typealias Metatype = T.Metatype as

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Regards LM (From mobile) > On Jul 13, 2016, at 2:02 PM, Adrian Zubarev via swift-evolution > wrote: > > This isn’t a full proposal (yet). We still can change things. I didn’t > consider everything and can’t to that on my own. Feedback is welcome. > > To answer

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

If it’s possible to drop T.Metatype, sure why not to make it Metatype, but I have no idea hod the core team will build this. We should consider typealias Metatype = T.Metatype as an alternative implementation, but tackle for Metatype. Can you provide a full example? let type = Type(casting:

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

OK, then, I guess, Swift can create type metainfo at runtime, and it must work for Type, as well. I'd appreciate this feature. Next, I don't really like the following: - I’d rename T.Type to T.Metatype and produce typealias Metatype = T.Metatype - Furthermore T.Metatype would be

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I’m glad Brent could reach out to you what I tried so hard. :) I’ve been working on non-string VFL (Visual Format Language) for iOS Autolayout constraints. Formula.Horizontal << |-view.size(==20)-(constant: 0, option: .Center)-otherView-| << [.AlignAllTop, .AlignAllBottom] Something like this

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

As I stated my current position in some of my last posts: Originally I wanted to disallow T.Type in declarations - BUT I CHANGED MY MIND :) We should keep metatypes :) To get an instance of a metatype I’d prefer this usage Type.metatype or Type().metatype or: let type = Int // Type

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Challenge accepted: Fixing your code to make it compile. typealias SomeGeneric = (T, Int) func wrap(_ value: T) -> SomeGeneric { return (value, 42) } func recursivelyPrint(_ value: T, depth: Int) { print(value) guard depth > 0 else { return } recursivelyPrint(wrap(value), depth:

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Good morning everyone. Welcome to our discussion Brent. There is nothing bad about Type being a final class. To be honest I played with the idea of Type being a class for optimization purposes, because it does feel like a performance drop if we had to instantiate tons of the same types (which

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-15 9:25 GMT+03:00 Brent Royal-Gordon : > > On Jul 14, 2016, at 6:33 PM, Anton Zhilin > wrote: > > > > And such a feature would look odd on a struct. > > But why would it be a struct? Types are obvious candidates to have > identities; the

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

> On Jul 14, 2016, at 6:33 PM, Anton Zhilin wrote: > > And such a feature would look odd on a struct. But why would it be a struct? Types are obvious candidates to have identities; the type is the same "thing" everywhere it's referred to. Types don't have value

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-15 3:52 GMT+03:00 Brent Royal-Gordon : > > On Jul 14, 2016, at 5:24 PM, Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Ok, I forgot about it. Type should have all features of T.Type, > except that Type will not contain static methods

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

> On Jul 14, 2016, at 5:24 PM, Anton Zhilin via swift-evolution > wrote: > > Ok, I forgot about it. Type should have all features of T.Type, except > that Type will not contain static methods of T. Why? It seems to me like the most natural way to design this by far

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-15 0:02 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > I still can’t get my head around this. > > Originally I wanted to seal T.Type completely but I realized that there > are to many downsides, therefore I think it’s better to revise the way how > we

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I must correct the dynamicType implementation. It’s true that the function will produce Type but we still need to extract the dynamic metatype from the value, store it in _underlyingMetatype and recalculate _uniqueIdentifier. public func `dynamicType`(_ instance: T) -> Metatype { let

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Here is the formatted gist of the possible impementation: https://gist.github.com/DevAndArtist/a5744f21107812b2d4e6baee2c55e0bf --  Adrian Zubarev Sent with Airmail Am 14. Juli 2016 um 23:02:52, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: I still can’t get my head around this.

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I still can’t get my head around this. Originally I wanted to seal T.Type completely but I realized that there are to many downsides, therefore I think it’s better to revise the way how we construct a metatype in Swift + how to solve the ambiguity in array/dictionary shorthand syntax + open

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I still didn't answer the original question: >> Values of Type store identifiers of U such that U: T. >Why would we want to store more than one unique identifier? We don't. What I meant is the following. Type can have multiple non-equal values. Each of them contains a single identifier of some

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I didn't send the link to evolution, so here it is: https://gist.github.com/Anton3/08a069a3b6f634bece7ad666922741d2 Response inline: 2016-07-14 20:52 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > > >- > >There is a small typo (SE–0090 is not accepted yet) -

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Okay I carefully read the gist and here is my feedback: First of all thank you for combining your thoughts with mine. There is a small typo (SE–0090 is not accepted yet) - only in the first example: func unsafeBitCast(_: T, to: U.Type) unsafeBitCast(10, to: Double) // The second

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I’m still not fully convinced about fully removing the access to the metatype. If you look at Ericas and Daves current proposal for MemoryLayout it would completely break and it would become impossible to build something like this. And yes I borrowed the idea of putting properties like size

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

An even better explanation of my suggestion: instead of *sealing* T.Type, I suggest to *rename* it to Type, formally turning it into a struct, and then add size and align properties to it. And regardless of how you interpret it, I suggest to remove .Type notation. > In Swift, only class instances

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Okay I get it now. You meant the size for a metatype sizeof(T.Type.self). This is indeed 8 bytes, at least not for optimized Bool (as you showed). Internally, Type contains an Int, i.e. identifier of a type. For every type, compiler must choose a different identifier We can already implement

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 20:19 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > > Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@gmail.com) > schrieb: > > I see model of Type as follows: > >1. Values of Type are identifiers of types (8 bytes, I guess) >2. All used

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@gmail.com) schrieb: I see model of Type as follows: Values of Type are identifiers of types (8 bytes, I guess) All used identifiers are contained in Type Type contains a subset of those identifiers I can’t follow your though here. Is this

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I see model of Type as follows: 1. Values of Type are identifiers of types (8 bytes, I guess) 2. All used identifiers are contained in Type 3. Type contains a subset of those identifiers 4. Type are usually created with default constructor Type() 5. Upcasting uses constructor

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Okay I’m convinced on that one, but do we really want to give up being able to construct an instance from an metatype instance? (Personally I’d keep it as an optional feature.) There are more than 7000 search results inside swift repository for .Type. I looked up a few of them and I found an

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 15:02 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > > To answer your question, we still need the metatype to access initializer > and static member of that type. If we’d drop T.Type completely, we’d lose > functionality to do so. > > protocol A { >

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

This isn’t a full proposal (yet). We still can change things. I didn’t consider everything and can’t to that on my own. Feedback is welcome. To answer your question, we still need the metatype to access initializer and static member of that type. If we’d drop T.Type completely, we’d lose

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Why can't we drop metatypes T.Type with your proposal? Do they bring some extra capabilities over Type struct? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Here is a part of a draft I put together in case we should go for a review on this. Here is the formatted version if you cannot read it here: https://gist.github.com/DevAndArtist/a8d11011a376d47d0afc941017e64c75 Proposed solution I propose to seal T.Type into a standalone type Type and

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Just to be crystal clear, here is my vision. Currently Swift is heading in this direction: SomeType.staticMember == metatypeInstance.staticMember == SomeType.self.staticMember SomeType.init == metatypeInstance.init == SomeType.self.init SomeType.self -> SomeType.Type (metatype) SomeType ->

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

It looks like this is touching on a small subset of the not-yet-designed reflection API (still tabled for 4.0?). I am interested to see what balance it strikes between declarations (eg. being able to reflect extensions declarations), types (eg reflecting type conformance), and operations

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Hello Chris, my main concern for this change is the lack of extensibility of metatypes. We can access the metatype through the .self postfix, which potentially will be removed in the future (only the postfix). Through an instance of such a metatype we can then access the static members and all

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

> On Jul 8, 2016, at 1:06 PM, Adrian Zubarev via swift-evolution > wrote: > > Hello Swift community, before Swift 3 drops I’d like to discuss if it is > reasonable to consider to create a standalone type to drop/seal the T.Type > magic? > Hi Adrian, What’s the

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Currently I could implement the whole type like this: public struct Type : Hashable, CustomStringConvertible, CustomDebugStringConvertible { // Anyone knows a better name? public let sealed: T.Type = T.self public let hashValue: Int = ObjectIdentifier(T.self).hashValue

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Correcting the function from the very first post: public func ==(lhs: Type, rhs: Type) -> Bool { return lhs.hashValue == rhs.hashValue } --  Adrian Zubarev Sent with Airmail Am 9. Juli 2016 um 11:55:00, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: Here are a few

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Here are a few more thoughts on solving a few problems with dropped .self in mind: Type cannot become Type to prevent infinite recursion. Any other type without the short form for initializer SomeType(...) or explicit access to static members or initializer like SomeType.init(...) or

[swift-evolution] [Discussion] Seal `T.Type` into `Type`

Hello Swift community, before Swift 3 drops I’d like to discuss if it is reasonable to consider to create a standalone type to drop/seal the T.Type magic? However this change does not play well with the proposal of dropping the .self compiler magic. Some bikeshedding: public struct Type :