Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

I could (assuming I’m the David you’re referring to), though it will probably be towards the end of the week or early next week before I get a chance to get to it. -David > On Jan 4, 2016, at 1:03 PM, Drew Crawford wrote: > > The swift package manager is currently

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

a package name argument by supplying it with the magic package > "swift", for example. Changes to the language can be highly disruptive to all > Swift code, so that's why I think it warrants its own build configuration. > > David > >> On Dec 20, 2015, at 10:4

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

Seems like a good start for Swift developers that need to write some C code for their project. -David Sent from my iPhone > On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev > wrote: > > Happy 2016! > > I am working on an initial proposal for adding

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

+1. I think it brings a nice symmetry with the integer types and puts size classing in a more consistent place. And to be frank, I already typedef the intrinsic float/double types in my C code to f32/f64 for similar reasons. -David > On Jan 4, 2016, at 12:58 PM, Alex Johnson via

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 31, 2015, at 9:47 AM, Matthew Johnson via swift-evolution > wrote: > > No. This is addressed in the proposal and the lazy collections motivating > example I replied with last night. I don’t think it’s a good idea to require > this. Can you put your

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

+1 to Joe’s comment. > On Dec 30, 2015, at 10:31 AM, Joe Groff via swift-evolution > wrote: > > >> On Dec 30, 2015, at 10:26 AM, Chris Lattner > > wrote: >> >>> >>> On Dec 30, 2015, at 9:53 AM, Joe Groff via

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

Overall, I think the feature is important to have, but I don’t understand some of the aspects of the proposal. I also don’t think there is a real focus for clarity on the types of testing that are being supported here. The implication is that unit tests are what this is being targeted, but is

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

I’m just going to interject a few thoughts in here. > On Dec 21, 2015, at 6:36 AM, Matthew Johnson wrote: > > Hi David, > > (my paraphrase: pattern matching is great and solves more of my concerns than > I originally realized.) Awesome! > I would also like to

Re: [swift-evolution] Proposal: Support for commit comments

What you are talking about are source control hooks. They don’t belong in a language as a language is completely agnostic of a source control system, assuming on is even used. > On Dec 21, 2015, at 3:04 PM, Amir Michail via swift-evolution > wrote: > > >> On Dec

Re: [swift-evolution] Immutable Structures

I’m confused by your example below. Your move() function is equivalent to this: func move(position: Position) { var copy = position copy.x += 20 } Did you mean “var” there? (sidenote: var is being removed from the function call site) Structs are immutable. It’s only with a

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

> On Dec 18, 2015, at 7:03 AM, Félix Cloutier wrote: > > For this reason, I don't like to encourage throwing polymorphic types, and I > think that it's a misconception to pretend that having a single type in the > throws annotation ensures that the function throws a single

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

> On Dec 18, 2015, at 5:53 AM, Matthew Johnson wrote: > > David, > > Thank you for taking the time to continue working on a proposal for typed > throws. I agree that this feature is very desirable and appreciate the work > you’re doing to bring forward a proposal. I

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 3:34 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 18, 2015, at 3:24 PM, Kevin Ballard via swift-evolution >> > wrote: >> >> AFAIK there's no precedent today for

Re: [swift-evolution] [Proposal] function "return" optional keyword.

