Re: [swift-evolution] [Review] SE-0124: `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

> > * What is your evaluation of the proposal? > +1 > * Is the problem being addressed significant enough to warrant a > change to Swift? > Yes, minor but important. > * Does this proposal fit well with the feel and direction of Swift? > Yes, it's consistent with

[swift-evolution] [Review] SE-0124: `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

Hello Swift community, The review of "SE-0124: `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label" begins now and runs through July 20. The proposal is available here:

[swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Hello Swift community, The second review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 22. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md Reviews

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

> > Isn't half of this done, or something? I seem to remember seeing code > about it, and I think there may even be a hidden switch to enable what is > there. The parsing code seems to be in place, toggled by the flag Context.LangOpts. EnableProtocolTypealiases:

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

https://github.com/apple/swift-evolution/tree/master/proposals/0092-typealiases-in-protocols.md Isn't half of this done, or something? I seem to remember seeing code about it, and I think there may even be a hidden switch to enable what is there. Sent from my new Email

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

Realistically, there are still going to be large changes to Swift. I expect conditional conformances, for example, to basically transform huge amounts of Swift code, including the standard library. Karl > > On Jul 15, 2016 at 7:53 PM,

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

How about Polar(r: 0, phi: 0) ? It should all equal with any angles if r == 0. 2016-07-16 0:41 GMT+08:00 Johannes Neubauer via swift-evolution < swift-evolution@swift.org>: > > > Am 15.07.2016 um 18:29 schrieb Saagar Jha : > > > > Here's a value type that uses custom

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

on Fri Jul 15 2016, Dmitri Gribenko wrote: > On Fri, Jul 15, 2016 at 11:44 AM, Ted kremenek via swift-dev > wrote: >> Good question. >> >> Dave/Dmitri: do you have a recommendation here? I can see either the JIRA >> issues referencing the

Re: [swift-evolution] [Pitch] `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

on Fri Jul 15 2016, Arnold Schwaighofer wrote: > This is probably uncontroversial. > > PR: https://github.com/apple/swift-evolution/pull/434 +1 >> On Jul 13, 2016, at 4:39 PM, Arnold Schwaighofer via swift-evolution >> wrote: >> >>

Re: [swift-evolution] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

on Thu Jul 14 2016, Tino Heth wrote: > I share the minor concerns that have been expressed so far. > My first thought on this topic ("MyStruct.size") had a obvious flaw, but I > wouldn't fear name collisions with something like > "MyStruct.memoryLayout.size". > This

Re: [swift-evolution] Visibility into timeline for proposals left in "Awaiting Review" for a while?

In the "schedule" document, this proposal is listed under the section entitled "Merged proposals that are out of scope for Swift 3.0, but will be scheduled when it is done". https://github.com/apple/swift-evolution/blob/master/schedule.md

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

2016/07/15 16:37、Riley Testut via swift-evolution のメッセージ: > FWIW, I'm still against this proposal, but since it will be accepted > regardless, here are my thoughts: > > • Open keyword is significantly better. > • Members should be *open* by default, and final

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: Last chance to rename .self and .Self?

Thanks! I will take a look Brandon > On Jul 15, 2016, at 3:28 PM, Adrian Zubarev via swift-evolution > wrote: > > You might have a look at our discussion thread. There is a huge overlap on > your bikeshedding. > >

Re: [swift-evolution] [Pitch] `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

+1 Sent from my iPhone > On Jul 13, 2016, at 18:39, Arnold Schwaighofer via swift-evolution > wrote: > > Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a > 'bitPattern:’ label to make it clear at the use site that we interpret the > value

[swift-evolution] Visibility into timeline for proposals left in "Awaiting Review" for a while?

Hello, Back in April, a proposal PR of mine (SE-0079 ) was merged into master that

Re: [swift-evolution] Discussion: Last chance to rename .self and .Self?

You might have a look at our discussion thread. There is a huge overlap on your bikeshedding. https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20160711/024439.html --  Adrian Zubarev Sent with Airmail Am 15. Juli 2016 um 21:25:50, Brandon Knope via swift-evolution

[swift-evolution] Discussion: Last chance to rename .self and .Self?

July 27th is last day for breaking source changes for Swift 3...so I thought I would bring this up one final time. Opinions: - .self and .Self do not adequately convey what they do without some mental gymnastics - self has somewhat two meanings (accessing a property on the type and getting

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] [Proposal] Variadics as Attribute

The last post in this thread is nearly a week ago... did you already apply for review? It would be a pity if this topic isn't finished, and I think a reduced variant that merely replaces "values: Int…" with "@variadic _ values: [Int]" shouldn't be a problem for Swift 3, leaving the possibility

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] Fixing the confusion between non-mutating algorithms and single-pass sequences

on Thu Jul 14 2016, Jonathan Hull wrote: > I have also been thinking about this problem for the last week or so > (as well as the finite/infinite bit). I don’t really have anything > detailed that is ready to share (and it sounds like you are headed in > a different direction now). I still

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

On Fri, Jul 15, 2016 at 11:44 AM, Ted kremenek via swift-dev wrote: > Good question. > > Dave/Dmitri: do you have a recommendation here? I can see either the JIRA > issues referencing the proposal (if one exists) or updating the gist. I > prefer the former. Updating the

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

On Jul 15, 2016, at 9:36 AM, L. Mihalkovic wrote: >>> >>> Or because the framework was developed in the real world, rather than >>> Elysium, and real-world framework developers just about *never* anticipate >>> every single way someone might use their framework

Re: [swift-evolution] Endgame for Swift 3

Good question. Dave/Dmitri: do you have a recommendation here? I can see either the JIRA issues referencing the proposal (if one exists) or updating the gist. I prefer the former. > On Jul 15, 2016, at 11:18 AM, Will Field-Thompson wrote: > > Is there any way to tell

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 19:05 schrieb Saagar Jha : > > Equatable, where the == operator is defined, will not let you compare two > things of a different type. I know that. I mean, this is what I meant with „Swift does a hard job to enforce this“. > On Fri, Jul 15, 2016 at

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] Endgame for Swift 3

Is there any way to tell which of the changes in the gist have had proposals associated with them? -- Will On Fri, Jul 15, 2016 at 1:46 PM Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone, > > Swift 3 has shaped up to be a remarkable release — a product of the

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

[swift-evolution] Endgame for Swift 3

Hi everyone, Swift 3 has shaped up to be a remarkable release — a product of the inspiration, ideas, and hard labor many people from across the Swift open source community. It is now time, however, to talk about the endgame for the release. Here are the key points: The last day to take

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] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Equatable, where the == operator is defined, will not let you compare two things of a different type. On Fri, Jul 15, 2016 at 10:02 Johannes Neubauer wrote: > > > Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution < > swift-evolution@swift.org>: > > > > >

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution > : > > >> Am 15.07.2016 um 18:29 schrieb Saagar Jha : >> >> Here's a value type that uses custom equality (at least, I think so): >> String. Since it uses extended

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 18:29 schrieb Saagar Jha : > > Here's a value type that uses custom equality (at least, I think so): String. > Since it uses extended grapheme clusters, internally two Strings may be > composed of different Unicode scalars, but if they create the same

Re: [swift-evolution] [Pitch] `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

On Wed, Jul 13, 2016 at 4:39 PM, Arnold Schwaighofer via swift-evolution wrote: > Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a > 'bitPattern:’ label to make it clear at the use site that we interpret the > value as a bit pattern. +1!

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

Regards (From mobile) > On Jul 15, 2016, at 8:26 AM, Chris Lattner via swift-evolution > wrote: > > >>> On Jul 14, 2016, at 10:58 PM, Charles Srstka >>> wrote: >>> >>> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 18:12 schrieb Johannes Neubauer via swift-evolution > : > > >> Am 15.07.2016 um 15:19 schrieb Shawn Erickson : >> >> Additional two "things" maybe considered equal in the chosen problem domain >> despite their identity (memory

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Here's a value type that uses custom equality (at least, I think so): String. Since it uses extended grapheme clusters, internally two Strings may be composed of different Unicode scalars, but if they create the same Characters they are considered to be equal. On Fri, Jul 15, 2016 at 09:12

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] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

> Am 15.07.2016 um 15:19 schrieb Shawn Erickson : > > Additional two "things" maybe considered equal in the chosen problem domain > despite their identity (memory location, etc.) being different. Having the > ability to supply custom hash and equality for types can be a

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On Jul 14, 2016, at 11:27 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 14, 2016, at 2:39 PM, Chris Lattner wrote: >> >> asks the community for an in-depth discussion of the secondary points of the >> proposal: does it make

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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

I'll also stick with "open" for both class and methods and I believe they should be required for both too. Just as I may not design a class to be subclassable outside my library, I may not want to allow a method to be overriden outside the library either (but I may want to override it inside the

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] [Meta] Proposal status page

Cool! Looks great! -Thorsten > Am 14.07.2016 um 10:30 schrieb Jacob Bandes-Storch via swift-evolution > : > > I got sidetracked today and mocked up a proposal "status page": > > http://jtbandes.github.io/swift-evolution/ > > This moves the proposal status info

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] [Pitch] `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

