Re: [swift-evolution] Default Generic Arguments

[Trent Nadeau via swift-evolution]

The fact that it has a default generic argument means that it has a "knob"
to turn based on changes in needs of the code. For example, if you had a
struct that used a T (defaulted to Int) for a field, and that field's range
should become a Double in your use case, you know that there's something
you can change to get that behavior, while just X might look like you'd
need to create your own type.

On Mon, Jan 23, 2017 at 2:41 PM, Michael Ilseman <milse...@apple.com> wrote:

>
> On Jan 23, 2017, at 10:41 AM, Trent Nadeau via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The proposal looks good to me with one possible concern. I'm leaning
> toward types that use the defaults should still require the angle brackets,
> X<>. This makes it clear that you're using a generic type.
>
>
> What are the perceived benefits by making it explicit that you’re using a
> defaulted-or-inferred generic type? What important pieces of information
> would the presence of an explicit “<>” communicate to future
> readers/maintainers of the code?
>
> That leads me to think that the examples Doug gave should be an error as
> the explicit types on the `let`s should either be omitted completely or
> fully specified (as X<>, X, X, etc.).
>
> On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi Everyone,
>>
>> I've opened a PR (https://github.com/apple/swift-evolution/pull/591
>> ) proposing default generic arguments which I think would be nice
>> addition to the language. They are also mentioned in "Generic manifesto".
>>
>> The proposal is focusing around generic types. Generic functions are not
>> coved by the proposal and I don't think that we need default generic
>> arguments in generic functions as all the types are always part of the
>> function signature so the compiler can always infer them. One corner case
>> might be if using default argument values in which case support for default
>> generic arguments in functions might be useful.
>>
>>
>> The proposal looks fairly straightforward and reasonable. One thing to
>> think about is how it interacts with type inference. For example, consider
>> these examples:
>>
>> struct X { }
>>
>> func f1() -> X { return X() }
>>
>> func f2() -> X { return X() }
>> func f2() -> X { return X() }
>>
>> func f3(_: T) -> X { return X() }
>>
>> let x1: X = f1()   // okay: x1 has type X?
>> let x2: X = f2()   // ambiguous?
>> let x3a: X = f3(1.5)   // okay: x3a has type X?
>> let x3b: X = f3(1)   // okay: x3a has type X?
>>
>> The type checker already has some notion of “if you can’t infer a
>> particular type, fill in a default” that is used for literals. That rule
>> could be used here… or we could do something else. This should be discussed
>> in the proposal.
>>
>> Thanks for working on this!
>>
>>
>> There's an interesting parallel to the default behavior of literals. The
>> type of a number or string literal is inferred from type context, or falls
>> back to a default type like Int or String if that doesn't come up with an
>> answer. You could think of that of saying the 'Self' type of the protocol
>> constraint has a default (and maybe that's how we'd generalize the "default
>> type for a protocol" feature if we wanted to.) It makes sense to me to
>> follow a similar model for generic parameter defaults; that way, there's
>> one consistent rule that applies.
>>
>> -Joe
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Trent Nadeau
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Default Generic Arguments

[Trent Nadeau via swift-evolution]

The proposal looks good to me with one possible concern. I'm leaning toward
types that use the defaults should still require the angle brackets, X<>.
This makes it clear that you're using a generic type. That leads me to
think that the examples Doug gave should be an error as the explicit types
on the `let`s should either be omitted completely or fully specified (as
X<>, X, X, etc.).

On Mon, Jan 23, 2017 at 1:21 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Everyone,
>
> I've opened a PR (https://github.com/apple/swift-evolution/pull/591) proposing
> default generic arguments which I think would be nice addition to the
> language. They are also mentioned in "Generic manifesto".
>
> The proposal is focusing around generic types. Generic functions are not
> coved by the proposal and I don't think that we need default generic
> arguments in generic functions as all the types are always part of the
> function signature so the compiler can always infer them. One corner case
> might be if using default argument values in which case support for default
> generic arguments in functions might be useful.
>
>
> The proposal looks fairly straightforward and reasonable. One thing to
> think about is how it interacts with type inference. For example, consider
> these examples:
>
> struct X { }
>
> func f1() -> X { return X() }
>
> func f2() -> X { return X() }
> func f2() -> X { return X() }
>
> func f3(_: T) -> X { return X() }
>
> let x1: X = f1()   // okay: x1 has type X?
> let x2: X = f2()   // ambiguous?
> let x3a: X = f3(1.5)   // okay: x3a has type X?
> let x3b: X = f3(1)   // okay: x3a has type X?
>
> The type checker already has some notion of “if you can’t infer a
> particular type, fill in a default” that is used for literals. That rule
> could be used here… or we could do something else. This should be discussed
> in the proposal.
>
> Thanks for working on this!
>
>
> There's an interesting parallel to the default behavior of literals. The
> type of a number or string literal is inferred from type context, or falls
> back to a default type like Int or String if that doesn't come up with an
> answer. You could think of that of saying the 'Self' type of the protocol
> constraint has a default (and maybe that's how we'd generalize the "default
> type for a protocol" feature if we wanted to.) It makes sense to me to
> follow a similar model for generic parameter defaults; that way, there's
> one consistent rule that applies.
>
> -Joe
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

[Trent Nadeau via swift-evolution]

For an architecture to be C-compatible, its byte size must be 8 bits. Given
the need to run C everywhere and that almost all OSes are written in C,
it's a very safe assumption that a byte equals 8 bits. At this point, I
think the only thing where that's not true are certain micro-controllers
for which there are specialized compilers.

In any case, LLVM (the compiler infrastructure on which the Swift compiler
is built) doesn't support architectures where that's not true.

On Tue, Aug 23, 2016 at 1:12 PM, Jason Cardwell via swift-evolution <
swift-evolution@swift.org> wrote:

> As an average developer that likes to look at this stuff on occasion, I
> thought I'd toss in my take on 'byte' terminology. I know little about
> machine architecture; but, it feels like the programming community in
> general has taken the term byte to mean 8 bits. Since it is actually the
> smallest unit of addressable memory, which is much more abstract, the APIs
> tend to go all wonky. In my head I think of it in a way not unlike the Int,
> IntMax, Int64 family. I haven't dealt with an architecture where IntMax =
> Int32 in so long that as I'm coding my head translates them all to 'a 64
> bit integer'. However, the aliasing is enough to keep me honest from time
> to time as it forces me to consider whether I can count on a certain size
> for a particular situation. I don't know, something about the Byte and
> UInt8 situation feels the same to me. It seems like the standard library
> should be telling me upfront somewhere what the hell I can safely call a
> byte for the target architecture. The need for this proposal arose out of
> developers like me wanting to work with bytes. If some future architecture
> allowed addressing 4 bits instead of 8, that's what I'd want to work with.
> It seems any confusion over interchangeable use of Byte and UInt8 stems
> from the varying levels of degree to which people see byte as an abstract
> term vs 8 bits. A simple declaration somewhere that officially tells us,
> "Hey, when you see mention of byte it is safe to think in your head '8
> bits''' would make it all fall in line for me. Anywho, thanks so far for
> the wonderful language.
>
> Jason Cardwell
>
> On Aug 19, 2016, at 12:43 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Fri, Aug 19, 2016 at 2:32 PM, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On 19 Aug 2016, at 19:35, Andrew Trick  wrote:
>>
>>
>> On Aug 16, 2016, at 7:13 PM, Karl via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> It seems like there’s a potential for confusion here, in that people may
>> see “UInt8” and assume there is some kind of typed-ness, even though the
>> whole point is that this is untyped. Adjusting the header comments slightly
>> might help:
>>
>>
>> /// A non-owning view of raw memory as a collection of bytes.
>> ///
>> /// Reads and writes on memory via `UnsafeBytes` are untyped operations
>> that
>> /// do no require binding the memory to a type. These operations are
>> expressed
>> /// in terms of `UInt8`, though the underlying memory is untyped.
>>
>> …
>>
>> You could go even further towards hinting this fact with a `typealias
>> Byte = UInt8`, and use Byte throughout. But, I don’t know if that’s getting
>> too excessive.
>>
>>
>> I don't think that's too excessive at all. I might even go further and
>> say that we should call it "Untyped" instead of "Byte", to really drive
>> home the point (many people see "byte" and think "8-bit int", which is
>> merely a side effect of CPUs generally not having support for types *other*
>> than ints and floats, rather than a reflection of the true "type" of the
>> data).
>>
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ‘Byte’ is sufficient, I think.
>>
>> In some sense, it is typed as bytes. It reflects the fact that anything
>> that is representable to the computer must be expressible as a sequence of
>> bits (the same way we have string de/serialisation — which of course is not
>> to say that the byte representation is good for serialisation purposes).
>> “withUnsafeBytes” can be seen as doing a reversible type conversion the
>> same way LosslessStringConvertible does; only in this case the conversion
>> is free.
>>
>>
>> Yes. Byte clearly refers to a value's in-memory representation. But
>> typealias Byte = UInt8 would imply the opposite of what needs to be
>> conveyed. The name Byte refers to raw memory being accessed, not the value
>> being returned by the collection. The in-memory value's bytes are loaded
>> from memory and reinterpreted as UInt8 

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

[Trent Nadeau via swift-evolution]

On Tue, Jul 5, 2016 at 7:11 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0117: Default classes to be non-subclassable publicly"
> begins now and runs through July 11. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.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?
>
A strong +1 to the new default. I agree with others that having two
keywords that also conflate/imply public access is less than ideal. Having
a `public(open) class` or `public open class` would be better in my opinion.

> * 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. Requiring extra keywords and safety at module boundaries to clarify
intent has been a philosophy toward Swift language changes.

> * 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?
>
Read the proposal as well as this and earlier discussions.

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



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Trent Nadeau via swift-evolution]

On Wed, Jun 22, 2016 at 2:04 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0095: Replace `protocol` syntax with
> `Any`" begins now and runs through June 27. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.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?
>
+1. I think this syntax shorter and easier to read.

> * 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. It improves the use of protocols in generics and existentials.

> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
Rust uses `+` with its traits, with basically the same meaning.

> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
Read the proposal and followed the email threads.

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



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Trent Nadeau via swift-evolution]

I've created the PR for the proposal at
https://github.com/apple/swift-evolution/pull/373.

Thanks again to everyone that has discussed this so far.

On Mon, Jun 20, 2016 at 8:18 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 9, 2016, at 4:15 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >>
> >> On Jun 9, 2016, at 16:10, John McCall  wrote:
> >>
> >>> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I'm against this for library evolution reasons: if someone releases a
> version of their library that has a non-escaping closure and later
> discovers it needs to be escaping, they can't change it.
> >>>
> >>> IIRC the counterpoint to this is that people were probably implicitly
> relying on it being non-escaping already, and that there aren't many cases
> where you'd want to do this anyway.
> >>
> >> Right.  APIs are already semantically constrained in how they're
> allowed to use their closure arguments.  Closure arguments inject arbitrary
> code, with arbitrary data access, into the callee; as a rule, the caller
> must know how the callee intends to use the closure, or its semantics will
> be grossly violated.  You can't re-implement an existing API that always
> synchronously sub-invokes a closure to instead call the closure
> asynchronously or concurrently because it is completely reasonable for the
> caller to pass a closure that relies on being called synchronously or from
> at most one thread at once and/or within a fixed range of time.  For
> example, the closure may modify a captured local variable, or it may it use
> a network connection that will be closed after the API returns.  APIs that
> want to do this sort of thing have to reserve the right to do that (and
> even then, they may have binary compatibility limitations), in which case
> it is totally reasonable to expect them to express that in the type.
> >
> > I don't buy this. If someone publishes an API that executes something on
> the current thread today and on a background queue tomorrow, that's totally
> fine if they never promised it would execute on a particular thread. If a
> client accidentally assumes an implementation detail is part of the
> interface, that's their fault, and always has been…though the library
> author might decide to continue supporting their use in the future in the
> interest of not making waves.
> >
> > (Escaping/non-escaping by default doesn't affect this, by the way, but
> by the same token this argument doesn't really affect escaping/non-escaping
> by default.)
>
> This hardly ever goes well. There's a pretty long blood trail of blog
> posts about this kind of attempted evolution in Javascript land;
> http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/
> happens to be the one I have on hand this moment.
>
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Trent Nadeau via swift-evolution]

Thanks for the very interesting design discussion so far. It's exactly what
I was wanting to see :)

I'm going to incorporate some of this in the next draft of the proposal.
I'm also going to add that there should be an asUnsafeEscapingClosure(_:)
helper that will convert a default/noescape closure to an escaping one. For
the initial implementation it could use unsafeBitCast(_:to:) to perhaps be
changed later.

On Thu, Jun 9, 2016 at 8:29 PM, John McCall  wrote:

> On Jun 9, 2016, at 4:15 PM, Jordan Rose  wrote:
>
> On Jun 9, 2016, at 16:10, John McCall  wrote:
>
> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm against this for library evolution reasons: if someone releases a
> version of their library that has a non-escaping closure and later
> discovers it needs to be escaping, they can't change it.
>
> IIRC the counterpoint to this is that people were probably implicitly
> relying on it being non-escaping already, and that there aren't many cases
> where you'd want to do this anyway.
>
>
> Right.  APIs are already semantically constrained in how they're allowed
> to use their closure arguments.  Closure arguments inject arbitrary code,
> with arbitrary data access, into the callee; as a rule, the caller must
> know how the callee intends to use the closure, or its semantics will be
> grossly violated.  You can't re-implement an existing API that always
> synchronously sub-invokes a closure to instead call the closure
> asynchronously or concurrently because it is completely reasonable for the
> caller to pass a closure that relies on being called synchronously or from
> at most one thread at once and/or within a fixed range of time.  For
> example, the closure may modify a captured local variable, or it may it use
> a network connection that will be closed after the API returns.  APIs that
> want to do this sort of thing have to reserve the right to do that (and
> even then, they may have binary compatibility limitations), in which case
> it is totally reasonable to expect them to express that in the type.
>
>
> I don't buy this. If someone publishes an API that executes something on
> the current thread today and on a background queue tomorrow, that's totally
> fine if they never promised it would execute on a particular thread. If a
> client accidentally assumes an implementation detail is part of the
> interface, that's their fault, and always has been…though the library
> author might decide to continue supporting their use in the future in the
> interest of not making waves.
>
>
> Synchronous-but-off-thread is kind of a special case because it's only
> observable in very special ways, e.g. thread-local storage and the current
> thread ID.  Concurrent (e.g. calling an enumeration callback on multiple
> threads simultaneously) and asynchronous (even if it comes back to the
> current queue) are absolutely something you have to know about as a
> caller.  It is deeply unreasonable for an API to suddenly start invoking a
> closure asynchronously when it hasn't documented that it might do that
> (perhaps implicitly by obviously following some well-known pattern, e.g.
> calling the closure a completion handler); that would be a huge semantic
> and binary-compatibility problem.
>
> Another line of argument: flipping the default is a huge boon to static
> analysis because (1) closure execution becomes ordered by default and (2)
> an escaping closure becomes a much more meaningful hint.  For example,
> consider a use-after-free static analysis that sees this code:
>
>   func foo(ptr: UnsafeMutablePointer) {
> bar { ptr[5] = 0 }
> ptr.dealloc()
>   }
>
> This analysis is currently blocked by this abstraction unless it knows
> something specific about 'bar'.  If 'bar' marks its argument @noescape,
> then the analysis knows that this is safe; but if not, the analysis is
> unlikely to be willing to warn because it's quite likely that 'bar' is just
> missing an annotation and does not actually execute its closure
> asynchronously.  However, if the polarity is flipped, the analysis wins on
> both ends: it can prove correctness in many more cases by default, and the
> cases where the closure actually escapes become much more suspicious,
> probably enough to warn by default.
>
> John.
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Trent Nadeau via swift-evolution]

When would be a good time to actual put out a PR to the swift-evolution
repo for this proposal? The feedback so far has been very light, but I'm
not sure if that's because everyone's gearing up for WWDC, if there's
little interest, or if it's uncontroversial.

On Wed, Jun 8, 2016 at 1:17 PM, John McCall  wrote:

> > On Jun 7, 2016, at 7:25 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >> @escaping would be part of the parameter type just as @noescape is
> today. Your foo(closure:) example wouldn't compile with my proposal, the
> same as today if you marked the parameter with @noescape. Non-escaping
> function parameters are only allowed to be called. They can't be assigned
> to variables.
> >
> > Okay, that does correct that issue. Although it raises a separate issue:
> a bare closure type now means something different in a parameter list than
> anywhere else.
>
> @escaping is really a parameter-specific aspect of the outer function
> type, not an aspect of the parameter's type.  It's just like something like
> NS_CONSUMED in Objective-C ARC.
>
> John.
>
> > Are generic types which happen to be functions in some particular use
> automatically @escaping? Are typealiases and associated types automatically
> @escaping?
> >
> > Also, if `@escaping` is a part of the parameter list syntax (like
> `inout`) instead of the type syntax (like `@autoclosure`), would it make
> sense to drop its `@` sign to make them more syntactically similar?
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Trent Nadeau via swift-evolution]

@escaping would be part of the parameter type just as @noescape is today.
Your foo(closure:) example wouldn't compile with my proposal, the same as
today if you marked the parameter with @noescape. Non-escaping function
parameters are only allowed to be called. They can't be assigned to
variables.

The current @noescape and the proposed @escaping can only be applied to the
types of function parameters so the code in your `struct Foo` example
wouldn't change.

Currently escaping and non-escaping closures are considered to be different
types so there is already a problem when a protocol requires a function
with a closure parameter. All conforming types must use the same
"escapiness" as the protocol.

On Tue, Jun 7, 2016 at 3:45 AM, Brent Royal-Gordon 
wrote:

> > This proposal switches the default to be non-escaping and requires an
> `@escaping` annotation if a closure argument can escape the function body.
>
> Is @escaping part of the function type syntax (like @autoclosure) or the
> parameter syntax (like inout)? It seems to me that there are places where
> you *do* want non-parameter closure variables to be non-escaping:
>
> func foo(closure: () -> Void) {
> let bar = closure   // You should not be able to
> escape through `bar`
> }
>
> But then there are also many places where you would have to write
> @escaping even though a non-escaping closure would be obviously nonsensical:
>
> struct Foo {
> var closure: () -> Void // Error;
> @escaping is mandatory here
> func method() -> () -> Void {...}   // Same
> }
>
> Requiring a boilerplate attribute like this is not really so great.
>
> > Existing code using the `@noescape` attribute will need to be migrated
> to remove the attribute since it will be the default. In addition, the
> compiler will need to detect escaping closures that are not marked with
> `@escaping` and create an error with a fixit to add the required attribute.
>
> This becomes difficult when a protocol has a closure parameter; there's
> not necessarily a default implementation to examine for escaping, and even
> if there is one, the default may be a simple, non-escaping implementation
> for something which ought to allow escaping from other implementations.
> Similar concerns apply to non-final class members.
>
> One way to address this issue would be to have the migrator conservatively
> mark non-@noescape closure parameters in protocol and class definitions
> as @escaping, but that might undermine the intent of automatically
> transitioning a lot of code to the new default.
>
> (By the way, is an @escaping closure a subtype of a non-escaping closure?)
>
> --
> Brent Royal-Gordon
> Architechies
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Trent Nadeau via swift-evolution]

I created a draft proposal to make `@noescape` the default and created a
new email thread with subject "[Proposal] Make non-escaping closures the
default".

On Thu, Jun 2, 2016 at 1:22 AM, Chris Lattner  wrote:

>
> On Jun 1, 2016, at 9:22 PM, Trent Nadeau  wrote:
>
> I'd like to write this proposal.
>
>
> Go for it!  Thanks,
>
> -Chris
>
>
> On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
>> > 2) For noescape, the core team feels that the right solution is for
>> closure arguments to *default* to noescape, which means that the attribute
>> we should really need is @escaping.
>>
>> To provide some more details, this approach has the following advantages:
>>
>> - Most functional algorithms written in pure Swift will benefit because
>> they are naturally noescape.  The core team feels that this will reduce the
>> boilerplate involved with writing these algorithms.
>>
>> - The compiler has enough logic in it to provide a great QoI experience
>> when a developer doesn’t think about escaping, and tries to escape a
>> closure - it can provide a fixit that suggests adding @escaping.
>>
>> - Recent changes (to disallow escaping closures to close over an inout
>> parameter) are pushing the language to prefer noescape closures.  noescape
>> closures have also always been the preferred default, since they eliminate
>> a class of retain cycle issues.
>>
>> - "@autoclosure(escaping)" can be simplified and standardized to
>> "@autoclosure @escaping”
>>
>>
>> The two primary concerns with taking this direction were that it is would
>> adversely impact resilience, and that imported Objective-C APIs would be
>> too annoying to work with, because the compiler would have to be
>> conservative and assume they are escaping:
>>
>>
>>
>> On resilience, the concern with this approach is that an API may not
>> thinking about whether a closure parameter should be escaping or not, and
>> this behavior makes it possible that someone could write “V1” of an API and
>> not accidentally promise noescape semantics, but then need it in “V2” of
>> the same API.
>>
>> John McCall pointed out that resilience in the type system is different
>> than resilience in practice: An API changing to capture a closure and use
>> it long after it was originally passed is likely to break the clients
>> regardless of whether the type system captures this as an issue.  He argues
>> (and the argument is strong IMO) that it is *better* for resilient APIs to
>> default to @noescape, since that forces the author of V2 to think about
>> whether they are breaking their clients.  If they are doing something that
>> is “logically” noescape in their V2, then they can unsafe bitcast away the
>> escaping aspect of the closure.  This is better than changing the client’s
>> view of the API in any case.
>>
>>
>> On imported Objective-C API, the core team did a quick study of the Cocoa
>> APIs and found that most closure/block parameters are escaping in
>> practice.  As such, the core team feels that it isn’t overly burdensome to
>> ask that imported Objective-C APIs annotate their semantically noescape
>> block parameters with the clang __attribute__((noescape)) attribute.
>>
>>
>> I’m happy to write up this proposal, but won’t have cycles to do so for
>> several weeks.  If someone else wants to take it up, that would be great :-)
>>
>> -Chris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
>
> --
> Trent Nadeau
>
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Trent Nadeau via swift-evolution]

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

## Introduction

The current default of closure arguments to functions (i.e., arguments to
functions that themselves have function type such as `(T) -> U`) is to be
"escaping", meaning they can escape the function body such as saving it to
a field in a struct or a global variable. In order to say that a closure
argument cannot possibly escape the function body ("non-escaping"), the
developer must explicitly add an `@noescape` annotation to the argument
type.

This proposal switches the default to be non-escaping and requires an
`@escaping` annotation if a closure argument can escape the function body.
Since the escaping case can be statically detected, this annotation can be
added via an error with a fixit. Other annotations that have consequences
for escape semantics (e.g., `@autoclosure(escaping)`) will be altered to
make use of the new `@escaping` annotation.

Swift-evolution threads: [Discussion thread topic for that proposal (TBD)](
http://news.gmane.org/gmane.comp.lang.swift.evolution)

## Motivation

Per Chris Lattner [on swift-evolution](
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019880.html
):

> To provide some more details, this approach has the following advantages:
>
> - Most functional algorithms written in pure Swift will benefit because
they are naturally noescape.  The core team feels that this will reduce the
boilerplate involved with writing these algorithms.
>
> - The compiler has enough logic in it to provide a great QoI experience
when a developer doesn’t think about escaping, and tries to escape a
closure - it can provide a fixit that suggests adding @escaping.
>
> - Recent changes (to disallow escaping closures to close over an inout
parameter) are pushing the language to prefer noescape closures.  noescape
closures have also always been the preferred default, since they eliminate
a class of retain cycle issues.
>
> - "@autoclosure(escaping)" can be simplified and standardized to
"@autoclosure @escaping”

## Detailed design

The `@noescape` annotation is removed from the language. The compiler will
emit an error with a fixit to remove the annotation.

The compiler will emit an error if a closure argument is found to possibly
escape the function body. In order to silence the warning, the developer
must add, manually or via fixit, the `@escaping` annotation to the argument
type.

The compiler's semantic analysis implementation can be simplified as the
more constrained escaping case that conflicts with other attributes is now
no longer the default.

The standard library should be changed to use the new default whenever
possible by removing all uses of `@noescape` and only adding `@escaping`
where the compiler detects the need.

### Imported C/Objective-C APIs

Per the Core Team, most Cocoa closure/block parameters are escaping (e.g.,
delegates). As such the Clang importer will automatically add the
`@escaping` annotation to closure/block parameters encountered in imported
Objective-C APIs unless they are explicitly marked with the Clang
`((noescape))` attribute. This will also be done with imported C APIs with
function pointer or block parameters.

## Impact on existing code

Existing code using the `@noescape` attribute will need to be migrated to
remove the attribute since it will be the default. In addition, the
compiler will need to detect escaping closures that are not marked with
`@escaping` and create an error with a fixit to add the required attribute.

Uses of `@autoclosure(escaping)` must be changed to `@autoclosure
@escaping`.

There should be few, if any, changes required for uses of Cocoa APIs as
these will be mostly marked as `@escaping`, and escaping closure arguments
are *more* constrained than non-escaping ones.

## Future directions

The `@noescape(once)` annotation proposed in [SE-0073](
https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md)
would, if some future version is accepted, just become `@once`.

## Alternatives considered

Leave the `@noescape` attribute and existing semantics as they are now.

## Acknowledgements

Thanks to Chris Lattner, **TBD**, and anyone else who reviewed and
contributed to this proposal.


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Trent Nadeau via swift-evolution]

I'd like to write this proposal.

On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
> > 2) For noescape, the core team feels that the right solution is for
> closure arguments to *default* to noescape, which means that the attribute
> we should really need is @escaping.
>
> To provide some more details, this approach has the following advantages:
>
> - Most functional algorithms written in pure Swift will benefit because
> they are naturally noescape.  The core team feels that this will reduce the
> boilerplate involved with writing these algorithms.
>
> - The compiler has enough logic in it to provide a great QoI experience
> when a developer doesn’t think about escaping, and tries to escape a
> closure - it can provide a fixit that suggests adding @escaping.
>
> - Recent changes (to disallow escaping closures to close over an inout
> parameter) are pushing the language to prefer noescape closures.  noescape
> closures have also always been the preferred default, since they eliminate
> a class of retain cycle issues.
>
> - "@autoclosure(escaping)" can be simplified and standardized to
> "@autoclosure @escaping”
>
>
> The two primary concerns with taking this direction were that it is would
> adversely impact resilience, and that imported Objective-C APIs would be
> too annoying to work with, because the compiler would have to be
> conservative and assume they are escaping:
>
>
>
> On resilience, the concern with this approach is that an API may not
> thinking about whether a closure parameter should be escaping or not, and
> this behavior makes it possible that someone could write “V1” of an API and
> not accidentally promise noescape semantics, but then need it in “V2” of
> the same API.
>
> John McCall pointed out that resilience in the type system is different
> than resilience in practice: An API changing to capture a closure and use
> it long after it was originally passed is likely to break the clients
> regardless of whether the type system captures this as an issue.  He argues
> (and the argument is strong IMO) that it is *better* for resilient APIs to
> default to @noescape, since that forces the author of V2 to think about
> whether they are breaking their clients.  If they are doing something that
> is “logically” noescape in their V2, then they can unsafe bitcast away the
> escaping aspect of the closure.  This is better than changing the client’s
> view of the API in any case.
>
>
> On imported Objective-C API, the core team did a quick study of the Cocoa
> APIs and found that most closure/block parameters are escaping in
> practice.  As such, the core team feels that it isn’t overly burdensome to
> ask that imported Objective-C APIs annotate their semantically noescape
> block parameters with the clang __attribute__((noescape)) attribute.
>
>
> I’m happy to write up this proposal, but won’t have cycles to do so for
> several weeks.  If someone else wants to take it up, that would be great :-)
>
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0097: Normalizing naming for "negative" attributes

[Trent Nadeau via swift-evolution]

I meant writing a proposal for having noescape be the default with an
`@escaping` attribute to have different behavior. `@once` would be a
separate proposal and looks to be out of scope for Swift 3.0.

The former change was mentioned by Chris Lattner in
http://article.gmane.org/gmane.comp.lang.swift.evolution/16896.

On Sat, May 28, 2016 at 3:21 PM, Cheyo Ximenez  wrote:

> Are you talking about writing a proposal for @escaping or @once after it
> becomes feasible?
> I haven't seen a proposal for making `noescape` the default. Do you think
> that is with in the swift 3 scope and goal of source braking changes?
>
> This is where is I saw this first.
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md
>
> On May 28, 2016, at 10:18 AM, Trent Nadeau  wrote:
>
> I agree with Jose. I especially like the idea of making `@noescape` the
> default with a new `@escaping` attribute. As I believed was mentioned in an
> earlier review, this would also make the proposed `@noescape(once)` just be
> `@once`. I'd be happy to write the proposal for that rename.
>
> On Wed, May 25, 2016 at 12:43 PM, Jose Cheyo Jimenez via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> >   * What is your evaluation of the proposal?
>> -1.  noreturn is a term of art that is googable, renaming will make it
>> obscure imo specially since it is not that common in iOS code.
>> If the core team were to keep `noreturn` then `nonscaping` will be weird,
>> but then if `noescape` became the default then (the non negative ;-)
>> `escaping` would make sense.
>>
>> >   * Is the problem being addressed significant enough to warrant a
>> change to Swift?
>>
>> no.
>>
>> >   * Does this proposal fit well with the feel and direction of
>> Swift?
>>
>> no.
>>
>> >   * 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?
>>
>> read the thread.
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
>
> --
> Trent Nadeau
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0097: Normalizing naming for "negative" attributes

[Trent Nadeau via swift-evolution]

I agree with Jose. I especially like the idea of making `@noescape` the
default with a new `@escaping` attribute. As I believed was mentioned in an
earlier review, this would also make the proposed `@noescape(once)` just be
`@once`. I'd be happy to write the proposal for that rename.

On Wed, May 25, 2016 at 12:43 PM, Jose Cheyo Jimenez via swift-evolution <
swift-evolution@swift.org> wrote:

>
> >   * What is your evaluation of the proposal?
> -1.  noreturn is a term of art that is googable, renaming will make it
> obscure imo specially since it is not that common in iOS code.
> If the core team were to keep `noreturn` then `nonscaping` will be weird,
> but then if `noescape` became the default then (the non negative ;-)
> `escaping` would make sense.
>
> >   * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> no.
>
> >   * Does this proposal fit well with the feel and direction of Swift?
>
> no.
>
> >   * 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?
>
> read the thread.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

[Trent Nadeau via swift-evolution]

It would certainly be clearer that the state is changing on each
"iteration", but I'm not sure it's worth such a long parameter label. Maybe
`sequence(state:update:)`?

On Thu, May 19, 2016 at 8:46 PM, Patrick Smith <pgwsm...@gmail.com> wrote:

> Would `sequence(mutatingState:next:)` perhaps be clearer?
>
>
> On 20 May 2016, at 10:37 AM, Trent Nadeau via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Ah, yes. I apologize. The fact that state is inout, and the same instance
> is always passed in confused me. Thanks for the correction.
>
> On Thu, May 19, 2016 at 7:46 PM, Brent Royal-Gordon <
> br...@architechies.com> wrote:
>
>> > Also note that there's a typo in the second example:
>> >
>> > for view in sequence(initial: someView, next: { $0.
>> > superview }) {
>> >
>> > // someView, someView.superview, someView.superview.superview, ...
>> >
>> > }
>> >
>> >
>> > should be:
>> >
>> > for view in sequence(state: someView, next: { $0.
>> > superview }) {
>> >
>> > // someView, someView.superview, someView.superview.superview, ...
>> >
>> > }
>>
>> I don't think these are mistakes—in each iteration of the loop, $0 is
>> supposed to be the view from the previous iteration.
>>
>> If you wanted an example using `state`, here's one which is roughly
>> equivalent to `stride(from: 1.0, to: 2.0, by: 0.1)`, using a
>> non-error-accumulating algorithm:
>>
>> let start = 1.0
>> let end = 2.0
>> let distance = 0.1
>>
>> for color in sequence(state: -1.0, next: { $0 += 1; let next =
>> start + $0 * distance; return next < end ? next : nil }) {
>> …
>> }
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>>
>
>
> --
> Trent Nadeau
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

[Trent Nadeau via swift-evolution]

Ah, yes. I apologize. The fact that state is inout, and the same instance
is always passed in confused me. Thanks for the correction.

On Thu, May 19, 2016 at 7:46 PM, Brent Royal-Gordon 
wrote:

> > Also note that there's a typo in the second example:
> >
> > for view in sequence(initial: someView, next: { $0.
> > superview }) {
> >
> > // someView, someView.superview, someView.superview.superview, ...
> >
> > }
> >
> >
> > should be:
> >
> > for view in sequence(state: someView, next: { $0.
> > superview }) {
> >
> > // someView, someView.superview, someView.superview.superview, ...
> >
> > }
>
> I don't think these are mistakes—in each iteration of the loop, $0 is
> supposed to be the view from the previous iteration.
>
> If you wanted an example using `state`, here's one which is roughly
> equivalent to `stride(from: 1.0, to: 2.0, by: 0.1)`, using a
> non-error-accumulating algorithm:
>
> let start = 1.0
> let end = 2.0
> let distance = 0.1
>
> for color in sequence(state: -1.0, next: { $0 += 1; let next =
> start + $0 * distance; return next < end ? next : nil }) {
> …
> }
>
> --
> Brent Royal-Gordon
> Architechies
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

[Trent Nadeau via swift-evolution]

* What is your evaluation of the proposal?
+1. I've used unfold/iterate functions in Haskell and Clojure, and they are
very useful.
* 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?
See above.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Quick reading.

Also note that there's a typo in the second example:

for view in sequence(initial: someView, next: { $0.superview }) {
// someView, someView.superview, someView.superview.superview, ...
}


should be:

for view in sequence(state: someView, next: { $0.superview }) {
// someView, someView.superview, someView.superview.superview, ...
}




On Thu, May 19, 2016 at 6:29 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0094: Add sequence(initial:next:) and
> sequence(state:next:) to the stdlib" begins now and runs through May 23.
> This is a refinement of part of SE-0045.  The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0094-sequence-function.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
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Trent Nadeau via swift-evolution]

* What is your evaluation of the proposal?
+1. A very simple API change that fixes a footgun in the standard library.
* 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?
I followed the original thread and read the proposal.

On Tue, May 17, 2016 at 11:32 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0089: Renaming String.init(_: T)" begins now and runs
> through May 23. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.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
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

[Trent Nadeau via swift-evolution]

* What is your evaluation of the proposal?
+1
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes. It's more consistent, both with the rules for keywords vs. attributes
and with future improvements with property behaviors, as mentioned in the
proposal.
* 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?
"Wrapper" behaviors like this have been attributes in other languages I've
used, like Java.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Read the proposal.

On Tue, May 17, 2016 at 11:31 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0087: Rename lazy to @lazy" begins now and runs through
> May 23. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.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
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

[Trent Nadeau via swift-evolution]

* What is your evaluation of the proposal?
+1. Although I would prefer something like:

precedence(greaterThan: LogicalAnd)

to:

precedence(> LogicalAnd)

I think the latter is more difficult to read, and I just find the idea of
using an operator in an operator/precendencegroup definition strange.

* 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. Magical numbers are definitely not used elsewhere in the language.
* 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?
Read the proposal

On Tue, May 17, 2016 at 11:30 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0077: Improved operator declarations" begins now and
> runs through May 23. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.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
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional assignment operator

[Trent Nadeau via swift-evolution]

This same operator (except spelled as ??=) was up as a proposal and
rejected in February. See
http://thread.gmane.org/gmane.comp.lang.swift.evolution/7694.

On Thu, May 12, 2016 at 10:41 AM, Rod Brown via swift-evolution <
swift-evolution@swift.org> wrote:

> I’m tentatively supportive of this proposal. I definitely see the use case
> (assign only if not not nil).  Interested to hear the opinions of others
> here :)
>
> -Rod
>
>
> > On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via
> swift-evolution  wrote:
> >
> > Sorry if this has already been discussed, if so I couldn’t find it.
> >
> > I would like to propose to add to Swift an optional assignment operator
> ?=
> > I think this would nicely align with the other uses of ?, and avoid
> repetition in this case:
> >
> >   var value = 5
> >
> >   var possibleNewValue: Int? = nil
> >
> >   value = possibleNewValue ?? value
> >
> > It would be used like this:
> >
> >   value ?= possibleNewValue
> >
> > I’ve found quite a few cases in which this would be very useful to me.
> It is already possible to implement it, but having it defined in the
> standard library would define an standard, and prevent different semantics
> depending on who implements it.
> >
> >
> >   infix operator ?= {
> > associativity right
> >  precedence 90
> >  assignment
> >   }
> >
> >   func ?= (inout lhs: T, rhs: T?) {
> >   lhs = rhs ?? lhs
> >   }
> >
> >
> > Regards,
> > José Manuel Sanchez
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Trent Nadeau via swift-evolution]

   - What is your evaluation of the proposal?
   - All the +1s. This is more consistent with `where` clauses elsewhere in
  the language and is much more readable.
   - 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. Consistent and readability have been very important with Swift so
  far.
   - If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
   - Rust is similar.
   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?
   - Read the proposal and followed the discussions.


On Tue, May 10, 2016 at 2:51 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0081: Move where clause to end of declaration" begins
> now and runs through May 16. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.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
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Trent Nadeau via swift-evolution]

I disagree. According to both http://grammarist.com/usage/indexes-indices/
and http://www.worldwidewords.org/qa/qa-ind2.htm, "indices" is more common
in the English-speaking world (outside of parts of America and Canada) as
well as in technical contexts.

On Mon, Apr 11, 2016 at 12:29 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

> I love irregular plurals as much as the next grammar nerd, but I think
> it'd be better to use the more regular, but still correct, plural "indexes"
> rather than "indices".
>
> -Joe
>
> > On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hello Swift community,
> >
> > The review of "A New Model for Collections and Indices" begins now and
> runs through April 18th. The proposal is available here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.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, eventually, determine 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 you 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
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

[Trent Nadeau via swift-evolution]

You can probably use SwiftLint (https://github.com/realm/SwiftLint) and
create a new rule.

On Wed, Jan 6, 2016 at 9:17 AM, Honza Dvorsky via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> since you mentioned:
> > Individuals or teams that feel that explicit “self.” is beneficial for
> their own code bases can enforce such a coding convention via tooling with
> the status quo.
>
> Are there any existing tools that already do that? I was hoping for a
> compiler flag where one could disable implicit self to keep the code more
> readable in out-of-Xcode scenarios, is there one? Or does the above just
> mean that it's "theoretically" possible to enforce it, even though there's
> no existing tool for it yet?
>
> I remember this being discussed in the conversation about this proposal
> and I haven't seen anyone being *against* there being a compiler flag,
> assuming it's off by default. To push that forwards, would we have to
> create a new proposal or could that be taken as an action coming out of
> this one (considering how many people still were *for* required self, even
> if we were in a minority)?
>
> Grateful for any advice, thanks.
> Honza Dvorsky
>
> On Wed, Jan 6, 2016 at 8:08 AM Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> The review of SE-0009 "Require self for accessing instance members`" ran
>> from December 16–20, 2015. The proposal has been *rejected*.
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md
>>
>> This proposal spawned a massive, polarized discussion with 200+ messages
>> involving 80+ participants. We’re thrilled at the enthusiasm and thank all
>> who participated. There were many, many interesting points made, along with
>> experience reports from various Swift code bases, ideas to help mitigate
>> the concerns that motivated the proposal, and so on. Quantitatively, the
>> overall community assessment of the proposal was roughly 5:2 against
>> requiring “self.”.
>>
>> The core team agreed that this proposal is not the right direction for
>> Swift. There are a number of reasons for this decision:
>>
>> * Mandatory “self.” introduces a significant amount of verbosity that
>> does not justify itself with added clarity. While it is true that mandatory
>> “self.” may prevent a class of bugs, the cost of eliminating those bugs is
>> fairly high in terms of visual clutter, which goes against the generally
>> uncluttered feel of Swift. Paul Cantrell put it well in his review
>> 
>>  when
>> he said, “anything that is widely repeated becomes invisible.” Swift
>> aims to avoid such boilerplate and repetition in its design, a principle
>> also espoused by the Swift API Design Guidelines
>> .
>>
>> * The requirement to use “self.” within potentially-escaping closures is
>> a useful indicator of the potential for retain cycles that we don’t want to
>> lose. Additionally, developers can optionally use “self.” when they feel it
>> improves clarity (e.g., when similar operations are being performed on
>> several different instances, of which “self” is one).
>>
>> * The name-shadowing concerns behind the mandatory “self.” apply equally
>> well to anything found by unqualified name lookup, including names found in
>> the global scope. To call out members of types as requiring qualification
>> while global names do not (even when global names tend to be far more
>> numerous) feels inconsistent, but requiring qualification for everything
>> (e.g., “Swift.print”, “self.name”) exacerbates the problem of visual
>> clutter.
>>
>> * Individuals or teams that feel that explicit “self.” is beneficial for
>> their own code bases can enforce such a coding convention via tooling with
>> the status quo. If this proposal were accepted, those opposed to the
>> proposal would effectively have no recourse because the language itself
>> would be enforcing “self.”.
>>
>> Doug Gregor
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] STDLibs

[Trent Nadeau via swift-evolution]

Big +1 from me. Rust's docs do this well too across trait implementations.

On Wed, Jan 6, 2016 at 5:43 AM, James Campbell via swift-evolution <
swift-evolution@swift.org> wrote:

> Is there a way of improving the documentation and hosting it on Swift
> instead of Apple ?
>
> Currently the Array page lists all of the things the class directly
> implements but doesn't include any of the methods mixed in by protocol
> extensions (i.e all of the methods from CollectionType).
>
> With YardDoc for Ruby it does this, so you know exactly what methods a
> class has.
>
> This confused me to no end as some topics here suggest adding ways of
> dropping the first X elements and even I have implemented `shift` which I
> didn't know already exist albeit under another name.
>
> Would be great if we could improve these documents for the language in an
> open source way :)
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Empower String type with regular expression

[Trent Nadeau via swift-evolution]

Also https://github.com/rust-lang-nursery/regex, which is the process of
possibly being standardized either in the Rust stdlib or as a fully
supported crate (library). That crate is based on
https://github.com/google/re2 that is written in C++. Both could be used
for implementation ideas.

On Mon, Jan 4, 2016 at 9:52 AM, Vincent Esche via swift-evolution <
swift-evolution@swift.org> wrote:

> There is actually a Rust crate doing exactly that:
> https://github.com/jneem/regex-dfa
> Rust however has powerful compile-time macros, enabling this, which Swift
> doesn’t (yet?).
>
> On 04 Jan 2016, at 02:53, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1 on first-class regex support/pattern matching on regex patterns.
>
> There was a thread a while ago discussing compile-time code generation,
> and if I recall correctly one of the stated use cases was
> 'compiling'/'building' (don't know the real terminology) regex literals at
> compile-time. Is there a bigger overall vision for this sort of feature, or
> would it be better to just focus on better regex support?
>
> Best,
> Austin
>
> On Sun, Jan 3, 2016 at 1:35 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It is also probably worth burning first-class language support for regexes.  
>> This would allow specifying variable captures inline in the pattern, would 
>> allow flexible syntax for defining regexes, support powerful extensions to 
>> the base regex model (e.g. Perl 6 style), and would provide better 
>> compile-time checking and error recovery for mistakes.
>>
>> -Chris
>>
>> I know this is an old thread already, but this sure would be one of the
>> major breakout pieces of functionality.
>> If Swift had native regular expressions, without all the noise you see in
>> the Objective-C API that exposes ICU regular expressions, the adoption rate
>> would be huge.
>> If they were *truly* native, as in somebody sat down and built an NFA (or
>> one of the fancier approaches that mixes with DFA) state machine, Swift's
>> best-in-class Unicode support would and could result in amazing things.
>> It'd boost the scripting use of Swift tremendously and seal the deal as a
>> server side language.
>>
>>
>> Totally agreed.  switch on a string with a bunch of regexes being matched
>> should turn into a parallel state machine, just like a lexer :-)
>>
>> -Chris
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

[Trent Nadeau via swift-evolution]

Speaking of release cadence, do you think that Swift could transition to
the release train model (i.e., staged release, beta, and nightly) once
source and ABI compatibility are both established? That would allow a
quicker cadence and more testing of new library and language features. It's
seems to be working well with Rust so far, at least.

On Fri, Jan 1, 2016 at 3:46 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Under what criteria should we propose moving items into the standard
> library and out from the standard library into Swift Foundation? Or will
> these things eventually merge and become one grand unified module sometime
> in the distant future?
>
> Hi Erica,
>
> I don’t see any specific reason to merge the stdlib and Foundation
> together - it seems like Foundation depending on the swift stdlib is proper
> layering.  Lets look at the mission of both of these libraries:
>
> For the Swift standard library, we want it to stay focused on the
> lowest-level “language support” primitives that includes things like Int,
> Array, Dictionary, OptionSet and the stuff they depend on (sequences etc).
> Even though they are implemented in the stdlib, I consider to be part of
> the the language.  While we may elect to allow some minor scope creep, this
> will be carefully scrutinized and needs to be strongly justified.
>
> For Foundation, there may be differing short-term and long-term answers
> here.  In the short-term, the corelibs projects have a very specific focus,
> which is to enable cross-platform Swift development by making common
> Foundation APIs available on other platforms.  This is a pretty huge
> project, so it is important that we keep focused on making this happen,
> even though folks have the natural inclination to do “new” things as well.
>
> In this short term, I see SwiftPM as a great solution to avoid having to
> cram “everything interesting” into the standard library or Foundation.
> Once SwiftPM is ready, there should be very little downside to something
> being a package hosted on github or elsewhere.
>
>
> In the longer term, we’ll have to see what happens, and make a decision
> that makes sense given the direction the project takes.  We may decide to
> start adding new functionality to Foundation that doesn’t exist on Apple
> platforms yet (with the understanding that they will adopt it as well).  We
> may decide to “standardize” new corelibs from existing popular packages, if
> they are outside of the scope of Foundation (totally random example:
> perhaps a web templating framework).
>
> Putting something into the standard Swift distribution (instead of it
> being an independent package) comes with pros and cons.  On the positive
> side, we want an official Swift release (e.g. "Swift 3.0”) to provide a
> consistent set of APIs out of the box that are guaranteed to be there.
> Getting your cool thing into the Swift distro guarantees that it will be
> available everywhere.  On the downside, this is a bad way to go for rapidly
> evolving APIs in multiple ways: first, Swift has relatively infrequent
> updates (e.g. twice a year at current cadence) so it will take a long time
> to get changes out.  Second, *changing* an API included in the Swift
> distribution will be comparatively hard.  Instead of bumping the major
> version number of a package, it will have to go through a (TBD) lengthy
> deprecation process that will likely span multiple years.
>
> In any case, we’ll figure it out as we go.  We don’t have all the answers,
> and we’re learning too.
>
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Scoped resources (like C# using statement)

[Trent Nadeau via swift-evolution]

# Introduction

Add a new `Scoped` protocol and enhance the do statement to automatically
call enter/exit actions on resources.

# Motivation

Resources (e.g., locks, files, sockets, etc.) often need to be scoped to a
block, where some action is taken at the start of the block and another is
required at the end. Examples include locking and unlocking a lock in a
critical section or closing a file at the end of a block.

Doing this manually is possible using `defer` statements among other
options, but this is error prone as a `defer` can be forgotten,
`lock`/`unlock` calls for two locks can be switched due to a typo, etc.
Having a dedicated language construct for this common case makes it easier
to read and write while making code shorter and clearer.

# Language Survey

At least three major languages have widely used statements for this use
case.

## C#

C# has the `using` statement and the associated `IDisposable` interface.

```csharp
using (StreamReader sr = new StreamReader(filename)) {
txt = sr.ReadToEnd();
}
```

C#'s solution only handles close/exit actions via the
`IDisposable.Dispose()` method and so cannot easily be used with items such
as locks; however, C# has the additional `lock` statement for that use case.

## Java

Java has try-with-resources and the associated `AutoCloseable` interface.

```java
try (BufferedReader br = new BufferedReader(new FileReader(path))) {
return br.readLine();
}
```

Java's solution only handles close/exit actions via the
`AutoCloseable.close()` method and so cannot easily be used with items such
as locks; however, Java has the additional `synchronized` statement for
that use case.

## Python

Python has with `with` statement and the associated `__enter__` and
`__exit__` special methods that classes may implement to become a "context
manager".

```python
with lock, open(path) as my_file:
contents = my_file.read()
# use contents
```

Python's solution handles both enter and exit actions and so this one
construct is usable for locks as well as resources like sockets and files.

# Proposed Solution

We add a new protocol called `Scoped` to the standard library. Types for
resources that have enter/exit actions will be extended to add conformance
to this protocol.

The `do` statement will be extended to allow a new `using `
"suffix".

# Detailed Design

The `Scoped` protocol shall be as follows:

```swift
public protocol Scoped {
func enterScope()
func exitScope()
}
```

The compiler statement will accept a new form for resources. For example,

```swift
do using lock, let file = try getFileHandle() {
// statements
}
```

As can be seen in the example above, the resources can be bindings that
already exist (like `lock`) or can be new bindings. Bindings created with
`do using` are not available outside of the scope of the `do using`. Only
types conforming to `Scoped` may be using with `do using`. Use of
non-conforming types will result in a compiler error.

The above example would be syntactic sugar for the following:

```swift
do {
lock.enterScope()
defer { lock.exitScope() }

let file = try getFileHandle()
file.enterScope()
defer { file.exitScope() }

// statements
}
```

# Framework Changes / Examples

As an example of some real-world classes that would be useful with
`Scoped`, from Foundation:

```swift
// Would be nice to extend the NSLocking protocol instead, but that's not
supported yet.
extension NSLock: Scoped {
func enterScope() {
self.lock()
}

func exitScope() {
self.unlock()
}
}

extension NSFileHandle: Scoped {
func enterScope() {}

func exitScope() {
self.closeFile()
}
}
```

# Questions and Concerns
 * Bikeshedding protocol naming and scoping syntax
 * Should the enter and exit actions be allowed to throw errors?

-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

[Trent Nadeau via swift-evolution]

I disagree that `do using` would be useless for resources. Essentially no
Cocoa resource classes have a `deinit`. NSFileHandle, NSStream, etc.
require a close-like call to free the underlying resource. Also, per the
Swift documentation about deinitialization:

"Typically you don’t need to perform manual clean-up when your
instances are deallocated. However, when you are working with your own
resources, you might need to perform some additional clean-up yourself. For
example, if you create a custom class to open a file and write some data to
it, you might need to close the file before the class instance is
deallocated."

On Wed, Dec 30, 2015 at 1:19 AM, Félix Cloutier <felix...@yahoo.ca> wrote:

> My understanding is that you suggest using the "do using" statement for
> two purposes:
>
>
>1. to deterministically free resources (files, sockets);
>2. to create a scope with a guarantee about something (locks).
>
>
> The first purpose is very relevant for garbage-collected languages because
> the GC generally only monitors memory pressure to decide when to run, and
> so the GC won't budge if you're running out of file descriptors even if
> some could be reclaimed. However, Swift is not garbage-collected and
> resources are already reclaimed deterministically. If you create a Swift
> object that represents a file descriptor and don't allow references to
> escape the function, the object will be destroyed (and its resources
> reclaimed) at the latest when the function returns. In my opinion, this
> makes a "do using" statement useless for resource management.
>
> For scopes with guarantees, as Chris said, the most common pattern is to
> have a function that accepts a closure. I've seen some pretty serious
> nesting with `if let` (which are one very frequent case of scopes with
> guarantees), but other than that, I don't see lots of nesting and I've been
> pretty happy with what the language can do so far. The only thing I can
> complain about is that you can't use break/continue with the current setup.
>
> I see the discrepancy between objects, but I would say that any
> scope-based solution will often be just as hard to discover as the current
> solutions. `do using AutoreleasePool() { ... }` isn't an improvement over
> `autoreleasepool { ... }`.
>
> It's better for the lock case, but only if you agree that `do using` is
> useless for resource management. Otherwise, if your mutex itself benefits
> from being scoped, `do using lock` is probably creating/deleting a mutex,
> and you'd need to use `do using Lock(mutex) { ... }` to actually lock it
> (like with C++ mutex/lock objects), which is as discoverable as `mutex.lock
> { ... }`.
>
> Félix
>
> Le 29 déc. 2015 à 23:24:53, Trent Nadeau via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> While useful, that pattern doesn't seem to compose well. What if you need
> two locks? Would that be:
>
> lock1.withThisLockHeld {
> lock2.withThisLockHeld {
> // statements
> }
> }
>
> If so, it seems like it has the "pyramid of doom" issue that prompted
> allowing `if let` to have multiple bindings.
>
> In addition to the possible indentation and vertical space issue, you need
> to look up if and how each resource type does this. I believe this is a
> general enough pattern that it deserves language support. I think an
> analogy to the current situation would be if each collection type had its
> own way to iterate (Array.forEach, Set.withEachElement, etc.) instead of
> having for-in.
>
> On Tue, Dec 29, 2015 at 11:15 PM, Chris Lattner <clatt...@apple.com>
> wrote:
>
>> On Dec 29, 2015, at 8:02 PM, Trent Nadeau via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > Doing this manually is possible using `defer` statements among other
>> options, but this is error prone as a `defer` can be forgotten,
>> `lock`/`unlock` calls for two locks can be switched due to a typo, etc.
>> Having a dedicated language construct for this common case makes it easier
>> to read and write while making code shorter and clearer.
>> >
>> > ```swift
>> > do {
>> > lock.enterScope()
>> > defer { lock.exitScope() }
>> >
>> > let file = try getFileHandle()
>> > file.enterScope()
>> > defer { file.exitScope() }
>> >
>> > // statements
>> > }
>>
>> We have another pattern that types can use, which is:
>>
>> lock.withThisLockHeld {
>>   … stuff ...
>> }
>>
>> This can be done today with trailing closures.  Other examples of this
>> are “autoreleasepool” and withUnsafePointer (for other reasons).
>>
>> -Chris
>>
>>
>
>
> --
> Trent Nadeau
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution