Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

My thoughts on this proposal: 1. I agree with some of the other comments that I would prefer the version file be adjacent to "Package.swift". When the Packages directory isn't being checked in, I really would like to think of it as an "implementation detail" and not embed functionality inside

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

Sorry for how informal this review is; I'm generally in favor of it, although I would recommend that imported C functions are by default tagged with @discardableResult. Félix > Le 17 mars 2016 à 07:33:10, Tino Heth via swift-evolution > a écrit : > >> Perhaps we

[swift-evolution] [Accepted] SE-0046: Establish consistent label behavior across all parameters including first labels

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md The review of SE-0046 "Establish consistent label behavior across all parameters including first labels" ran from Mar 11…15, 2016. The proposal has been *accepted*: There was uniformly strongly

[swift-evolution] SE-0047

https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md I really like the way Swift currently works in this regard. Return values can be and are routinely ignored and that is ok

Re: [swift-evolution] Two-for-Tuesday: Resettable Properties

> SE-0030 initially included "out-of-band operations" (such as reset > methods with syntax like `foo.name.[resettable].reset()`) but > ultimately removed them due to complexities involved: > >> It is useful to add out-of-band operations to a property that aren't normal >> members of its formal

Re: [swift-evolution] [Pitch] Limit Implicit Capture

> On Mar 16, 2016, at 11:11, Joe Groff wrote: > > >> On Mar 16, 2016, at 11:09 AM, Jordan Rose via swift-evolution >> > wrote: >> >> It's worth noting that—for better or for worse—explicit capture has >>

Re: [swift-evolution] [Proposal] Add Binary Search functions to SequenceType

Nate - I suppose that's really the crux of the matter here. I agree a binary predicate solves the problem, but is that the route we want to go? I think it makes sense, but is there a reason we should stick with a unary predicate? For some reason I had it in my mind that there was mention of

Re: [swift-evolution] [Draft] Abolish IUO type

> (Come to think of it, is there a cost to converting between `T?` and `T!`, or > do they get optimized into the same thing?) I can't imagine there would be. @autounwrapped (or whatever) is a purely compile-time thing which tells the compiler to automatically insert a `!` operator if it will

Re: [swift-evolution] [Draft] Abolish IUO type

> It seems like this unnecessarily complicates the surface model of Swift. To > me, it seems like there is no advantage to having two ways to spell this. @autounwrapped let foo = functionReturningOptional() I *believe* that, without the `@autounwrapped` attribute, there's no way to go

Re: [swift-evolution] [Draft] Abolish IUO type

If you know something’s non-null, is there any advantage to keeping it in an implicitly-unwrapped optional instead of a normal non-optional type? Charles > On Mar 17, 2016, at 11:08 PM, Step C via swift-evolution > wrote: > > That just forces the unwrap to the base

