Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

+1 from me too. (My vote takes into account the various alternatives were put on the table and weeded down thoughtfully to the one we're voting on.) -- E > On Jan 3, 2016, at 5:57 AM, T.J. Usiyan via swift-evolution > wrote: > > +1 from me. It is a solid change

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

On Jan 1, 2016, at 1:46 PM, Chris Lattner <clatt...@apple.com> 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

Re: [swift-evolution] STDLibs

Have you stopped by swiftdoc.org recently? :) -- Erica > On Jan 6, 2016, at 3:43 AM, James Campbell via swift-evolution > wrote: > > Is there a way of improving the documentation and hosting it on Swift instead > of Apple ? > > Currently

Re: [swift-evolution] About the PermutationGenerator

t able to think > of one back when I was originally thinking about this, but of course that > doesn't mean there isn't one. (Infinite collections are interesting as > discussed on the "cycle" thread, but it's not the sequence/generator > distinction that's really meaningful there

Re: [swift-evolution] About the PermutationGenerator

It does seem that in Swift the concepts of collection, sequence, permutation, stream, etc are a bit muddled. -- E > On Dec 31, 2015, at 6:51 AM, Tino Heth via swift-evolution > wrote: > >> Those are collections. Collections can be iterated over multiple times. >

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

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? Thanks, -- E

Re: [swift-evolution] Proposal: Enum 'count' functionality

My wild aspirations in a nutshell: Core enums: Any enum that's created without raw or associated values, e.g. enum MyEnum {case This, That, Whatever, Etc}, can (and should) be Array representable. This would add intrinsic ordering and raw value construction starting with 0, up to count - 1.

Re: [swift-evolution] Proposal: Enum 'count' functionality

That would be okay too. Thank you, Santa Joe. -- E, who hopes she was on the nice list. > On Dec 21, 2015, at 3:56 PM, Joe Groff wrote: > > >> On Dec 21, 2015, at 12:24 PM, Erica Sadun wrote: >> >> I could be satisfied by such an approach. I could

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On Dec 22, 2015, at 6:25 PM, Dave Abrahams <dabrah...@apple.com> wrote: > >> >> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> As SE-0011 stat

Re: [swift-evolution] Optional dictionary subscripts

if let key = key, value = dict[key] { ...whatever... } seems to work fine without introducing a new construct -- E, waving hi to John > On Dec 22, 2015, at 4:37 AM, John Holdsworth via swift-evolution > wrote: > > This isn’t the most compelling of ideas but a

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

And what are your feelings about: typestandin, typeplaceholder, or adoptedtype? How would you describe the functionality of these members if you weren't looking for a keyword? -- E > On Dec 23, 2015, at 9:34 AM, Chris Lattner via swift-evolution > wrote: > > >>

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

at the > start of every line. Also if an API is intended to be used like that its > methods would return `self` and it would be used in a FLUENT style. > > Sent from my iPad > > On 28 Dec 2015, at 9:00 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org &l

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

or two > to your proposal, but I need to flesh them out first. Is it possible to leave > comments on the bug site? BTW, why was it delegated to the bug report system > in the first place? > > > >> On 28 Dec 2015, at 02:28, Erica Sadun via swift-evolution >> &l

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

As SE-0011 states, the concept of typealias is overloaded. In one case, it's really just typedef. In the other it's a stand-in for a deferred type that is specified by conforming classes. While you could argue that the other typealias be redefined to typedef, it's pretty clear that in use,

Re: [swift-evolution] [Accepted] SE-0015 Tuple Comparison Operators

Congratulations Kevin! My tuples thank you from the bottom of their arity. -- E > On Dec 23, 2015, at 6:01 PM, Dave Abrahams via swift-evolution > wrote: > > > The review of SE-0015 “Tuple Comparison Operators" ran from December 21–22, > 2015. The proposal has

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

Is there a reason that any final non-void statement in a closure or function shouldn't automagically be an optional return? (And automagically warn_unused_result...?) > On Dec 19, 2015, at 5:44 PM, Andrew Bennett via swift-evolution > wrote: > > +1 for consistency

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> Maybe [some person] could make a quick poll and see which one developers > prefer?  (after they read this email) Ask. Receive. https://www.surveymonkey.com/r/S8F59XF ___ swift-evolution mailing list

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 3:55 PM, Brent Royal-Gordon wrote: > >> I don't disagree with the points you make. But one can argue that this is a >> good thing. It calls attention to code that requires extra attention and >> care. In some ways this is similar to

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 12:47 PM, Matthew Johnson via swift-evolution > wrote: > On Jun 2, 2016, at 1:30 PM, John McCall > wrote: > >>> On Jun 2, 2016, at 11:22 AM, Matthew Johnson >>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 2:43 PM, Russ Bishop wrote: > > >> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution >> > wrote: >> >> I still think the value-based APIs are misleading and that it would be >>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 2:13 PM, Matthew Johnson wrote: > I don't disagree with the points you make. But one can argue that this is a > good thing. It calls attention to code that requires extra attention and > care. In some ways this is similar to

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 3:28 PM, John McCall via swift-evolution > wrote: > >> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu > > wrote: >> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution >>

Re: [swift-evolution] [Proposal] Enum subsets

A few ideas: * Mention the pull request about member sets? * I'd try to give some more compelling use cases (Where a union type can be broadly applied across more specific uses, which then tend to narrow the applicable cases, and you want to limit (and compile check) those cases while

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Discussion has more or less drawn down. Are there any further significant requests / issues that need addressing? Both standalone functions (my recommended approach) and the MemoryLayout struct approach (alternative, with reasons why I think it's not as ideal) are discussed in-proposal. Pull

Re: [swift-evolution] SE-0045 status?

> On Jun 8, 2016, at 12:05 AM, Chris Lattner <clatt...@apple.com> wrote: > >> >> On Jun 7, 2016, at 9:54 PM, Erica Sadun <er...@ericasadun.com> wrote: >> >> >>> On Jun 7, 2016, at 9:37 PM, Chris Lattner <clatt...@apple.com> wrote: &

Re: [swift-evolution] Add a while clause to for loops

> On Jun 8, 2016, at 1:07 PM, Xiaodi Wu via swift-evolution > wrote: > I should add, on the topic of removing `where`, there would be a higher > threshold for a successful proposal and I would have to convince people that > the `where` clause is actually harmful. I

Re: [swift-evolution] Sketch: Teach init a 'defer'-like ability to deinit

I really like this idea. Spatially moving cleanup next to unsafe operations is good practice. In normal code, I want my cleanup to follow as closely as possible to my unsafe act: let buffer: UnsafeMutablePointer = UnsafeMutablePointer(allocatingCapacity: chunkSize) defer {

Re: [swift-evolution] Add a while clause to for loops

> On Jun 8, 2016, at 9:23 PM, Brent Royal-Gordon via swift-evolution > wrote: > The original sin here was in connecting the `where` clause to the for loop's > sequence expression, rather than its pattern. If `where` were positioned > right after the loop variable: >

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

My results: -Onone (None) plain for loop with guard Elapsed time: 0.0563530325889587 plain for loop with if Elapsed time: 0.0631130337715149 where test Elapsed time: 0.0661619901657104 eager filter test Elapsed time: 0.684610962867737 lazy filter test Elapsed time: 0.640420973300934 Program

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Missed pasting this one bit: var value = 0 func doSomething() { // some numeric load value += 1 } > On Jun 9, 2016, at 9:59 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > My results: > > -Onone (None) > > plain for

Re: [swift-evolution] extend trailing closure rule

> On Jun 8, 2016, at 4:11 PM, Matt Neuburg via swift-evolution > wrote: > > Well, I guess I didn't pick a strong enough case. Try this one: > >UIView.animate(withDuration:0.4, delay: 0, options: [.autoreverse]) { >self.view.backgroundColor =

Re: [swift-evolution] Ad hoc enums / options

> On Jun 4, 2016, at 8:58 AM, Hooman Mehr wrote: > > How about this: > > > Going back to Erica’s original example: > > func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > operation: (.Fit | .Fill) = .Fit > ) -> UIImage { > > And noting that we

Re: [swift-evolution] Ad hoc enums / options

On Jun 7, 2016, at 2:49 PM, L Mihalkovic wrote: >> This is my favorite approach (assuming it's technically feasible) as it >> preserves the limitation that the enumerations are scoped strictly to the >> function but can be referenced outside of it. >> >> It allows

Re: [swift-evolution] SE-0045 status?

> On Jun 7, 2016, at 9:37 PM, Chris Lattner <clatt...@apple.com> wrote: > > >> On Jun 6, 2016, at 8:35 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Did we ever get to a stopping point on SE-0045, with the take

[swift-evolution] SE-0045 status?

Did we ever get to a stopping point on SE-0045, with the take while / drop while methods? I remember we were discussing using prefix / suffix and a bunch of other names, but was the consensus ever fully settled? I'm going back through the gmane archive, the SE repo, and the 5-31 dev build and

Re: [swift-evolution] [Proposal] A more liberal placement of defer

This is problematic. You may want to defer code at different points with different reasons. For example, you might not want to trigger defer until after some preconditions have been met.: guard something guard something allocate memory; defer {release memory} -- E > On Jun 6, 2016, at 1:50

Re: [swift-evolution] [Proposal] A more liberal placement of defer

Not sure I see how they're in different scopes. Can you explain that to me? -- E > On Jun 6, 2016, at 2:18 PM, donny wals wrote: > > Erica, > > Maybe my phrasing was a bit off, but in my proposal it’s really important > that the return and the defer are in the same

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 10, 2016, at 9:24 AM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Jun 10, 2016, at 9:22 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>>

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 10, 2016, at 9:49 AM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Jun 10, 2016, at 9:24 AM, Erica Sadun <er...@ericasadun.com >> <mailto:er...@ericasadun.com>> wrote: >> >> >>> On Jun 10, 2016, at 9:22 AM, Eri

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

> On Jun 10, 2016, at 1:06 PM, Rob Norback via swift-evolution > wrote: > > Following Brent's logic that the for-in where should mimic the switch > statement functionality, then this example: > > for (eachKey, eachValue) > where eachValue > 5 > in

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 8, 2016, at 10:17 PM, Sean Heber <s...@fifthace.com> wrote: > > > On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I saw your post on that *after* I fin

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 9, 2016, at 11:11 AM, Charlie Monroe wrote: > See my latest post - included results with -Ofast. But still, using filter > and lazy.filter is 10+% slower, which were the suggested alternatives to > `where`. > > I need to correct this misapprehension. My

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution > wrote: > > So, instead of: > > @available(*, unavailable, renamed:"someNewAPI()") > public func someOldAPI() -> Int { fatalError() } > > You can just have: > > @available(*, unavailable,

Re: [swift-evolution] Add max/min to floating point types

CGFloat has .max and .min. And if you use them, you get: 2016-06-10 13:32:14.185 Untitled Page 10[18435:13174627] This NSLayoutConstraint is being configured with a constant that exceeds internal limits. A smaller value will be substituted, but this problem should be fixed. Break on void

Re: [swift-evolution] Sketch: Teach init a 'defer'-like ability to deinit

memory, ditto. Etc etc. Surely Swift should be able to support doing this. -- E > On Jun 8, 2016, at 3:43 PM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > I really like this idea. Spatially moving cleanup next to unsafe operations > is good practic

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

> On Jun 9, 2016, at 1:57 PM, Haravikk wrote: > > I think the idea here is for a change from the first to the second of: > > for eachValue in theValues where eachValue.isOdd { … } > for eachValue where eachValue.isOdd in theValues { … } > > I’m kind of

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

> On Jun 9, 2016, at 12:31 PM, Антон Жилин via swift-evolution > wrote: > > I'm starting to worry about the proposal, too. Any news? > > - Anton They posted: The core team has caught up except for three proposals that have gone through the review period, but

[swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

Gist: https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57 Regularizing Where grammar Proposal: TBD Author: Brent Royal-Gordon , Erica Sadun Status: TBD Review manager: TBD

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

3. > On Thu, Jun 9, 2016 at 1:54 PM Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> On Jun 9, 2016, at 1:57 PM, Haravikk <swift-evolut...@haravikk.me >> <mailto:swift-evolut...@haravikk.me>

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

So how did the guard versions perform? Sent from my iPad > On Jun 9, 2016, at 4:27 AM, Charlie Monroe wrote: > > >>> On Jun 9, 2016, at 10:29 AM, Brent Royal-Gordon >>> wrote: >>> >>> I've taken the time to run a test, going through milion

Re: [swift-evolution] Ad hoc enums / options

> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution > wrote: > What about the ABI? This sounds expensive to implement. > > Consider this set of ad-hoc enum types: > > (.a | .b) > (.c | .d) > > Naive implementation: we'll represent these things as

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0096: Converting dynamicType from a property to an operator

> On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution > wrote: > I don't understand why the proposal says we can't implement this in the > library today. > > $ swift > Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). > Type

[swift-evolution] [Pitch] Circling back to `with`

Over the past couple of days, the Twitters have discovered some work I'd done on closure-based setup. It's clear that a demand is out there and strong for this kind of behavior, even without implicit `self` as part of the mix or cascading. In that light, I've put together the following:

Re: [swift-evolution] [Pitch] Circling back to `with`

> On May 25, 2016, at 3:29 PM, Matthew Johnson wrote: > On May 25, 2016, at 3:56 PM, Erica Sadun > wrote: >> I wouldn't be pushing if I thought it wouldn't be useful after cascading. If >> no other reason, it offers a

Re: [swift-evolution] [Pitch] Circling back to `with`

On May 25, 2016, at 2:55 PM, Matthew Johnson wrote: > > >> On May 25, 2016, at 3:48 PM, Jacob Bandes-Storch via swift-evolution >> > wrote: >> >> I like this pretty well, and I think "with()" makes sense as a

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

> On May 25, 2016, at 2:18 PM, Kevin Ballard via swift-evolution > wrote: >> We think the need to do a capture is icky, so the sequence form is >> almost always better. > > I agree that the need for a capture is ugly. >> The design of AnySequence and AnyIterator

Re: [swift-evolution] [Pitch] Circling back to `with`

e Then project relies upon. I'm unfamiliar with `tap` but it looks similar to method cascading, which is on hold for Swift 4. -- E > >> On May 25, 2016, at 2:28 PM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> w

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 10, 2016, at 9:22 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >&g

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 10, 2016 at 7:18 AM, Haravikk > wrote: >> * The word "where" does not consistently imply `break` or `continue`.

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution > wrote: > > I am 100% with Charlie on this. Expressiveness has to do with the > *effectiveness* of conveying a thought or a feeling. > > Keep "where". It is expressive. It conveys a specific idea

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 14, 2016, at 7:50 AM, plx via swift-evolution > wrote: > For those particular keywords, I’d prefer having them (or equivalents). I’m > not sure if I’d prefer having *all* of them—`where/unless` and > `while/until`—or just one from each “pair”…I could go

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 13, 2016, at 9:44 AM, let var go via swift-evolution > wrote: > > I think we must be reading different discussions. > > What I have seen in this discussion is the following: > > a) The need to filter a for-in loop doesn't arise that often; but, > b) When

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon wrote: > >> Upon accepting SE-0099, the core team is removing `where` clauses from >> condition clauses, writing "the 'where' keyword can be retired from its >> purpose as a boolean condition introducer." >> >>

Re: [swift-evolution] Add a while clause to for loops

> On Jun 7, 2016, at 1:16 PM, Tim Vermeulen via swift-evolution > wrote: > >> The meaning of the proposed while is not at all a pair for where, since >> where clauses in while loops would do the same thing as while clauses in for >> loops. That's crazy. > > It

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution > wrote: > > Second, I have really gotten use to not needing to use semicolons, and this > proposal seems to use/require them in very common situations. > > After shedding the requirement of

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 6:19 PM, Matthew Johnson wrote: >>> Also, can someone refer me to an example of this statement: "This proposal >>> resolves this problem by retaining commas as separators within clauses (as >>> used elsewhere in Swift) and introducing semicolons to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon > wrote: > >> guard >> x == 0 && a == b && c == d && >> let y = optional, w = optional2, v = optional 3 && >> z == 2 >> else { ... } >> >> Figuring out where to break the first line into expression and into >>

Re: [swift-evolution] [Pitch] #warning

> On May 29, 2016, at 1:44 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution >> wrote: >> >> I appreciate the sentiment, but I think we should reserve warnings for >>

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0050: Decoupling Floating Point Strides from Generic Implementations

> On May 30, 2016, at 4:10 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> The core team believes that the existing strideable API cannot efficiently >> and correctly handle all the real-world use cases one would want. However, >> a multiplication-based

Re: [swift-evolution] Ad hoc enums / options

> Begin forwarded message: > > From: Christopher Kornher > Subject: Fwd: [swift-evolution] Ad hoc enums / options > Date: May 31, 2016 at 12:25:33 PM MDT > To: Erica Sadun > > Apologies for using you as a relay... > >> Begin forwarded message: >> >>

Re: [swift-evolution] Ad hoc enums / options

>> I have two suggested “improvements” >> >> 1) Make the enum String raw-representable. Name it somehow. This does not >> affect Erica’s original syntax. >> 2) Force an explicit name. >> >> class MyImage { >> func scaleAndCropImage( >> image: UIImage, >> toSize

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 11:16 AM, Xiaodi Wu wrote: > > The motivating example is a compelling illustration of a problem with the > current grammar. I don't think anyone would disagree that `if let y = y where > x < z` is an abomination. > > Now, I see no principled

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 10:24 AM, Charlie Monroe > wrote: > > Most ideas discussed here lately cannot be used from ObjC. That is a fair point. It may be reasonable to add an ObjC interop section to the proposal template. At the same time, I'm not sure the core

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 3:20 PM, Brent Royal-Gordon > wrote: > >> func scaleAndCropImage( >>image: UIImage, >>toSize size: CGSize, >>operation: (.Fit | .Fill) = .Fit >>) -> UIImage { > > As I said the last time this proposal came up, I think this is great

Re: [swift-evolution] Working with enums by name

> On May 31, 2016, at 4:07 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> • also wants OptionSetType-like behavior (and thus an Int raw type). > > Then it's not an `enum`, it's a `struct`. You can get it for free as an array of enums and test with

Re: [swift-evolution] [Pitch] Circling back to `with`

On May 25, 2016, at 5:34 PM, Dany St-Amant <dsa@icloud.com> wrote: > Le 25 mai 2016 à 14:28, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : > >> Over the past couple of days, the Twitters have

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution > wrote: > >> • What is your evaluation of the proposal? > > +1. I believe it improves the clarity of condition clauses and as the > proposal suggests, I think it will make it easier for

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On May 27, 2016, at 1:47 PM, Matthew Johnson wrote: > >> >> On May 27, 2016, at 2:37 PM, Erica Sadun > > wrote: >> Given the whole newline groundswell that has emerged on SE, I did consider >> it but when I mocked up

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Supporting Dave A, type-based calls are much more likely to be used than instance calls, unlike with dynamicType/type(of:) Termstdlib search gist search Google site:github +swift sizeof 157 169 4880 sizeofValue 4 34 584 alignof 44 11 334 alignofValue

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 10:12 AM, Matthew Johnson wrote: >> On Jun 2, 2016, at 11:04 AM, Erica Sadun > > wrote: >>> On Jun 2, 2016, at 9:48 AM, Matthew Johnson via swift-evolution >>>

[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Upon accepting SE-0098, the core team renamed the proposed stdlib function from dynamicType() to type(of:). They write, "The core team recognizes that this means that we should probably resyntax the existing sizeof/strideof functions, but that should be a follow-on discussion." Follow on

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 1, 2016, at 11:10 PM, Xiaodi Wu wrote: > > On Thu, Jun 2, 2016 at 12:03 AM, Jacob Bandes-Storch > wrote: > If it's worth continuing the discussion in this thread, I rather like the > MemoryLayout.size idea. For

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 1, 2016, at 10:55 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Upon accepting SE-0098, the core team renamed the

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Using MemoryLayout is a much bigger change than the simple name changes being pitched here. I'm not ruling it out, but it may be deferred or additive as the 3.0 timeline allows and the core team decides. For now, my suggested design (strongly based on Wux's feedback and the previous thread

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 12:35 PM, Matthew Johnson wrote: > > I think I'm -1 on this. It makes things easier for the implementer of the > function and harder for the caller. > > It's not clear whether the caller could store an argument to pass in a > variable, but if

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 12:52 PM, Xiaodi Wu wrote: > These lines of reasoning are what have compelled me to conclude that `where` > might not be salvageable. To which, I'd add: `where` suggests there's a subordinate and semantic relationship between the primary condition

Re: [swift-evolution] [Pitch] Expose assert configuration functions in standard library

Or, to be honest: /// Offers user-facing public assert configuration test @_transparent public func isDebugAssertConfiguration() -> Bool { return _isDebugAssertConfiguration() } which covers, I believe, about 98% of the demand for this feature -- E > On May 31, 2016, at 11:21 PM, Brent

Re: [swift-evolution] [Pitch] Expose assert configuration functions in standard library

> On Jun 1, 2016, at 9:15 AM, Erica Sadun wrote: > > Or, to be honest: > > /// Offers user-facing public assert configuration test > @_transparent > public > func isDebugAssertConfiguration() -> Bool { > return _isDebugAssertConfiguration() > } > > which covers, I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 4:48 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 27, 2016, at 12:11 PM, Joe Groff > > wrote: >> >> Hello Swift community, >> >> The review of SE-0099 “Restructuring Condition

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

> On May 30, 2016, at 2:39 PM, Chris Lattner via swift-evolution > wrote: > >> On May 30, 2016, at 6:01 AM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> // Proposed syntax: >> func takes(a (valueA, valueB): (Int, Int)) { >> //

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

> On May 30, 2016, at 2:19 PM, Frédéric Blondiau via swift-evolution > wrote: > > I personally never found that this “$n” convention was “Swift-like”... but > it’s true that a “$n” is easier to spot than a “.n”, and I got used to also. > > However, I realised how

[swift-evolution] Ad hoc enums / options

Here's a function signature from some code from today: func scaleAndCropImage( image: UIImage, toSize size: CGSize, fitImage: Bool = true ) -> UIImage { And here's what I want the function signature to actually look like: func scaleAndCropImage( image: UIImage, toSize

[swift-evolution] [Pitch] Expose assert configuration functions in standard library

Back in March, I somewhat foolishly agreed to pick up the gauntlet for a series of community-requested proposals centered on build configurations. Requested items included: A way to test for destination platforms like Apple, Linux, Windows, Unix-like, UIKit-supporting, etc A way to test for

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 10:05 AM, Nate Cook wrote: > Pull Requests > > Additive > #346 Introducing with to the Standard Library Yeah, mea culpa -- but mea culpa with a reason. Method cascades are not going to be in 3. This is intentionally a stop-gap additive

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

> On Jun 22, 2016, at 8:36 AM, Adrian Zubarev via swift-evolution > wrote: > > I’d love to see something like this happen to Xcode. I’m curious if we could > write an extension for Xcode 8 to refactor code to at least some of the > conventions. > I don't believe

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 10:09 AM, Matthew Johnson wrote: > >> >> On Jun 22, 2016, at 10:59 AM, John McCall > > wrote: >> >> >>> On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution >>>

[swift-evolution] Revisiting SE-0041 Names

Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md Rejection: "The feedback on the proposal was generally positive about the

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jun 21, 2016, at 6:06 PM, Dave Abrahams wrote: > > It's just that I don't think this part of the library API is important > enough, to enough people, that this readability is worth the additional > exposed surface area (and further exposure later on—I can easily

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jun 21, 2016, at 7:07 PM, Dave Abrahams wrote: > > > on Tue Jun 21 2016, Erica Sadun > wrote: > >>> On Jun 21, 2016, at 6:06 PM, Dave Abrahams wrote: >>> >>> It's just that I don't think this part of the

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 22 2016, Erica Sadun wrote: >> >> No, I'd do edits on a gist page not in-place > > Then feel free, of course! It's your choice, y'know. I

  1   2   3   4   5   6   >