[swift-evolution] [Proposal] Make non-escaping closures the default

https://github.com/tanadeau/swift-evolution/blob/make-noescape-default/proposals/-make-noescape-default.md # Make non-escaping closures the default * Proposal: [SE-](-name.md) * Author: [Trent Nadeau](https://github.com/tanadeau) * Status: **Awaiting review** * Review manager: TBD

Re: [swift-evolution] [Proposal] Enum subsets

Sub typing is the answer that we're going with then? On Sat, Jun 4, 2016 at 4:26 PM, T.J. Usiyan wrote: > It could be a more general solution. I am unclear about what 'subtype > relationships' means here though. > > Are you talking a about what you allude to here? >

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPhone > On Jun 5, 2016, at 7:02 PM, Austin Zheng wrote: > > Thank you for your feedback, Doug! I appreciate you taking the time to read > through everything and write up your thoughts. I'll revise the proposal and > plan for a 2017 time frame. It should

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 5, 2016, at 9:40 PM, Andrew Bennett wrote: > > Responses inline > > On Mon, Jun 6, 2016 at 12:23 PM, Matthew Johnson > wrote: > > > Sent from my iPad > > On Jun 5, 2016, at 8:43 PM, Andrew Bennett

Re: [swift-evolution] Pitch: @required attribute for closures

Responses inline On Mon, Jun 6, 2016 at 12:23 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Jun 5, 2016, at 8:43 PM, Andrew Bennett wrote: > > Thanks Matthew, my responses are inline: > > On Mon, Jun 6, 2016 at 10:32 AM, Matthew Johnson

Re: [swift-evolution] Pitch: @required attribute for closures

Sent from my iPad > On Jun 5, 2016, at 8:43 PM, Andrew Bennett wrote: > > Thanks Matthew, my responses are inline: > >> On Mon, Jun 6, 2016 at 10:32 AM, Matthew Johnson >> wrote: >> >> >> Sent from my iPad >> >>> On Jun 5, 2016, at 6:50 PM,

Re: [swift-evolution] Enhanced existential types proposal discussion

Thank you for your feedback, Doug! I appreciate you taking the time to read through everything and write up your thoughts. I'll revise the proposal and plan for a 2017 time frame. I would also be happy to see someone from the core team write up a proposal when the time is right, should they feel

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPhone > On Jun 5, 2016, at 6:41 PM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Jun 5, 2016, at 6:20 PM, Douglas Gregor wrote: >> >> >>> On May 18, 2016, at 12:35 AM, Austin Zheng wrote: >>>

Re: [swift-evolution] Pitch: @required attribute for closures

Thanks Matthew, my responses are inline: On Mon, Jun 6, 2016 at 10:32 AM, Matthew Johnson wrote: > > > Sent from my iPad > > On Jun 5, 2016, at 6:50 PM, Andrew Bennett wrote: > > Perhaps I was unclear, in my explanation. The guarantee I'm enforcing is

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPad > On Jun 5, 2016, at 6:20 PM, Douglas Gregor wrote: > > >> On May 18, 2016, at 12:35 AM, Austin Zheng wrote: >> >> I've put together a considerably more detailed draft proposal, taking into >> account as much of Matthew's

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, John McCall wrote: > On Jun 2, 2016, at 1:43 PM, Russ Bishop wrote: > > On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution > > wrote: > > I still think the value-based APIs are

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, John McCall wrote: > On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution > > wrote: > > On Jun 2, 2016, at 10:38 AM, Xiaodi Wu wrote: > > Well, as I understand it, it's not actually

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, Matthew Johnson wrote: > On Jun 2, 2016, at 10:03 AM, Xiaodi Wu wrote: > > That proposal was returned for revision; as far as user ergonomics in Swift > 3, .self is going to be a consideration. Best to find a solution >

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, Matthew Johnson wrote: > On Jun 2, 2016, at 10:01 AM, Charlie Monroe > wrote: > > Isn’t this a short-term concern? I thought that requirement was going away. > > AFAIK there are still concerns about ambiguity - [Int]

Re: [swift-evolution] Pitch: @required attribute for closures

Sent from my iPad > On Jun 5, 2016, at 6:50 PM, Andrew Bennett wrote: > > Perhaps I was unclear, in my explanation. The guarantee I'm enforcing is that > the closure is called exactly once before being released. > > Everything I suggested is a compile-time check. > > The

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

on Thu Jun 02 2016, John McCall wrote: > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed context, like so: > let x: UInt16 = 7 > or > let x = 7 as UInt16 > > Nonetheless, programmers often try the

