Re: [swift-evolution] Add an ifPresent function to Optional

> On Mar 20, 2016, at 11:52 AM, Erica Sadun via swift-evolution > wrote: > > Questions being raised in this discussion: > > * Are the current stdlib names for optional map and flatMap misleading? Misleading makes it a harder question to answer. I can answer with

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

I would also like to see some real world use cases from numerics packages. This may be something we can solve by providing a series of customizable generators. Stride might work for a subset of use cases, but I don’t think we should try to shoehorn everything into it. I have generally been

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

> A simple example might be: for (altitude = 0.1; altitude < 10e6; altitude > =* 10.0) { . . . } Conceptually, this could be represented as a variant of `stride` which took a unary function for its `by` parameter: for altitude in stride(from: 0.1, to: 10e6, by: { $0 * 10 }) {

Re: [swift-evolution] Add an ifPresent function to Optional

> On Mar 20, 2016, at 12:20 PM, Krzysztof Siejkowski > wrote: > However, I’m not sure about this one: > >> public func f2(@noescape f: (Wrapped) throws -> U!) rethrows -> U! > > I haven’t used implicitly unwrapped optionals at all, I just never found a > good case

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

On 3/20/16 14:43, Andrey Tarantsov via swift-evolution wrote: > I have no stake in this proposal, except for: > >> I suggest, therefore, that this acceptance be indicated by an >> annotation to the literal; a form such as ~0.1 might be easiest to >> read and implement, as the prefix ~ operator

Re: [swift-evolution] Add an ifPresent function to Optional

Questions being raised in this discussion: * Are the current stdlib names for optional map and flatMap misleading? * Are the current stdlib functions for optional closure application appropriate and sufficient? @warn_unused_result public func map(@noescape f: (Wrapped) throws -> U)

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

I have no stake in this proposal, except for: > I suggest, therefore, that this acceptance be indicated by > an annotation to the literal; a form such as ~0.1 might be easiest to > read and implement, as the prefix ~ operator currently has no meaning > for a floating-point value. Whatever you

Re: [swift-evolution] Add an ifPresent function to Optional

> No. My argument is that map on collections and on optionals are two > completely different things. They unify on a level that does not > exist in Swift (higher-kinded types). +1000. Optional.map is already highly unfortunate. It makes optional arrays especially painful to deal with, but

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

Ah, thanks. No surprises there. I use a similar approach and it is often sufficient. `newtype` could reduce boilerplate there but not necessarily by a lot. Do you think that kind of "wrapper-type" replacement is the right place to target first? > El mar 20, 2016, a las 10:32 AM, Tino Heth

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

I recently had the misfortune of deleting what turned out to be a necessary function, because it was an optional requirement of a protocol and wasn't being called by any code in the project, so I would sympathise with this. On the other hand I've also written protocols composed entirely of

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

Imho the syntax of the deprecated for-loop was no good fit for Swift, but I've read several rumors about inferior performance of the alternatives…. so, as a basis for further discussion, I'd like to see some reliable numbers: I expect that every loop can be expressed in Swift 3 with identical

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

> Le 19 mars 2016 à 15:35, Dany St-Amant via swift-evolution > a écrit : > > >> Le 15 mars 2016 à 09:07, Ilya Belenkiy via swift-evolution >> > a écrit : >> >> These names are very uniform, and the

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

Thank you for the feedback! I checked SE-0003 again and didnt see explicit mention of this. I would like to write up a quick proposal today if its ok. Chris, I promise to make it very concise is it ok to send over a PR to swift evolution? - Nick 2016年3月18日金曜日、Chris

[swift-evolution] Notes from Swift core team 2016-03-15 design discussion

To help keep proposals moving forward, the Swift core team has set aside some time specifically for design discussions of upcoming proposals. Below are some rough notes from the yesterday's discussion. These are informal comments, intended to guide the proposals in directions that draw

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

> On Mar 17, 2016, at 11:08 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Mar 17, 2016, at 1:27 AM, Nicholas Maccharoli via swift-evolution >> > wrote: >> >> ​As a follow-up to proposal

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

Big +1 on this proposal from me. Does this proposal allow a protocol can have generic associated types? - associatedtype Something - associatedtype Something It's not mentioned, but I think it would be necessary at some point for completeness. On Thu, Mar 17, 2016 at 2:32 PM, Joe Groff

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

> On Mar 17, 2016, at 1:38 PM, Chris Willmore via swift-evolution > wrote: > >> On Mar 17, 2016, at 6:53 AM, Brent Royal-Gordon >> wrote: >> >>> 1. We have to add @implicitly_unwrapped attribute to the proposal. I hate >>> implied

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

> 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 non-compiler hackers. :-) For what it's worth, I actually find it really helpful to have a way