-1 for me. Closures gain a special syntax because of their use case, specifically inlining locally. Functions don’t get that. > On Dec 19, 2015, at 4:44 PM, Andrew Bennett via swift-evolution > wrote: > > +1 for consistency with closures > > On Sun, Dec 20, 2015 at

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 21, 2015, at 11:05 PM, Brent Royal-Gordon > wrote: > >>> The proposal already states that a memberwise initializer only includes >>> parameters for properties that are at least as visible as the initializer >>> itself. So if you can see the `s` and `i`

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 21, 2015, at 10:39 PM, Brent Royal-Gordon > wrote: > >> Also, I don’t think it generates good API signatures. Take this example: >> >> struct S { >> let s: String >> let i: Int >> >> // user declares: >> memberwise init() {} >> //

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

> On Dec 22, 2015, at 9:30 AM, Paul Cantrell via swift-evolution > wrote: > > Hmm, I wonder if #1 or #4 suggest any language changes to propose for this > list. Tangential to the topic at hand, but default values in tuples is something I’ve wanted for a while.

Re: [swift-evolution] Pitch: Deinit for structs

This is something I asked for before, then I realized it wouldn’t work. func helper(rs: ResourceHandle) {} let resource = ResourceHandle() helper(resource) result.doSomething() // error Another example: let x = Handle() do { let y = x } // resources are freed here as deinit is called // x

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> Additionally, we think we can get away with renaming "private" because most > current uses of "private" (file-scoped) declarations are within the same > (brace-bound) scope anyway; A quick look through my code bases verifies that this is true with my small sample of code. The only outliers

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

It would be nice to know the rationale behind the choice of the current syntax. I agree that these seem more natural: @warn_unused_result public func ~=(value: I, pattern: Range) -> Bool @warn_unused_result public func ~=(value: I.Bound, pattern: I) -> Bool I would not change from `~=` to

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

Along the lines of what Jordan is saying, I don't think there even is a such thing a unifying definition of "debug build". Even your definition for "my people" is a collection of build settings. The definition of "asserts can fire" is also problematic. Maybe if tied specifically to Swift's

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 25, 2016, at 9:15 AM, Jordan Rose via swift-evolution > wrote: > > >> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution >> > wrote: >> >>> >>> On Mar 24, 2016, at 5:13 PM, Brent

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I have types where I declare their members (some public, some private) and use extensions to provide the API implementations of protocols. These implementations use data that is not public to the type. A file-based access level is the only one that works for me. This is actually the common

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

The C99 spec changed the scoping rules to address the very issue you are asking about having any "real-world impact". Yes, the variable outside does matter. It's why you see some code like this, even with C++ because it used to not scope locally there too with all compilers: {for (int i= 0;

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 29, 2016, at 10:18 AM, Jordan Rose wrote: > > A good handful of people already enumerated several cases where file-based > scoping is useful, and I very much agree. Leaking helper operations across an > entire module just because they can't be lexically scoped,

Re: [swift-evolution] [Discussion] Enforce argument labels on tuples

This is similar to another concern I raised with functions and being able to essentially erase the function argument names and apply two different named parameters just because their types match. It seems reasonable to me that you can go from (x: Int, y: Int) => (Int, Int). However, going from

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> On Apr 26, 2016, at 1:31 PM, Chris Lattner <clatt...@apple.com> wrote: > > >> On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> What is your

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

es in closure expressions. >>> Parentheses are visual clutter if not really needed and for a closure >>> expression there is no need for parentheses as the parameter list is >>> already nicely bracketed by `{ ... in`. >>> Actually I would argue that paren

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

What is your evaluation of the proposal? +1. Commas are already redundant syntax to provide additional clarity over spaces in nearly all use cases. Being strict on this provides no material benefit. On the other hand, being super strict about this does have measurable, real-world impacts. I can

Re: [swift-evolution] SE-0084 spinoff: Newlines as item separators

Agreed with all of these points. I’d personally like to see the ‘,’ disappear altogether, but not piece-wise like this. -David > On May 18, 2016, at 1:28 AM, David Hart via swift-evolution > wrote: > > -1 I see one big downside. Contrary to statements, which

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

Agreed. -1. Sent from my iPhone > On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution > wrote: > > -1 from me. We should not introduce two equivalent spellings for the same > thing. > > (Yes, there are sometimes multiple ways to accomplish something, but

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

Hmm... I don't think this is clearer: let fn: (Int) -> (Int) -> Int I think it's much less readable and really, the () are syntactically redundant: the -> is really what distinguishes this as a function. Also, this would look like a error now: let fn: (Int) -> () Did the user mean

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 15, 2016, at 1:07 PM, Chris Lattner wrote: > > >> On Apr 15, 2016, at 11:27 AM, David Owens II > > wrote: >> >> Hmm... I don't think this is clearer: >> >> let fn: (Int) -> (Int) -> Int >> >> I think it's much less

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 19, 2016, at 7:49 AM, Erica Sadun via swift-evolution > wrote: > > >> On Apr 18, 2016, at 4:31 PM, Dave Abrahams via swift-evolution >> > wrote: >> >> >> on Fri Apr 15 2016, Brent Royal-Gordon

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

I have a different read of the proposal I guess... I actually find that this: (Int, Int) -> (Int, Int) Naturally reads take a single pair (e.g. tuple) of (Int, Int) and return a single pair of (Int, Int) This actually looks and feels like the right implementation to me: let tx: (Int, Int) ->

Re: [swift-evolution] [Discussion] Enforce argument labels on tuples

> On Apr 20, 2016, at 4:47 PM, Chris Lattner <clatt...@apple.com> wrote: > > On Apr 20, 2016, at 12:31 PM, David Owens II via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> This is similar to another concern I

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

What is your evaluation of the proposal? I think the philosophical direction of the proposal is good, though I still don’t like the actual implementation details. There are two concepts here: the ability to subclass the ability to override members Having both of these concepts annotated with

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 8:52 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Jul 27, 2016 at 10:30 PM, David Owens II via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > On Jul 27, 2016, at 7

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

t; On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution >> <swift-evolution@swift.org> wrote: >> I brought this up in review, but there seems to be a serious testability >> problem here because of how special @testable is. >> >> // This class i

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

I brought this up in review, but there seems to be a serious testability problem here because of how special @testable is. // This class is not subclassable outside of ModuleA. public class NonSubclassableParentClass { // This method is not overridable outside of ModuleA. public func

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 7:18 PM, John McCall <rjmcc...@apple.com> wrote: > > >> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Yes, it’s per file. It’s also added in the initial temp

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

. It seems this design is acceptable and by-design. -David > On Jul 27, 2016, at 6:36 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution >> <swift-evolution@swift.org> wrote: &

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

But does it already surpass the limits? > • There is a bandwidth limit of 100k monthly page views, equivalent to > our Standard hosting plan. > • If you exceed our bandwidth limit – which is very unlikely, unless > your project is enormous – you have two options: > •

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution > wrote: > > I still think it is worth doing a test to see how everyone likes it: Even if it is better, someone if going to have to either maintain the server and install of discourse _or_ pay

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

> On Jul 19, 2016, at 11:37 AM, L. Mihalkovic via swift-evolution > wrote: > > > > Regards > (From mobile) > > On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution > > wrote: > >> >>

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

> I believe no programmer, least of which myself, can be trusted with the > decision to reliably decide ahead of time that this or that class cannot or > will not be subclassed. > So strong -1 for me. I just don’t get this line of reasoning. Can a programmer be trusted with determining if a

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

> On Jul 9, 2016, at 9:08 AM, Austin Zheng via swift-evolution > wrote: > >> On 9 Jul 2016, at 00:53, Jon Shier > > wrote: >> >>> While I can see why removing the labels from the type system would be a >>> good idea, I

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

Sent from my iPhone > On Jul 10, 2016, at 11:24 PM, Austin Zheng wrote: > > >> On Jul 10, 2016, at 11:16 PM, David Owens II wrote: >> >> Unless you really want to try and get parameter name syntax changed to match >> your example: >> >> func

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

> On Jul 10, 2016, at 10:53 PM, Austin Zheng wrote: > > >> On Jul 10, 2016, at 10:30 PM, David Owens II > > wrote: I wish the core team or the author of the proposal came to this thread and engaged again with

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

> On Jul 10, 2016, at 11:09 PM, Mark Lacey wrote: > > In the meantime one option here would be to define a nested function that > invokes the callback. It results in boilerplate, which is unfortunate, but > would work: > > func doResize > ( > image: Image, >

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

And you go back to a single point of failure, requirement to host and maintain a server, or to pay them to host it for you. Discourse is probably the best alternative, but it still has drawbacks as well. -David > On Aug 2, 2016, at 11:28 AM, Shawn Erickson via swift-evolution >

Re: [swift-evolution] #pragma

The context of comments should clearly not be ignored by IDEs. If you did that, the entire feature set of doc comments would go away. -David Sent from my iPhone > On Sep 4, 2016, at 5:15 PM, Félix Cloutier via swift-evolution > wrote: > > There is a *lot* more to