Re: [swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

Sorry, I can't seem to find the original message. on Tue May 31 2016, Thorsten Seitz wrote: >> Am 31.05.2016 um 14:46 schrieb Haravikk via swift-evolution >> : >> >> So for Swift 3 we’re going to have the great new indexing model that >>

Re: [swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

on Sat Jun 04 2016, Thorsten Seitz wrote: > That's a good idea! I'd like to see how some real algorithms would > look like with that approach. Exactly. -- -Dave ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Pitch: @required attribute for closures

Perhaps I was unclear, in my explanation. The guarantee I'm enforcing is that the closure is called exactly once before being released. Everything I suggested is a compile-time check. The compile-time warning and runtime `fatalError` I suggested could be replaced with a compile-time error,

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

Bringing up an old idea, we could rewrite `rethrows` using Never and throws type specification: func call(block: () throws E -> T) throws E -> T But this requires some compiler magic: non-throwing functions should effectively become functions throwing Never. - Anton 2016-06-06 1:53

Re: [swift-evolution] Marking sort and sorted with rethrows

on Sun Jun 05 2016, Tim Vermeulen wrote: > Most standard library functions that take a closure allow that closure > to throw (and those functions are subsequently marked with > rethrows). sort and sorted are exceptions to this. I couldn’t find > this documented

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 18, 2016, at 12:35 AM, Austin Zheng wrote: > > I've put together a considerably more detailed draft proposal, taking into > account as much of Matthew's feedback as I could. You can find it below: > >

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 5, 2016, at 5:46 PM, michael.petern...@gmx.at wrote: > >> Am 05.06.2016 um 20:31 schrieb Charlie Monroe via swift-evolution >> >: >> >> While I agree with Michael that nowadays, a lot of stuff that doesn't need >> to be, is

Re: [swift-evolution] Pitch: @required attribute for closures

> Am 05.06.2016 um 20:31 schrieb Charlie Monroe via swift-evolution > : > > While I agree with Michael that nowadays, a lot of stuff that doesn't need to > be, is done async, which leads to a giant thread pool per app and developers > nowadays do not think of the

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution > : > > The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely in > generic types. I would like to call the type

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 12:56 PM, Austin Zheng via swift-evolution > wrote: > > This is pretty much where my thinking about the topic has led me as well. > I'll resign this topic to pursue some other, hopefully more relevant work, > although anyone who wants to

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

I have to agree with Never. None is for Optional.none, and it looks like Void in function signature. I would argue that Never could not be mistaken as a synonym for Void. protocol Nothing {} is exactly how Any could be defined, so it's an opposite entity. We could define that as a protocol that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

on Wed May 25 2016, Matthew Johnson wrote: > Sent from my iPad > >> On May 25, 2016, at 12:10 PM, Jordan Rose via swift-evolution >> wrote: >> >> On May 25, 2016, at 05:27, Brent Royal-Gordon via swift-evolution

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

*please* let us not repeat the mostly avoidable challenging-to-explain-to-newcomers-and-vetarans-alike situation that we had in Obj-C with regard to `nil`. nil Nil NULL NSNull nullptr kCFNull __DARWIN_NULL are the representations of 'don't have' that come to mind. On Sun, Jun 5, 2016 at 2:39

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 5, 2016, at 9:47 PM, Pyry Jahkola via swift-evolution > wrote: > I would prefer the type to be simple, and be implemented as a case-less enum (not a bottom value, as in Haskell). None should be a usual enum, with no compiler magic

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

>>> I would prefer the type to be simple, and be implemented as a case-less >>> enum (not a bottom value, as in Haskell). >>> >>> None should be a usual enum, with no compiler magic except that functions >>> returning None are equivalent to current @noreturn. >> >> I think it would be more

[swift-evolution] Discussion: Why is "nil" not "none"

Quick thought: If optional has a .none case, wouldn't it be more consistent to rename nil to none? Also, would nil make it into Swift if not for other languages? It also might make it somewhat clearer: var someInt: Int? = none //looks less like a pointer and more like a value of nothing 1.

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 5, 2016, at 8:39 PM, Charlie Monroe via swift-evolution > wrote: > > While None is probably the best way to describe the opposite of Any, it would > be often mistaken for .None (i.e. Optional) by newcomers to the language. > > I'd personally prefer

Re: [swift-evolution] Marking sort and sorted with rethrows

> On 5 Jun 2016, at 19:14, Tim Vermeulen via swift-evolution > wrote: > > Most standard library functions that take a closure allow that closure to > throw (and those functions are subsequently marked with rethrows). sort and > sorted are exceptions to this. I

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 5, 2016, at 1:49 PM, Pyry Jahkola via swift-evolution > wrote: > > >> On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution >> > wrote: >> >> The following names were suggested: NoReturn,

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution > wrote: > > The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely in > generic types. I would pick `Never` because

Re: [swift-evolution] Pitch: @required attribute for closures

While I agree with Michael that nowadays, a lot of stuff that doesn't need to be, is done async, which leads to a giant thread pool per app and developers nowadays do not think of the cost of inter-thread communication (i.e. each dispatch_(a)sync has its cost, even though it's a light-weight

[swift-evolution] [Draft] Change @noreturn to unconstructible return type

The following names were suggested: NoReturn, Bottom, None, Never. I would pick None, because it looks like opposite to Any and fits nicely in generic types. I would prefer the type to be simple, and be implemented as a case-less enum (not a bottom value, as in Haskell). None should be a usual

Re: [swift-evolution] SE-0064 Property Selectors and KVO

#selector(Thing.thingWatched) won't work because it expects a function. As thingWatched is a property, it doesn't know if you want to reference the getter or setter. SE-0064 lets you reference those explicitly. In this case, you could write NSStringFromSelector(#selector(getter:

[swift-evolution] Marking sort and sorted with rethrows

Most standard library functions that take a closure allow that closure to throw (and those functions are subsequently marked with rethrows). sort and sorted are exceptions to this. I couldn’t find this documented anywhere, but I assume this is because sorting can happen in-place and it would be

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 5, 2016, at 10:28 AM, Michael Peternell > wrote: > > This is not a good design. If you want the completion handler to be called, > you can rewrite the function to make this intent obvious: > > func doSomethingAsync(completionHandler: (SomeEnum) -> ()) { >

Re: [swift-evolution] Pitch: @required attribute for closures

> Am 05.06.2016 um 11:37 schrieb Charles Srstka via swift-evolution > : > > MOTIVATION: > > As per the current situation, there is a pitfall when writing asynchronous > APIs that does not occur when writing synchronous APIs. Consider the > following synchronous

Re: [swift-evolution] Pitch: @required attribute for closures

Sent from my iPad > On Jun 5, 2016, at 8:52 AM, Andrew Bennett wrote: > > Storing into a member would be fine, as long as it must keep @once as a type > annotation and the compiler makes sure you maintain: > sum(callCount, storeCount, passCount) == 1 > > For example: >

Re: [swift-evolution] Pitch: @required attribute for closures

Sent from my iPad > On Jun 5, 2016, at 6:56 AM, Andrew Bennett wrote: > > I like this. > > One of the suggestions on @noescape(once) was that it just becomes @once and > works with escaping closures too. It might be possible if compile time checks > verified that the

Re: [swift-evolution] Pitch: @required attribute for closures

"runtime circumstance" -> "runtime assertion", weird typo. On Sun, Jun 5, 2016 at 9:56 PM, Andrew Bennett wrote: > I like this. > > One of the suggestions on @noescape(once) was that it just becomes @once > and works with escaping closures too. It might be possible if compile

Re: [swift-evolution] Pitch: @required attribute for closures

Sent from my iPad > On Jun 5, 2016, at 5:02 AM, Patrick Pijnappel via swift-evolution > wrote: > > This has actually been proposed before, see SE-0073: > https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md Actually that proposal

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> To answer my own question, relooking at the proposal, RawRepresentable > wouldn’t be suitable for Bool, Character, UnicodeScalar, Integer, etc. > >> On 5 Jun 2016, at 7:20 PM, Patrick Smith wrote: >> >> (This raises a point — what’s the difference between the proposed >>

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

To answer my own question, relooking at the proposal, RawRepresentable wouldn’t be suitable for Bool, Character, UnicodeScalar, Integer, etc. > On 5 Jun 2016, at 7:20 PM, Patrick Smith wrote: > > (This raises a point — what’s the difference between the proposed >

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

Good point Sent from my iPhone > On Jun 5, 2016, at 00:16, Patrick Smith wrote: > > The issue I think is that it would open up serialisation for all sorts of > formats, which is a much larger problem in itself, whereas this can just > focus on a user-defined ‘lossless’

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

The issue is to decide on the applicability scope. Thinking 'my app/their stuff' is an illusion. To the compiler & runtime there is only code split into modules, some in source code and others as dylibs (.dll, .so, ...). Any extension based conditional refines a protocol everywhere. What's hard

[swift-evolution] Pitch: @required attribute for closures

MOTIVATION: As per the current situation, there is a pitfall when writing asynchronous APIs that does not occur when writing synchronous APIs. Consider the following synchronous API: func doSomething() -> SomeEnum { if aCondition { if bCondition {

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On 5 Jun 2016, at 4:31 PM, Brent Royal-Gordon wrote: > > Sorry, I meant to reply to this but forgot. No worries Brent! Thanks for the thoughtful reply. > >> For developers, like ourselves, it seems straight-forward that a string is >> this simple primitive. We get

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> Am 04.06.2016 um 23:18 schrieb Austin Zheng via swift-evolution > : > > Hello Dan, > > You'll be pleased to learn that conforming generic types conditionally to > protocols is on the roadmap (and is one of the highest priority items for the > versions of Swift

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

IMO you have identified some of the symptoms of a larger issue with Swift. Currently swift lets us group our code into modules. Within a module we can use folders to physically group the files, but this is not mandatory (and xcode does not by default align the logical and physical structure of

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Sorry, I meant to reply to this but forgot. > For developers, like ourselves, it seems straight-forward that a string is > this simple primitive. We get them in, we process them, and we spit them back > out. However, this is a flawed system, as it one that is made easiest for the > programmer,