Re: [swift-evolution] [Discussion] Simplifying case syntax

I agree that the ambiguity created by moving `let` outside the local binding context is problematic. I alway place `let` immediately alongside the binding for this reason. In design 2 do you disallow matching a value using an existing name? If so, how do users match values bound to an

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 12:44 PM, Dave Abrahams wrote: > > > on Tue Feb 28 2017, Karl Wagner wrote: > >>> On 28 Feb 2017, at 18:00, Matthew Johnson wrote: >>> >>> On Feb 28, 2017, at 10:44 AM, Daniel Leping >

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 12:27 PM, Tino Heth via swift-evolution > wrote: > >> I disagree with that, it works if you only have a single function parameter >> type that throws an error, but if there are more than one inferring the type >> won’t be possible anymore:

Re: [swift-evolution] [Pitch] Typed throws

>> >> Whether to wrap or not is a judgment call. >> >> If the purpose of your library is to simply provide a cleaner experience for >> a system API that is a stable dependency that will not change. Users might >> expect to have the errors from the system

Re: [swift-evolution] [Pitch] Typed throws

"I don’t know/can’t easily communicate which errors this function throws”. >>>> Really, it is a documentation problem; it's too onerous to document every >>>> individual throwing function, even with our very pretty markdown-like >>>> syntax. I’m just

Re: [swift-evolution] [Pitch] Typed throws

ully leverage > it. > > Everyone wins! > > Cheers, > Z > > P.S. Stack traces in errors would be awesome. > >> On Feb 28, 2017, at 9:00 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org&g

Re: [swift-evolution] 'T != Type' in where clause

> On Feb 28, 2017, at 11:33 AM, Joe Groff wrote: > >> >> On Feb 28, 2017, at 9:23 AM, Matthew Johnson wrote: >> >> >>> On Feb 28, 2017, at 11:04 AM, Joe Groff via swift-evolution >>> wrote: >>> >>> On Feb 27,

Re: [swift-evolution] 'T != Type' in where clause

> On Feb 28, 2017, at 11:04 AM, Joe Groff via swift-evolution > wrote: > > >> On Feb 27, 2017, at 4:34 PM, Rex Fenley via swift-evolution >> wrote: >> >> I often find myself running into situations where I'll receive "Ambiguous >> use

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 11:08 AM, Vladimir.S <sva...@gmail.com> wrote: > > On 28.02.2017 19:48, Matthew Johnson wrote: >> >>> On Feb 28, 2017, at 6:47 AM, Vladimir.S <sva...@gmail.com> wrote: >>> >>> On 28.02.2017 0:40, Matthew Johnson via sw

Re: [swift-evolution] [Pitch] Typed throws

gt; > In other cases you might have dependencies that are considered implementation > details. In that case if you don’t wrap the errors you’re doing users a > disservice by giving them an unstable interface for error handling. Changing > out your dependency that is s

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 6:47 AM, Vladimir.S <sva...@gmail.com> wrote: > > On 28.02.2017 0:40, Matthew Johnson via swift-evolution wrote: >> >>> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution >>> <swift-evolution@swift.org <mailto:swi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 28, 2017, at 10:39 AM, Joe Groff wrote: > > >> On Feb 27, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> Having watched this conversation from the sidelines, I just wanted to chime >> in from a more distant view: >> >>

Re: [swift-evolution] [Pitch] Typed throws

ntation detail becomes a breaking change. > > On Tue, 28 Feb 2017 at 8:29 Karl Wagner <razie...@gmail.com > <mailto:razie...@gmail.com>> wrote: >> On 28 Feb 2017, at 02:43, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolut

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 12:29 AM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 28 Feb 2017, at 02:43, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >&g

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 11:04 PM, David Waite > wrote: > > >> On Feb 27, 2017, at 2:08 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 9:53 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > > > > -- > Brent Royal-Gordon > Sent from my iPhone >> On Feb 27, 2017, at 10:39 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

