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 pro

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 of the > current mod

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> - Second is that clients of some other public API vended by a non-Apple >> framework (e.g. a SwiftPM package) may end up

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 semantics; if you perform a muta

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 fee

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

> 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 non-Apple > framework (e.g. a SwiftPM package) may end up in a situation where the > framework author didn’t consider subclass-ability, but the client des

Re: [swift-evolution] executing a string

I could see a method being implemented that does something bad, but isn’t called directly anywhere in code. A code path analysis of a program may miss the problematic method (though unlikely?). But if the method signature is passed in dynamically as the result of a web call or something, it coul

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

> On Jul 14, 2016, at 11:39 PM, 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". This approach satisfies the

Re: [swift-evolution] executing a string

I've never heard of an app being exploited through selector abuse. Do you have any example of that? Félix > Le 14 juil. 2016 à 08:48:53, Ford Prefect via swift-evolution > a écrit : > > One of the major security flaws of Obj C is > the ability to convert a string into a selector, which > perm

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

When/if we get an async/await like feature, of course we’ll try to pull completion handlers automatically into the model. We can do that post swift 3. -Chris > On Jul 14, 2016, at 3:30 PM, Charles Srstka via swift-evolution > wrote: > > Right, but since this would affect the Obj-C importer a

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

On Jul 14, 2016, at 9:33 AM, Ben Rimmington wrote: >> >> This will restore the ability to express the idea of a closure parameter >> that carries labels as part of its declaration, without requiring parameter >> labels to be part of the type system (allowing, e.g. the operator + to be >> passe

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

> On Jul 14, 2016, at 9:27 AM, Erica Sadun wrote: > > >> On Jul 14, 2016, at 10:01 AM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On Jul 14, 2016, at 1:20 AM, Taras Zakharko wrote: >>> >>> Great! >>> >>> This cleanly separates between the type and the name/signature! Simple an

Re: [swift-evolution] executing a string

> On 14 Jul 2016, at 17:48, Ford Prefect via swift-evolution > wrote: > > One of the major security flaws of Obj C is > the ability to convert a string into a selector, which > permits using private methods by constructing selectors > at runtime long after the app store review has been complete

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 of T. > > Why? It seems

Re: [swift-evolution] [Meta] Proposal status page

Only talking about the page and its content, since I didn't review the code and how it works: I love it! I think it would be great to have this in the official repo. On Thu, Jul 14, 2016, at 11:46, Jacob Bandes-Storch via swift-evolution wrote: > It occurs to me that moving swift-evolution to u

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 is to have `Type` be the ty

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 construc

Re: [swift-evolution] executing a string

Here’s how selectors in Swift work, based on this proposal. Swift’s selectors are a lot safer than Objective-C’s. > > > > > One of

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

> On Jul 14, 2016, at 5:56 PM, David Waite wrote: > > >> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 14, 2016, at 4:39 PM, Chris Lattner >> > wrote: >>> >>> [The core team] asks the commu

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

Hi Austin, > Am 15.07.2016 um 00:35 schrieb Austin Zheng : > > Additive proposals are out of scope for Swift 3; you'll have better luck if > you come back around August and propose these one at a time. Ok. I didn’t know that proposals can be only for the next release. I will come back later ;)

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

This is great news! Thank you!! On Thursday, 14 July 2016, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > > Shortly after SE-0111 was accepted last week

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

The issue with bringing this up now is that much of the core team is distracted by the work of finalizing the Swift 3 implementation, and won’t be able to fully participate. I have a ton of questions about how opinionated the language will be with regards to concurrency approaches (I’m in the c

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

Is there a way I can make that clearer than putting it in a section labeled “FUTURE DIRECTIONS”? Charles > On Jul 14, 2016, at 5:52 PM, Dan Appel wrote: > > Yes, it should be made clear that the 'async'/'await' suggestions are future > directions, which are more to show how flexible the desig

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

> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution > wrote: > > >> On Jul 14, 2016, at 4:39 PM, Chris Lattner > > wrote: >> >> To sum this all up, the core team is … requesting a revision to change the >> concrete syntax to “public open class Foo” ins

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

IIRC, one of the main goals in Swift 3 was to further stabilize the language spec and *minimize* breakage in future versions, not eliminate potential breakage altogether. Considering the numerous directions Native Concurrency can take (Go-style green thread scheduling, async-await, continuation

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

Yes, it should be made clear that the 'async'/'await' suggestions are *future* *directions*, which are more to show how flexible the design is rather than actually be a part of the implementation. On Thu, Jul 14, 2016 at 3:30 PM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote

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

Additive proposals are out of scope for Swift 3; you'll have better luck if you come back around August and propose these one at a time. I don't see the need for "poor man's existentials" - existential improvements are out of scope for the next release, and there are already a bunch of designs flo

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

Right, but since this would affect the Obj-C importer and thus would be a source-breaking change, it would probably not be possible anymore after Swift 3. Charles > On Jul 14, 2016, at 4:57 PM, Dan Stenmark wrote: > > I’d say it’s a little premature to be talking about this; the team has made

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

Hi Daniel, I will answer backwards, since it is easier for me this way. > Am 14.07.2016 um 22:47 schrieb Daniel Resnick : > > Furthermore, why should properties pointing to reference types always use > `===`? What if the reference type conforms to `Equatable`? I proposed to use `===`, since a

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

> On Jul 14, 2016, at 4:39 PM, Chris Lattner wrote: > > To sum this all up, the core team is … requesting a revision to change the > concrete syntax to “public open class Foo” instead of “subclassable class > Foo”. Yes, +1 to “public open Foo” instead of “subclassable Foo”. Presumably “open”

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

I’d say it’s a little premature to be talking about this; the team has made it very clear that the discussion on Native Concurrency in Swift won’t begin for another couple months. Dan > On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution > wrote: > > I know it’s late, but I was

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

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md Hello Swift Community, The review of "SE-0117: Default classes to be non-subclassable publicly" ran from July 5…11, 2016. As expected, this proposal was extremely polarizin

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 d

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 the

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

Forbidding custom `==` for value types would break equality for all Swift collection types, since they use reference types behind the scenes for storing memory and copy on write semantics. Furthermore, why should properties pointing to reference types always use `===`? What if the reference type co

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

Dear Evolutionaries, First off, I like Swift! I have some proposals for swift 3ff. (since the `++` operator is discouraged ;) ): 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`

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 ty

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

It occurs to me that moving swift-evolution to use *only* a gh-pages branch, like swift-internals does, would allow this to work without JS. On Thu, Jul 14, 2016 at 1:30 AM, Jacob Bandes-Storch wrote: > I got sidetracked today and mocked up a proposal "status page": > > http://jtbandes.githu

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

Result is one way to do it, but I'm not a huge fan. I would personally prefer this kind of api. doSomethingAsync { getResult in do { let result = try getResult() } catch { // handle error } } Where the signature would go from func doSomethingAsync(callback: (T?, Error?) -> ()) to func doSometh

Re: [swift-evolution] [SE-0088] Dispatch API names

> On Jul 14, 2016, at 3:44 AM, Karl wrote: > > I just discovered this thread by accident - thank the Lord I’m not the only > one who feels like this about the new Dispatch API! > >> On 8 Jul 2016, at 04:16, Darren Mo via swift-evolution >> wrote: >> >> Should I create a bug report for chang

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

I know it’s late, but I was wondering what the community thought of this: MOTIVATION: With the acceptance of SE-0112, the error handling picture looks much stronger for Swift 3, but there is still one area of awkwardness remaining, in the area of returns from asynchronous methods. Specifically,

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 line shoul

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

> On 14 Jul 2016, at 05:47, Chris Lattner via swift-evolution > wrote: > > Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > >

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

> On Jul 14, 2016, at 10:01 AM, Chris Lattner via swift-evolution > wrote: > > >> On Jul 14, 2016, at 1:20 AM, Taras Zakharko wrote: >> >> Great! >> >> This cleanly separates between the type and the name/signature! Simple and >> consistent. Thank you! >> >> A clarification question: do i

Re: [swift-evolution] executing a string

Turning strings into selectors is a powerful feature as well ;-) — but afaik, Swift doesn't use another sort of special dispatch besides what is known from other languages. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.o

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

> On Jul 14, 2016, at 1:20 AM, Taras Zakharko wrote: > > Great! > > This cleanly separates between the type and the name/signature! Simple and > consistent. Thank you! > > A clarification question: do i understand correctly that steps 2 and 3 will > not be included in Swift 3 due time constr

[swift-evolution] executing a string

One of the major security flaws of Obj C is the ability to convert a string into a selector, which permits using private methods by constructing selectors at runtime long after the app store review has been completed. Does Swift do away with that? I understand it doesn't use selectors per se b

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

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 one most likely has issues as well, but imho they aren't that obvious and des

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

Just +100. One more wise decision from the core team. Thank you for all of your work. On 14.07.2016 7:47, Chris Lattner via swift-evolution wrote: Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md Shortly after SE-0111 was accep

Re: [swift-evolution] [SE-0088] Dispatch API names

I just discovered this thread by accident - thank the Lord I’m not the only one who feels like this about the new Dispatch API! > On 8 Jul 2016, at 04:16, Darren Mo via swift-evolution > wrote: > > Should I create a bug report for changing `DispatchQueue.after` and > `DispatchSource.read`? >

Re: [swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

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 wanted to share the gist of my thoughts, in case the

[swift-evolution] [Meta] Proposal status page

I got sidetracked today and mocked up a proposal "status page": http://jtbandes.github.io/swift-evolution/ This moves the proposal status info (currently in README.md) into a separate "source of truth": https://github.com/jtbandes/swift-evolution/blob/master/proposals.xml The status pag

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

Great! This cleanly separates between the type and the name/signature! Simple and consistent. Thank you! A clarification question: do i understand correctly that steps 2 and 3 will not be included in Swift 3 due time constraints? — T > On 14 Jul 2016, at 06:47, Chris Lattner via swift-evolut