Re: [swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

> On Mar 16, 2016, at 9:59 AM, Erica Sadun wrote: > >> >> On Mar 16, 2016, at 10:41 AM, Joe Groff > > wrote: >> >>> >>> On Mar 16, 2016, at 8:24 AM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [proposal] Generic type aliases

> On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution > wrote: > > This is a minimal proposal for introducing type aliases into Swift, and > intentionally chooses to keep them limited to being “aliases”. As such, > additional constraints are not allowed

Re: [swift-evolution] [proposal] Generic type aliases

On Mar 16, 2016, at 4:56 PM, Joe Groff wrote: >> We shouldn’t infer it the requirement. >> >> Rationale: I see this as analogous (in two ways) to why we don’t infer >> hashability of T in: >> >> func f(…) { >> let x : Dictionary >> } > > However, we do infer the

Re: [swift-evolution] Proposal to remove semicolons

Sorry, that was a terrible example which doesn’t work (typing code into an email at this point in the afternoon isn’t a good idea it seems!) I made a simple example project to show the issue. Two methods in the view controller, different behaviour depending on the trailing semicolon:

Re: [swift-evolution] Proposal to remove semicolons

This seems like unexpected behavior and if the user intended it to return a value, it should be moved to the return line. The compiler is smart enough to warn about it and the warning goes away when you move the line up. If there is an issue where they need something that spans multiple lines

Re: [swift-evolution] [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

It seems to me there are two options when you have overlapping protocol requirements: 1. Declare one extension that satisfies the group of overlapping protocols. In this case, perhaps A, B, and C. 2. Break up the extensions per protocol. In this case you have the problem that you have to pick

Re: [swift-evolution] [Pitch] Remove bit shift traps

Since the trap represents a possible mistake, I think it’s better to keep it. However, we could have &<< and &>> operators that return the suggested defaults? This would also be more explicit that there is extra behaviour on the operation (so it may be a tiny bit slower than << and >>). > On

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> The main thing is just that UnsafeBufferPointer doesn't act like a pointer; > it acts like a buffer, and a zero-element buffer turns out to be a perfectly > useful degenerate case (and something that will happen anyway for an array > with capacity reserved but no elements). In the cases where

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

addendum: my example was discussed at https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000488.html ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [proposal] Generic type aliases

> On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution > wrote: > > This is a minimal proposal for introducing type aliases into Swift, and > intentionally chooses to keep them limited to being “aliases”. As such, > additional constraints are not allowed

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> On Mar 18, 2016, at 13:11 , Félix Cloutier wrote: > > GCC may have some hints: > >> -fdelete-null-pointer-checks >> Assume that programs cannot safely dereference null pointers, and that no >> code or data element resides at address zero. This option enables simple >>

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

> Per Doug’s email, the core team agrees we should make a change here, but > would like some bikeshedding to happen on the replacement name for private. > > To summarize the place we’d like to end up: > > - “public” -> symbol visible outside the current module. > - “internal” -> symbol visible

Re: [swift-evolution] [Draft] Abolish IUO type

What will happen to map()/flatMap() on IUO attributed optional values? let foo: Int! = 42 let bar = (foo as ImplicitlyUnwrappedOptional).map { $0.UInt($0) } Replacement would be something like this? let bar: UInt! = (foo as Int?).map { UInt($0) } I have never seen code like this in real

Re: [swift-evolution] [Draft] Abolish IUO type

> On Mar 16, 2016, at 5:34 PM, Brent Royal-Gordon > wrote: > >> The most significant one is that I think that describing this in terms of an >> IUO attribute (which is an internal implementation detail) makes the >> proposal more confusing than necessary for the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

> • What is your evaluation of the proposal? Good stuff. How exact does the type match have to be? Can they be two subclasses of a different superclass? Can they conform to common protocols? Can they conform to no common protocols and just be `AnyObject` or `Any`? Is there a way to

Re: [swift-evolution] [Draft] Abolish IUO type

Oops, typo in the example code: let foo: Int! = 42 let bar = (foo as ImplicitlyUnwrappedOptional).map { UInt($0) } 2016-03-18 14:05 GMT+09:00 rintaro ishizaki : > What will happen to map()/flatMap() on IUO attributed optional values? > > let foo: Int! = 42 > let bar = (foo

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

Since we’re allowing keywords as argument names, shouldn’t this: func foo(let i: Int) be allowed, such that it’ll be called as this: foo(let: 3) — Harlan > On Mar 17, 2016, at 11:08 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Mar 17, 2016, at 1:27

Re: [swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references

> I'm in favor. Unbound methods have always existed in a sort of awful tension > between being usable in higher-order algorithms and being usable in more > down-to-earth situations like `map`. With the demise of curried functions and > implicit tuple splatting, the higher-order stuff isn't

Re: [swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

On Mar 8, 2016, at 7:29 PM, Kevin Ballard via swift-evolution wrote: > > One minor change to what I've been proposing: Instead of merely saying that > it's implementation-defined, we should expressly say that invoking next() > after it has previously returned nil

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] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

After using Swift all day, every day since day #1, I'm strongly in favor, e.g. +1 here! Now bring the @pure! :) R+ Sent from my iPhone > On 16 Mar 2016, at 20:36, Chris Lattner wrote: > > Hello Swift community, > > The review of “Defaulting non-Void functions so they

Re: [swift-evolution] What's the best replacement if "Remove C-style for loops"?

> On 17 Mar 2016, at 14:48, nebulabox via swift-evolution > wrote: > > I have several codes like the following: > > for var i = 0; i < myarr.count; i += n { // the step is NOT 1 >// many codes > } > > (…) If no C-style for loop, what's the best replacement for

Re: [swift-evolution] [Draft] Abolish IUO type

It seems reasonable.  If I understand it correctly, I would still be able to write code like this:     @IBOutlet weak var emailTextField: UITextField! I don’t have any issues with the limitations as proposed. Btw, I included the above line because with all of the examples you used, IMO, it

Re: [swift-evolution] SE-0047

> It is far more common to be able to ignore a return value than to have it be > required to be handled. Do you really think that's true? I took a look at the Swift standard library and extracted just the function, method, and operator names and return values, with Void functions excluded

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

I understand this. I am looking forward to see what Ted proposes. -Patrick > On Mar 19, 2016, at 2:31 PM, Ross O'Brien wrote: > > But the discussion is no longer about 'do we really need to take this feature > out?'. The feature is already out. It's deprecated in

[swift-evolution] [Draft 2] Throwing Properties and Subscripts

I've incorporated the feedback from the previous thread, "[Draft] Throwing Properties and Subscripts", into my proposal on permitting getters and setters to throw. Draft 2 formatted

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

Le 15 mars 2016 à 20:31, Michael Ilseman a écrit : > Automatic inference, at least in the near term, will not be turned on by > default for all C APIs, but will start out as opt-in. In the near term, > heuristics and techniques are tuned for CF-style naming conventions.

[swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

Strong +1, with some nitpicks to enclosed example: I disagree that NSNotificationCenter’s returned token should be ignored without warning—this goes against the patterns I’ve seen in programming Cocoa the last 27 years, where needing to unregistering for notifications when an object is

[swift-evolution] [Draft] Change IteratorType post-nil guarantee

Proposal pull request: #213 Implementation pull request: #1702 Original pitch thread: [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> > • What is your evaluation of the proposal? +1 > • 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

Re: [swift-evolution] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

> > • What is your evaluation of the proposal? I think anything that improves pattern matching is a good thing for Swift. > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > • Does this proposal fit well with the feel and direction

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

But the discussion is no longer about 'do we really need to take this feature out?'. The feature is already out. It's deprecated in Swift 2.2. The discussion is 'is there a compelling reason to put it back in again?'. We still have for-in loops. We still have repeat while. We still have forEach.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

+1 This is a great addition. I've hoped for it since 1.0. On Sat, Mar 19, 2016 at 9:45 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > • What is your evaluation of the proposal? > > > +1 > > • Is the problem being addressed significant enough to warrant a change

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen > wrote: > > On Chris’s advice, I’ve spawned this into a new discussion topic, for which > the base could be > part of what I wrote in relation to SE-0007. > > > Hello Patrick > as I wrote: > As a result of removing

[swift-evolution] Making pointer nullability explicit (using Optional)

Hey, everyone. If you're like me, you're sick of the fact that 'UnsafePointer' doesn't tell you whether or not the pointer can be nil. Why do we need to suffer this indignity when reference types—including function pointers!—can distinguish "present" from "absent" with the standard type

[swift-evolution] Removing explicit use of `let` from Function Parameters

​As a follow-up to proposal SE-0003​: "Removing var from Function Parameters" being accepted, I think it might make sense to disallow explicitly declaring function parameters with the `let` keyword since function parameters are immutable by default. Basically disallow writing functions like this:

Re: [swift-evolution] [Draft] Abolish IUO type

> On Mar 17, 2016, at 9:08 PM, Chris Lattner via swift-evolution > wrote: > > On Mar 17, 2016, at 5:50 PM, Brent Royal-Gordon > wrote: > >>> It seems like this unnecessarily complicates the surface model of Swift. >>> To me, it seems like

[swift-evolution] Fwd: [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

> Begin forwarded message: > > From: Victor Gao > Subject: Re: [swift-evolution] [swift evolution] [proposal] Proposal to add > "implement" keyword to denote protocol method implementation > Date: March 18, 2016 at 21:48:53 ADT > To: Ross O'Brien

Re: [swift-evolution] [Pitch] Remove bit shift traps

> Le 18 mars 2016 à 07:03, Haravikk via swift-evolution > a écrit : > > Since the trap represents a possible mistake, I think it’s better to keep it. > However, we could have &<< and &>> operators that return the suggested > defaults? This would also be more

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> On Mar 18, 2016, at 9:49 AM, Jordan Rose wrote: > > >> On Mar 17, 2016, at 21:08 , Russ Bishop > > wrote: >> >> I’m very much +1 on this idea. >> >>> On Mar 17, 2016, at 6:59 PM, Jordan Rose via swift-evolution >>>

Re: [swift-evolution] [Draft] Abolish IUO type

> On Mar 18, 2016, at 4:20 AM, James Campbell wrote: > > One thing I've had bit me is the lack of some sort of confirmation, see this > example. > > I have a objective-c method in a library like so: > > - (void)observe:(CallbackBlock)block; > > The CallbackBlock is a type

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> On Mar 18, 2016, at 9:49 AM, Jordan Rose via swift-evolution > wrote: > > >> On Mar 17, 2016, at 21:08 , Russ Bishop wrote: >> >> I’m very much +1 on this idea. >> >>> On Mar 17, 2016, at 6:59 PM, Jordan Rose via swift-evolution >>>

Re: [swift-evolution] Changing the curried static methods

> On Mar 15, 2016, at 6:03 PM, Stephen Celis wrote: > > >> On Mar 14, 2016, at 1:09 PM, Joe Groff via swift-evolution >> wrote: >> >> Note that there's a proposal open to flatten away the currying altogether: >> >>

[swift-evolution] [Pitch] Remove bit shift traps

Currently, bit shifting with an amount greater than or equal to the size of the type traps: func foo(x: Int32) { let y = x << 32 // Runtime trap (for any << or >> with amount >= 32) } I propose to make this not trap, and just end up with 0 (or ~0 in case of right-shifting a negative number):

Re: [swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references

> • What is your evaluation of the proposal? I'm in favor. Unbound methods have always existed in a sort of awful tension between being usable in higher-order algorithms and being usable in more down-to-earth situations like `map`. With the demise of curried functions and implicit tuple

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> What is your evaluation of the proposal? I worry about imported libraries. I think the default is right for code that was written directly in Swift, but for C and Objective-C code that was written in discartable-by-default environment, the APIs were designed with discardable results that in

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

I guess I am not in the forloopian camp. I spend far too much time, converting for i = 0; i < 4; i++) into something more modern like iterating over containers. If it is in the language, people will use it, not having it there makes people think about better ways of doing things rather than

Re: [swift-evolution] [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

(cc swift-evolution) > On Mar 19, 2016, at 8:41 AM, Step C wrote: > > The compiler can tell us when we have broken or not completed conformance, > agreed. > > If we can empower extensions a bit more, we could also fully group each > protocol conformance by

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

> Can't quite see where "Inheritance for structs / "newtype"-feature" > enables this, however. Care to explain? It's not required, but unless you want to implement a completely new numeric type (like fractions), it is tedious to declare all operations and conversions that are useful or

Re: [swift-evolution] [Draft] Abolish IUO type

> On Mar 16, 2016, at 6:44 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Let me play devil’s advocate: why not just get rid of implicit unwrapping >> entirely? >> >> Apple’s Objective-C APIs have had plenty of time to be audited by now. > > Two reasons:

Re: [swift-evolution] [Draft] Abolish IUO type

> On Mar 17, 2016, at 12:16 AM, Chris Willmore via swift-evolution > wrote: > > To run with the example above, emailTextField would have type UITextField? > but, because it’s an IUO declaration, it would still be usable in contexts > that required non-optional

Re: [swift-evolution] [Pitch] Limit Implicit Capture

> On Mar 16, 2016, at 11:09 AM, Jordan Rose via swift-evolution > wrote: > > It's worth noting that—for better or for worse—explicit capture has different > semantics from implicit capture today. If a local variable ('var', not 'let') > is captured, it is captured

Re: [swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

Proposal: https://github.com/apple/swift-evolution/pull/213 On Wed, Mar 9, 2016 at 1:29 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > One minor change to what I've been proposing: Instead of merely saying > that it's implementation-defined, we should expressly say

[swift-evolution] Attention Proposal Authors

Hi All, Not long ago we landed changes in trunk that reflect the new API guidelines and importer rules. If you have a proposal in the queue, or an open pull request for a proposal, please check it over to make sure it reflects Swift 3 reality. If changes need to be made to a proposal in the

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

Thanks for the pointers Erica! I have updated the motivation section and the section on the impact on existing code. How does the proposal look now? - Nick All the best, Nicholas Linked in: http://lnkd.in/328U22 On Fri, Mar 18, 2016 at 11:33 PM, Erica Sadun wrote: >

[swift-evolution] What's the best replacement if "Remove C-style for loops"?

I have several codes like the following: for var i = 0; i < myarr.count; i += n { // the step is NOT 1 // many codes } I knew I could use the while loop, but it seems very ugly. var i = 0 while i < marr.count { // some codes i += n // Sometimes it is easy to be missed } If no

Re: [swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references

> • What is your evaluation of the proposal? +1. This is a great proposal, especially for the functional use cases mentioned in the motivation section. > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. It makes functional use cases more

Re: [swift-evolution] [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

Do I need to create a md file in the swift evolution repository to post my proposal? > On Mar 19, 2016, at 00:12, Jordan Rose wrote: > > [+swift-evolution] Sure! It's just a fancy word for doing something like this: > > protocol SelfAppendable { > init() > func

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

>> I also don't like that this proposal doesn't include an "Impact on existing >> code" section. We ought to decide whether the migrator will add >> `@discardableResult` to existing symbols or not. > > I totally agree with Erica – the migrator should only remove existing > @warn_unused_result

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

Just had an idea for a different approach for access levels (as if things aren't complicated enough ;-) - but I'm only brainstorming here): The problem of access levels isn't limited to programming — file systems have to deal with it as well. So, ignoring ACLs for a moment, imagine protected x:

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

Looks great, thanks! - Doug > On Mar 17, 2016, at 9:45 PM, Nicholas Maccharoli > wrote: > > Thank you! > > I have filed a PR here: https://github.com/apple/swift-evolution/pull/215 > > > How does it look? >

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

On 3/19/16 09:03, Tino Heth via swift-evolution wrote: >> Just wanted to expand on the type tolerances idea with an example: >> >> let a:Float±0.1 = 1234.56 >> let b:Float±0.5 = 123.456 >> >> let result:Float±0.25 = a + b // Error as b’s tolerance > 0.25 > That example is a good motivation for two

Re: [swift-evolution] Proposal to remove semicolons

-1 I think end-of-line semicolons are ugly. I also think the decision to use them or not use them should be left to individuals and not enforced by the compiler. In the current implementation a semicolon can be optionally added after any statement and is proactively used to separate statements

[swift-evolution] [Accepted] SE-0037: Clarify interaction between comments & operators

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md The review of SE-0037 "Clarify interaction between comments & operators" ran from Mar 11…15, 2016. The proposal has been *accepted*: There was little community discussion, but

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

> I wonder if it would help to document the grammar changes necessary in the > proposal. I'm preparing a revision with that information. > I also wonder how it could affect the getter shorthand? Couldn't the > following work for subscripts? > >subscript(idx: Int) throws -> Element { ... }

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

> I would like to update my draft proposal to introduce a test for debug > configurations using a public function > rather than a build configuration test. > > * Would the stdlib team be open to that? > * What would be an appropriate name? `debugConfiguration`? `debugBuild`? > `isDebugBuild`?

[swift-evolution] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

Hello Swift community, The review of “Declare variables in 'case' labels with multiple patterns” begins now and runs through March 21, 2016. The proposal is available here:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> On Mar 16, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> • What is your evaluation of the proposal? > > Overall in favor. > > I don't like the getter syntax: > > float Point3DGetRadius(Point3D point) >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

Thanks for pointing out the ambiguity! I added an amendment to the proposal in https://github.com/apple/swift-evolution/pull/214 > On Mar 16, 2016, at 4:58 AM, Michel Fortin wrote: > > Le 15 mars 2016 à 20:31, Michael Ilseman a écrit : > >>

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> The review of “Defaulting non-Void functions so they warn on unused results” > begins now and runs through March 21, 2016. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md > > • What is your evaluation of

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

GCC may have some hints: > -fdelete-null-pointer-checks > Assume that programs cannot safely dereference null pointers, and that no > code or data element resides at address zero. This option enables simple > constant folding optimizations at all optimization levels. In addition, other >

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

> On Mar 17, 2016, at 11:22 AM, Harlan Haskins wrote: > > Since we’re allowing keywords as argument names, shouldn’t this: > > func foo(let i: Int) Right now, you’d have to declare this as func foo(`let` i: Int) but the proposal would fix that. > be allowed,

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

Brent Royal-Gordon via swift-evolution writes: Hi Brent, Excellent work! That is an extremely well written proposal draft - and I would love to see the proposal accepted. Here are my 2 cents on the discussion about alternatives: 1. Omit throwing getters on properties:

Re: [swift-evolution] [proposal] Generic type aliases

> On Mar 16, 2016, at 12:23 PM, Russ Bishop wrote: > > >> On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution >> > wrote: >> >> This is a minimal proposal for introducing type aliases into Swift, and >>

Re: [swift-evolution] [Draft] Abolish IUO type

One thing I've had bit me is the lack of some sort of confirmation, see this example. I have a objective-c method in a library like so: - (void)observe:(CallbackBlock)block; The CallbackBlock is a type def-ed block like so: typedef void (^CallbackBlock)(FDataSnapshot *snapshot); The parameter

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

• What is your evaluation of the proposal? +1 on proposal overall. I agree that @discardable is sufficient to describe what it does. If there is questions it is easy to search it on the web. Also the context of where the @discardable modifier is on the line will reduce ambiguity.

Re: [swift-evolution] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

• What is your evaluation of the proposal? A strong +1. • 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

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

Yes, thank you Dmitri, I think so too. Will come back to this later. TedvG ted van gaalen > On 19 Mar 2016, at 08:46, Dmitri Gribenko wrote: > > Hi Ted, > > Thank you for starting this thread. I agree that removing the C-style > for loop has degraded the readability

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

This is an interesting proposal. I have a couple of throwing `setSomething` methods in my code that could be expressed as throwing property setters. That said, I don't really mind them being methods. Methods having a verb in their names makes them fit well with `try` at the call site. I also

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

+1 but: I'm somewhat hesistant about not marking the plausibly discarable ones @discardableResult. - I rarely use the result value of removeLast() and I don't see how requiring it here adds any safety. It is obvious this call has side-effects and doesn't just return the last element. - I would

Re: [swift-evolution] [Proposal] Add an API to Unmanaged to get the instance it holds "@guaranteed"

> Probably not, The name is a strawman. I guess I could not resist the > optimizer speak after all. The programmer is asserting he guarantees the > lifetime by other means. I expect if this proposal moves forward the standard > library team will decide on the right name for this method. > >

Re: [swift-evolution] [proposal] Generic type aliases

>> However, we do infer the `T: Hashable` in a case like this: >> >> func foo(x: Dictionary) {} >> >> `typealias` feels similar to that to me. It doesn't have to be a global >> analysis, just an analysis of the RHS of the typealias. > > I consider the RHS of the typealias to be the

Re: [swift-evolution] [Draft] Abolish IUO type

On Mar 17, 2016, at 5:50 PM, Brent Royal-Gordon wrote: >> It seems like this unnecessarily complicates the surface model of Swift. To >> me, it seems like there is no advantage to having two ways to spell this. > >@autounwrapped let foo =

[swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references

Hello Swift community, The review of “Flattening the function type of unapplied method references” begins now and runs through March 21, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md Reviews are an

Re: [swift-evolution] Proposal to remove semicolons

cc'ing the list back in to catch up on this. -- E > On Mar 16, 2016, at 10:54 AM, Chris Wood wrote: > > I really need to remember the “reply to all” button for these mailing lists. > *Facepalm* :) > > Chris > >> On Mar 16, 2016, at 4:25 PM, Chris Wood

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> On 17 Mar 2016, at 09:27, Tino Heth via swift-evolution > wrote: > > Sadly, the second sentence is definitely true — "@discardableResult" doesn't > "feel" right, and would discourage techniques like fluent interfaces. Somehow I completely forgot about the issue

[swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

Hello Swift community, The review of “Defaulting non-Void functions so they warn on unused results” begins now and runs through March 21, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md Reviews are an important

Re: [swift-evolution] SE-0047

I don't think that counting discardable results in existing Cocoas libraries is a good metric for the usefulness of warn-unused-result: Other libraries may follow a different style, and Objective-C is a very bad fit for fluent interfaces. So far, I haven't seen any real world examples of

Re: [swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

On Wed, Mar 16, 2016, at 09:59 AM, Erica Sadun wrote: > >> On Mar 16, 2016, at 10:41 AM, Joe Groff wrote: >> >>> >>> On Mar 16, 2016, at 8:24 AM, Erica Sadun via swift-evolution >>> wrote: >>> >>> On Mar 8, 2016, at 7:29 PM, Kevin Ballard via

Re: [swift-evolution] [Draft] Abolish IUO type

> On Mar 17, 2016, at 1:45 PM, Jed Lewison wrote: > >> On Mar 17, 2016, at 12:16 AM, Chris Willmore via swift-evolution >> > wrote: >> >> To run with the example above, emailTextField would have type

  1   2   >