that this *requires* subtyping, and it does not allow the pattern to be accessed on Foo. One can even imaging syntax allowing the pattern to be accessible on `Foo` using a name `bar`: extension Foo { pattern bar = // syntax which sets up a structural match of Bar values inside the parens when use

Re: [swift-evolution] [Pitch] Typed throws

Sent from my iPad > On Feb 27, 2017, at 8:21 PM, Dave Abrahams wrote: > > >> on Mon Feb 27 2017, Matthew Johnson wrote: >> >> If you don't believe typed errors will improve your code or if you >> just don't want to deal with typed errors, just don't use them! > > As

Re: [swift-evolution] [Pitch] Typed throws

if you just don't want to deal with typed errors, just don't use them! You will be able to continue using untyped throws just as you do today. You can even do this if you use libraries that throw typed errors. > >> On Tue, 28 Feb 2017 at 1:12 Matthew Johnson via swift-evolution

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 26, 2017, at 10:47 PM, Jonathan Hull wrote: > >> >> On Feb 25, 2017, at 2:41 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 25, 2017, at 4:01 PM, Jonathan Hull >> >

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 5:01 PM, Dave Abrahams wrote: > > > on Mon Feb 27 2017, Matthew Johnson wrote: > >>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams wrote: >>> >>> >>> I'm sorry, I don't see any substantive difference, based on what you've >>>

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 4:44 PM, Zach Waldowski via swift-evolution > wrote: > > On Mon, Feb 27, 2017, at 04:05 PM, Daniel Leping via swift-evolution wrote: >> David, IMHO, all you say is absolutely true and typed throws might work >> well, but in theoretic idealistic

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 4:20 PM, Dave Abrahams wrote: > > > on Mon Feb 27 2017, Matthew Johnson > wrote: > >>> On Feb 27, 2017, at 10:48 AM, Dave Abrahams wrote: >>> >>> >>> on Mon Feb 27 2017, Matthew Johnson

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Feb 27 2017, Joe Groff wrote: > >>> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >>> >>> Before I start revising this proposal, there are a couple of open

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 3:34 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 27, 2017, at 4:19 AM, Daniel Leping via swift-evolution >> > wrote: >> >> >> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution > wrote: > > IMHO, there are two kinds of responses to errors - a specific response, and a > general one. Only the calling code knows how it will deal with errors, so a > “typed throws” is the function

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution > wrote: > > IMHO, there are two kinds of responses to errors - a specific response, and a > general one. Only the calling code knows how it will deal with errors, so a > “typed throws” is the function

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 12:46 PM, Joe Groff wrote: > > >> On Feb 27, 2017, at 10:39 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution >>> wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Sent from my iPad > On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >> >> Before I start revising this proposal, there are a couple of open questions >> I’d like to

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 26, 2017, at 10:58 AM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Feb 25, 2017, at 5:27 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The name that has usually be

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 25, 2017, at 6:07 PM, Daniel Duan via swift-evolution > wrote: > > Not sure which “this” you were referring to. The anonymous case part is > something that I consider out-of-scope for this proposal as well. It came up > during review and is posted as one

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 4:23 PM, Jonathan Hull <jh...@gbis.com> wrote: > > >> On Feb 25, 2017, at 1:43 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On F

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 4:01 PM, Jonathan Hull wrote: > >> >> On Feb 25, 2017, at 1:19 PM, Matthew Johnson > > wrote: >>> On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution > wrote: > >> … >> Additionally, the design allows ‘final’ to take any one of those visibility >> levels as a parameter, to indicate that the type should be treated as >> ‘final’ at and above the

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution > wrote: > > +1000 > > This is the best of the proposals I have seen. I think it works by itself as > a complete proposal, but since we are talking "comprehensive rethink", there

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 25, 2017, at 12:12 AM, David Waite via swift-evolution > wrote: > >>> On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution >>> wrote: >> > >> >> The prevailing view from recent

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

ot intended for _ to be an ordinary identifier, but as a way of >>>> spelling the empty case name. Ambiguous cases, not distinguished by either >>>> full name or payload type, would be errors. How to construct anonymous >>>> cases? I guess it would be MyEnum

Re: [swift-evolution] [Draft] scope-based submodules

> On Feb 24, 2017, at 4:57 PM, David Hart <da...@hartbit.com> wrote: > >> >> On 24 Feb 2017, at 20:34, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I didn't expect su

Re: [swift-evolution] [Draft] scope-based submodules

e the file as-is because those ancestors would not exist in the context you placed it in your module (unless you want to be evil and couple your module structure to that of a copy-and-paste dependency). > > > On 24.02.2017 22:34, Matthew Johnson via swift-evolution wrote: >> I didn't expect

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 23, 2017, at 12:52 PM, Anton Zhilin via swift-evolution > wrote: > > +1 to foo(:) version. > I can easily see placeholder arguments as a sugary syntax for closures: > This shorthand has been explicitly rejected several times in favor of the $ argument

[swift-evolution] [Draft] scope-based submodules

I didn't expect submodules to be a part of the Swift 4 discussion. When it came up I was pleasantly surprised. I have been thinking about the design of a submodule system for quite a while but was planning to wait until it was clearly in scope to draft a proposal. Now that the topic has been

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 24, 2017, at 11:00 AM, Joe Groff via swift-evolution > wrote: > > >> On Feb 23, 2017, at 10:36 PM, Russ Bishop > > wrote: >> >> >>> On Feb 21, 2017, at 8:18 AM, Joe Groff >>

Re: [swift-evolution] Analysis of existing scopes

> On Feb 23, 2017, at 1:34 PM, Joanna Carter > wrote: > > >> Le 23 févr. 2017 à 14:59, Matthew Johnson a écrit : >> >> The rationale for this is that it allows you to explore the eventual design >> of a type without exposing it. When

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

re to catch all types that may thrown in the `do` block. > > And if 'old' syntax (i.e. foo() throws {...}) without specifying list of > exception classes will be allowed? Yes > >> >>> The thread is really long and I personally was not able to follow it >>&

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

r during propagation. >> >>> The thread is really long and I personally was not able to follow it >>> from the beginning(so I believe the answer can be helpful for others >>> like me). Thank you(really). >>> >>> On 23.02.2017 20:09, Matthew Johns

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 24, 2017, at 12:06 PM, David Hart <da...@hartbit.com> wrote: > > Sending to mailing list: > > On 23 Feb 2017, at 01:37, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >

Re: [swift-evolution] [Proposal] Guarded self in closures

the scope of the user code in the closure >>>>>> // it is used by libraries to detect when they can safely >>>>>> discard their reference to the closure because it has become a no-op >>>>>> // context is a super secret compiler r

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 12:30 PM, Anton Zhilin wrote: > > 2017-02-23 21:01 GMT+03:00 Matthew Johnson >: > I don’t understand what you mean here. > > I was a bit confused. Thanks to your clarification, I discovered

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

g argument. `Either<E, F>` is not a subtype of `E` or `F`. The only way to propagate both errors without resorting to simply specifying `Error` as your error type is to catch them and wrap them (at least until we have a built-in mechanism for implicit error conversions). > > - Karl

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

using a sum type. // In that case we might have an error type such as Either<AnUninhabitableType, AnotherUninhabitableType>. // Because all cases of the sum type have an associated value with an uninhabitable the sum type is as well. try rethrower(f: nothrow, g: ithrow) > On Feb 22, 2017, at 6:3

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

er can be helpful for others like me). > Thank you(really). > > On 23.02.2017 20:09, Matthew Johnson via swift-evolution wrote: >> >>> On Feb 23, 2017, at 10:58 AM, Anton Zhilin <antonyzhi...@gmail.com >>> <mailto:antonyzhi...@gmail.com>> wrote: &g

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 11:41 AM, Anton Zhilin wrote: > > 2017-02-23 20:09 GMT+03:00 Matthew Johnson >: > >> On Feb 23, 2017, at 10:58 AM, Anton Zhilin > >

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