+1. Agreed. Otherwise, it's kind of a cryptic initializer. > On Jul 15, 2016, at 3:54 PM, Arnold Schwaighofer via swift-evolution > wrote: > > This is probably uncontroversial. > > PR: https://github.com/apple/swift-evolution/pull/434 > > > >> On Jul 13, 2016, at

Re: [swift-evolution] [Pitch] `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

This is probably uncontroversial. PR: https://github.com/apple/swift-evolution/pull/434 > On Jul 13, 2016, at 4:39 PM, Arnold Schwaighofer via swift-evolution > wrote: > > Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a > 'bitPattern:’

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Additional two "things" maybe considered equal in the chosen problem domain despite their identity (memory location, etc.) being different. Having the ability to supply custom hash and equality for types can be a useful tool in a developers toolbox. For example two pathways of code may create what

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Hello Johannes, > Am 14.07.2016 um 22:36 schrieb Johannes Neubauer via swift-evolution > : > > 1. Custom implementation of equals operator `==` for value types should be > forbidden. Rationale: Why has it been added in the first place? For omitting > some values

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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution > wrote: > > To sum this all up, the core team is rejecting this proposal and requesting a > revision to change the concrete syntax to “public open class Foo” instead of > “subclassable class Foo".

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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> does it make sense to require every member to be marked as “overridable” in > order to be overridden by an open subclass outside of the current module? Despite of probably being one of the most passionate defenders against adding restrictions on subclassing, I've to accept the clear

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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

I have deliberately kept away from the discussion on this topic, as I didn’t feel like I can contribute in any meaningful way. In all honesty, I have barely used ‚traditional’ OOP paradigms in the last few years at all. While OOP is a useful tool and its great for modelling certain relationship

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

FWIW, I'm still against this proposal, but since it will be accepted regardless, here are my thoughts: • Open keyword is significantly better. • Members should be *open* by default, and final should be opt-in. If you're opening up a class for subclassing, my gut says you should allow the

Re: [swift-evolution] [Review] SE-0121: Remove `Optional` Comparison Operators

+1 from me. I recently had to fix a bug stemming from this which was easy to fix, but not easy to spot. These operators are quite special; they are plain yes/no assertions used to filter data at a particularly broad level of abstraction. It is usually super-important that you understand

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

> * What is your evaluation of the proposal? Given SE-0121 would get accepted, this proposal does only add small additional value, and might even make code unnecessary complicated. BUT the nil-coalescing operator (??) really should not allow a non-optional on its left hand side. > * Is the

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On Jul 14, 2016, at 2:39 PM, Chris Lattner wrote: > > asks the community for an in-depth discussion of the secondary points of the > proposal: does it make sense to require every member to be marked as > “overridable” in order to be overridden by an open subclass outside

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

> On Jul 14, 2016, at 10:58 PM, Charles Srstka wrote: > >> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution >> > wrote: >> >> - Second is that clients of some other public API vended by a

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] [Review] SE-0121: Remove `Optional` Comparison Operators

> * What is your evaluation of the proposal? Very welcome change that should reduce unexpected behavior in some cases. > * Is the problem being addressed significant enough to warrant a change to > Swift? Yes, as it could avoid programming mistakes. > * Does this proposal fit well with the