problem with that at all. As I point out in the analysis below, rethrowing functions are allowed to throw any error they want. They are only limited by *where* they may throw. > > 2017-02-23 3:37 GMT+03:00 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <ma

Re: [swift-evolution] Analysis of existing scopes

> On Feb 23, 2017, at 4:47 AM, Joanna Carter via swift-evolution > wrote: > > And now I find, what I consider to be, a very peculiar anomaly in method > visibility. > > private class PrivateBaseClass > { > internal func internalFunc() { } > > public func

Re: [swift-evolution] [Proposal] Guarded self in closures

>>>>>> closure is a strong reference. I wouldn't want `DispatchQueue.async` to >>>>>> take a guarded closure. That API doesn’t contain any semantic content >>>>>> around *why* you dispatched async. It’s not a callback, but instead a >>&

Re: [swift-evolution] [Proposal] Guarded self in closures

ext: self) { (self, searchQuery) in >>>>> self.performSearch(query: searchQuery) >>>>> } >>>>> ``` >>>>> >>>>> This code neither requires an addition of language features nor contains >>>>> retain c

[swift-evolution] [Discussion] Analysis of the design of typed throws

# Analysis of the design of typed throws ## Problem There is a problem with how the proposal specifies `rethrows` for functions that take more than one throwing function. The proposal says that the rethrown type must be a common supertype of the type thrown by all of the functions it

Re: [swift-evolution] [Proposal] Guarded self in closures

nce. But it gives an opportunity to do things without explicit weak > references just as guarded closures do. It also adds an ability to avoid an > execution of pure (or just not bound to context) operations you depends on. > Deallocation of context will lead to cancellation of full chain

Re: [swift-evolution] [Proposal] Guarded self in closures

Sent from my iPad > On Feb 22, 2017, at 5:28 PM, David Hedbor wrote: > > > >> On Wed, Feb 22, 2017 at 3:09 PM, Matthew Johnson >> wrote: >> >>> On Feb 22, 2017, at 4:57 PM, David Hedbor wrote: >>> >>> >>> >>> On Wed,

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 22, 2017, at 4:57 PM, David Hedbor wrote: > > > > > On Wed, Feb 22, 2017 at 2:23 PM, Matthew Johnson > wrote: > >> On Feb 22, 2017, at 4:06 PM, David Hedbor >

Re: [swift-evolution] [Proposal] Guarded self in closures

It nudges them not to by offering to thread the context but it doesn’t do anything to prevent it. You can still create a strong reference (event to self) without specifying it in the capture list. I think there is a place for a language solution here. > >> On Feb 22, 2017, at 22:57,

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

ities. It isn’t clear to me > whether or not the core team views this as something they are willing to > consider for Swift 4 or not, but it is definitely not in the realm of > syntactic sugar so it has a better chance than `asCase?`. Joe, any thoughts > on whether it’s worth inves

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 22, 2017, at 4:06 PM, David Hedbor wrote: > > One more thing I'd like to add into the discussion is handling of optional > variables. My assumption is that if I have an optional variable in the outer > scope, it would remain optional in the inner scope, but the way

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 22, 2017, at 3:36 PM, David Hedbor via swift-evolution > wrote: > > I did read it, but I think I skimmed it a bit too fast. You're correct in > that it essentially solves the same problem using a different syntax (more > compact at that). I think when I

Re: [swift-evolution] [Draft] Guarded closures and `@guarded` arguments

is case. The good news is that this would still be valid code within a guarded closure because the new proposal allows you to override the guarded behavior using the capture list. > >> On 20 Feb 2017, at 18:01, Matthew Johnson via swift-evolution >> <swift-evolution@swi

Re: [swift-evolution] [Proposal] Guarded self in closures

Hi David, I just shared a draft proposal to introduce guarded closures last week: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html . I think you would find it very

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 22, 2017, at 12:30 PM, David Sweeris <daveswee...@mac.com> wrote: > > >> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I like this idea. I think you made the right choice of

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 22, 2017, at 8:32 AM, John McCall via swift-evolution > wrote: > > >> On Feb 21, 2017, at 11:50 PM, Chris Lattner wrote: >> >> On Feb 20, 2017, at 11:12 PM, John McCall wrote: As you know, I still think that

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

I like this idea. I think you made the right choice of syntax given the alternatives considered. To me `foo(_)` and `foo(:)` equally imply presence of an argument. The former looks like an anonymous (unnamed) argument and the latter includes the colon which only follows an argument. Between

Re: [swift-evolution] [Draft] Fix Private Access Levels

> On Feb 22, 2017, at 12:32 AM, David Hart wrote: > > >> On 21 Feb 2017, at 23:41, Xiaodi Wu > > wrote: >> >> Well-written as-is. >> >> Overall, my feedback is that solution 2 should not be on the table (though >> there

Re: [swift-evolution] [Proposal] Typed throws

> On Feb 22, 2017, at 7:10 AM, Anton Zhilin wrote: > > How about this: > > func bypassRethrows(_ f: () throws(E) -> ()) throws(E) { > if let e = (MyError() as Error) as? E { > throw e > } > } > I obviously can’t “test” this right now, but should work? >

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

It isn’t clear to me whether or not the core team views this as something they are willing to consider for Swift 4 or not, but it is definitely not in the realm of syntactic sugar so it has a better chance than `asCase?`. Joe, any thoughts on whether it’s worth investing time into a proposal or

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 22, 2017, at 2:04 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 21, 2017, at 11:11 PM, Jonathan Hull via swift-evolution >> wrote: >> >> There is one major use case which I see all of these proposals failing to

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 22, 2017, at 1:31 AM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 8:33 PM, Matthew Johnson wrote: >> >>> A submodule may not import any direct parent module (parent, grandparent, >>> etc.), but may import any other submodule

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 11:54 PM, Robert Widmann wrote: > > >> On Feb 22, 2017, at 12:41 AM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On Feb 21, 2017, at 11:09 PM, Robert Widmann

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sent from my iPad > On Feb 21, 2017, at 11:09 PM, Robert Widmann wrote: > > >>> On Feb 21, 2017, at 11:59 PM, Matthew Johnson >>> wrote: >>> >>> >>> On Feb 21, 2017, at 10:41 PM, Robert Widmann >>> wrote: >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:41 PM, Robert Widmann wrote: > > By API boundaries I mean both the one internal to MyModule.Foo and the one > defined by MyModule. Here “the API boundary” is explicitly about the > submodule MyModule.Foo, whose internal state may have been

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:29 PM, Robert Widmann wrote: > > This level of access, the “private to this submodule except to the select set > of interfaces I want to see it” level, is the equivalent of friend classes in > C++. I don’t consider leaving this out to be a

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:25 PM, Robert Widmann wrote: > > Good question! This behavior is actually the behavior that exists today. > For example, open a playground and type > > import Foundation.NSDebug > > let s : NSString = “" > > You’ll notice no matter which

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 20, 2017, at 7:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like. > > *** > > Any

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 7:56 PM, Robert Widmann via swift-evolution > wrote: > > Good Evening All, > > Jaden Geller and I have been considering a (sub)module system for Swift that > would complement the existing language but also provide sorely needed > modularity.

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:11 PM, Matthew Johnson wrote: > > >> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Feb 21, 2017, at 7:38 PM, Robert Widmann >>> wrote: >>> >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 21, 2017, at 7:38 PM, Robert Widmann wrote: >> >> Correct. Because, in dividing the submodule across an extension, you have >> placed what should

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:42 PM, Robert Widmann wrote: > > >> On Feb 21, 2017, at 10:36 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution >>>

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 21, 2017, at 9:38 PM, Michel Fortin wrote: > >> Le 21 févr. 2017 à 22:05, Matthew Johnson a écrit : >> Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : > e) Generic Containers: >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution > wrote: > >> >> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu > > wrote: >> >> On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 21, 2017, at 8:57 PM, Michel Fortin via swift-evolution > wrote: > > (this was accidentally sent off-list, reposting here a day later) And this was my reply. > >> Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : >> >>> e)

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

> On Feb 21, 2017, at 2:35 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Feb 21, 2017 at 6:56 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > O

Re: [swift-evolution] [Proposal] Typed throws

Sent from my iPhone > On Feb 20, 2017, at 5:51 PM, Anton Zhilin wrote: > > 2017-02-21 1:21 GMT+03:00 Matthew Johnson : >> >> Thanks for the links. I scanned through them somewhat quickly and didn’t >> see anything that specifically said

Re: [swift-evolution] [Draft] Fix Private Access Levels

Sent from my iPhone On Feb 21, 2017, at 9:18 AM, Brent Royal-Gordon wrote: >> On Feb 21, 2017, at 5:36 AM, Matthew Johnson wrote: >> >> This is true for lexical scoping, but I'd also like to see scoped be >> parameterized to take the name of

Re: [swift-evolution] [Draft] Fix Private Access Levels

Sent from my iPhone > On Feb 21, 2017, at 7:51 AM, Vladimir.S via swift-evolution > wrote: > > FWIW, I do think "Solution 2: Rename the scoped access level to scoped" is > the best solution. It has(like current 'private') a value of protecting (even > from

Re: [swift-evolution] [Draft] Fix Private Access Levels

Sent from my iPad > On Feb 21, 2017, at 5:45 AM, David Hart via swift-evolution > wrote: > > >>> On 21 Feb 2017, at 11:40, Brent Royal-Gordon wrote: >>> >>> On Feb 20, 2017, at 10:58 PM, David Hart via swift-evolution >>>

Re: [swift-evolution] [Draft] Fix Private Access Levels

Sent from my iPad On Feb 21, 2017, at 4:40 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Feb 20, 2017, at 10:58 PM, David Hart via swift-evolution >> wrote: >> >> The scoped keyword is a good choice not only because the

Re: [swift-evolution] [Draft] Fix Private Access Levels

Sent from my iPad > On Feb 21, 2017, at 1:47 AM, Rien via swift-evolution > wrote: > > I don’t know if you want to add this to the ‘criticism’ or not. > > 1) The information content added by “fileprivate” is questionable because of > the ‘soft default’: > > -

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad On Feb 21, 2017, at 5:18 AM, Dimitri Racordon wrote: >> Maybe we should try to collect what people want from submodules first. > > I’d like a simple method to group my sources files into some kind lexical > scope. Nothing more actually =D I

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad On Feb 21, 2017, at 4:01 AM, Brent Royal-Gordon wrote: >> On Feb 20, 2017, at 7:59 PM, Matthew Johnson wrote: >> >>> Any group of Swift files can be grouped together to form a submodule. >> >> It isn't clear to me how you

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

t 1:04 PM, Matthew Johnson <matt...@anandabits.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> On Feb 20, 2017, at 2:38 PM, Joe Groff <jgr...@apple.com> wrote: >>>>>>> >>>>>>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Thanks for bringing up submodules Robert. I agree it's a good time to discuss them. There seem to be two broad approaches to submodules. One is more of a physical / encapsulation based view and the other is more of a logical / namespace based view. This proposal falls into the latter

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad > On Feb 20, 2017, at 7:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like.

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 6:54 PM, Michel Fortin wrote: > >> >> Le 20 févr. 2017 à 18:02, Matthew Johnson a écrit : >> >> >>> On Feb 20, 2017, at 4:50 PM, Michel Fortin wrote: >>> Le 20 févr. 2017 à 14:45,

<    1   2   3   4   5   6   7   8   9   10   >