[swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

Pull request: https://github.com/apple/swift-evolution/pull/681 Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Al

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

or other teammates drops *significantly*. I argued this about >> scoped private as well, but the core team felt that it had legitimate enough >> use by a large enough number of people. On the other hand, I can't imagine >> that this would hold its weight in terms of valu

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Apr 21, 2017 at 8:48 AM, Robert Bennett via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Xiaodi, I think one thing you're neglecting is that users may never print out > a multiline literal stri

[swift-evolution] [Pitch] Build configuration tests

I'm going to throw this back out into the SE arena to see if there's still interest in these. https://github.com/apple/swift-evolution/pull/369 It seems to me that many of these are already incorporated into the language as private calls, an

Re: [swift-evolution] [Pitch] Build configuration tests

> On Apr 24, 2017, at 7:59 PM, Ben Rimmington wrote: > > >> On 24 Apr 2017, at 21:07, Erica Sadun wrote: >> >> I'm going to throw this back out into the SE arena to see if there's still >> interest in these. >> >> https://github.com/apple/swift-evolution/pull/369 >> >> It seems to me that

Re: [swift-evolution] [Pitch] Build configuration tests

save on having a new word for this: just have an optional > argument in OS, since we're really asking is this "iOS" really the "iOS > Simulator"? That is: `#if os(iOS, simulator)` vs `#if os(iOS, device)`. We > can even have the compiler reject conditions such as

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On May 4, 2017, at 8:14 PM, Robert Widmann via swift-evolution > wrote: > > Hi all, > > So sorry that this proposal comes so late in the game, but I feel it’s too > important not to bring it to the attention of the community now. Attached is > a proposal to deprecate a language feature ma

[swift-evolution] Quick question: Constraint Aliasing

Can anyone give me a rough estimate of how hard (in terms of coding, not in terms of Swift Evolution process) it would be to adopt (1) `extension Set` as an outright alias for `extension Set where Element == ShippingOptions` and (2) `extension [ShippingOptions]` for `extension Array where Eleme

Re: [swift-evolution] VisualFoundation Framework

These are inherently cross-platform concepts that can be represented both as literals (like the current color, file, and image) or as Swift-specific types, allowing the realization details to be pushed to platforms (macOS, iOS, common linux libraries). Some ideas about literals here: https://g

Re: [swift-evolution] [Proposal] Factory Initializers

Any chance at a 4.1 or a 4.2 round this year? -- E > On Jun 5, 2017, at 1:16 AM, Xiaodi Wu via swift-evolution > wrote: > > I hope so! We'll have to wait a bit for the core team to outline Swift 5 > priorities. > > > On Mon, Jun 5, 2017 at 00:24 Pranshu Goyal

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 11, 2017, at 3:41 PM, Haravikk via swift-evolution > wrote: > > >> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I agree, this makes focusing on the right types of changes much easier and >> helps us avoid turning S

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 2:07 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jun 13, 2017 at 1:18 AM, Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>>

[swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Some pals and I have been kicking an idea around about introducing better ways to support the compiler in protocol extensions. We want to eliminate some hard-to-detect bugs. We've been brainstorming on how to do this without affecting backward compatibility and introducing a minimal impact on ke

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 14 2017, Chris Lattner wrote: > >>> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>> wrote: >>> >>> Some pals and I have be

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

M, David Hart wrote: > > Erica, any thoughts on only having default and making it an error in a future > version of Swift like was discussed on this thread? The idea seems to have a > few supporters. > >> On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution >>

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

hich is the consequence of the one >> keyword solution. >> >> -- E >> >>> On Jun 16, 2017, at 7:44 AM, David Hart >> <mailto:davidh...@fastmail.com>> wrote: >>> >>> Erica, any thoughts on only having default and making it an error in a >&

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 16, 2017, at 12:21 PM, Tino Heth <2...@gmx.de> wrote: > > The described problem might be one of the most famous itches of the language, > but imho the bar for new keywords* should be higher than that — and there are > alternatives: > > First, I guess many would like to see this to be

[swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

Using an operator to provide feedback on the context of a failed unwrap has become a commonly implemented approach in the Swift developer Community. What are your thoughts about adopting this widely-used operator into the standard library? guard !lastItem.isEmpty else { return } let lastItem =

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 27, 2017, at 1:51 PM, Dave DeLong via swift-evolution > wrote: > > >> On Jun 27, 2017, at 1:43 PM, Tony Allevato via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I agree with Jaden and Xiaodi above—making Never a proper bottom type and >> using ?? would accomp

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

t;>>>> As you write, this operator becomes sugar for “?? fatalError()” once >>>>> Never becomes a true bottom type. >>>>> >>>>> In the meantime, can’t the same thing be accomplished by overloading >>>>> fatalError so it’s a generic

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 3:52 AM, Yuta Koshizawa via swift-evolution > wrote: > > Hi, I think it is an orthogonal issue if we need a new operator. It is > also possible to introduce an infix `!` for it. > > I am sure that we do not need to avoid `precondition` as long as we > use it appropriately

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

Based on the feedback on this thread, I'm coming to the following conclusions: `!!` sends the right semantic message. "Unwrap or die" is an unsafe operation. It is based on `!`, the unsafe forced unwrap operator, and not on `??`, the safe fallback nil-coalescing operator. Its symbology should th

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 3:46 PM, Jordan Rose wrote: > > > >> On Jun 28, 2017, at 14:40, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> The `!!` operator should follow the same semantics as >> `Optional.unsaf

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 6:26 PM, Xiaodi Wu wrote: > > On Wed, Jun 28, 2017 at 5:05 PM, ilya via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > One could, for example, extend the existing documentation markup sign /// to > pick up text as force unwrap messages: > > `let last =

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

On Jun 28, 2017, at 6:43 PM, Alan Westbrook via swift-evolution wrote: > > >> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> In the initial example, repeated here in largely identical form, the desired >> comment is "array must b

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 29, 2017, at 9:13 AM, Dave DeLong wrote: > > My usage of “!!” generally falls in to two big buckets: > I've incorporated all the feedback to date and updated the gist: https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

lack Swan Deployment” > references a “Mackintosh” - I believe this was supposed to be “Hackintosh”. > > >> On 30 Jun 2017, at 3:20 am, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jun 29, 2017, at 9:13 AM, D

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

t is my biggest concern but I believe that can be surmounted. -- E > On Jun 29, 2017, at 11:23 PM, Brent Royal-Gordon > wrote: > >> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Usi

Re: [swift-evolution] https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md

> On Jul 9, 2017, at 4:30 PM, Mario Duran wrote: > > Worst Idea Ever. Thank you for your feedback. If you'd like to learn more about Swift and its open sourced evolution process, please check out swift.org and see how you can become a contributor and an active voice in t

Re: [swift-evolution] Change default compiler fix for not-unwrapped Optional from ! To ?

> On Jul 14, 2017, at 2:11 AM, Víctor Pimentel via swift-evolution > wrote: > >> On 14 Jul 2017, at 08:05, Rod Brown via swift-evolution >> wrote: >> >> >> >>> On 14 Jul 2017, at 2:36 pm, Robert Bennett via swift-evolution >>> wrote: >>> >>> When writing Swift code, it is not uncommon t

Re: [swift-evolution] [Pitch] Throwing unwrap operators

From 2016: See: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160404/014272.html and https://gist.github.com/erica/5a26d523f3d6ffb74e34d179740596f7

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

When moving to a forum, the problem becomes a thread splintering to an overwhelming tree. I'd prefer to see a single primary thread (as in the mailing lists) with breakout threads for working groups. These could be built either around already identified areas (see manifestos) or future direction

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution > wrote: > > Perhaps I am too optimistic, and core team members correct me if I am > speaking out of turn here, but… > > I imagine that the core team will assist in providing implementations for > proposals that are crucial to t

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

Also, for those of you here who haven't heard my previous rant on the subject, I dislike using map for generating values that don't depend on transforming a domain to a range. (It has been argued that `_ in` is mapping from `Void`, but I still dislike it immensely) Here are the ways that I have

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

> On Aug 17, 2017, at 12:04 PM, Max Moiseev wrote: > > >> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Also, for those of you here who haven't heard my previous rant on the &g

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

main to a range. I’m not sure I > understand what wins are to be had by having “collect {}” as a synonym for > “map { _ in }”. > > On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Aug 17, 2017, at 12:04

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

oes project from a domain to a range. I’m not sure I >> understand what wins are to be had by having “collect {}” as a synonym for >> “map { _ in }”. >> >> On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrot

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

e would just contain its count and > pretty much fake its collection interface, in the sense that no elements are > actually stored. Then you could do Count(3).map { UIView() } > > On Aug 17, 2017, at 9:06 PM, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

> On Aug 17, 2017, at 7:38 PM, Xiaodi Wu wrote: > > On Thu, Aug 17, 2017 at 8:25 PM, Erica Sadun > wrote: > `repeatElement((), count: 5)` is better than `1 ... 5`, but `Count(3).map({ > UIView() })` is far more elegant. I'd still probably go with an array > initi

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

> On Aug 17, 2017, at 9:29 PM, Taylor Swift wrote: > On Thu, Aug 17, 2017 at 9:06 PM, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote: >>

Re: [swift-evolution] [Pitch] making where and , interchangeable in guard conditions.

Right now, if you look at the grammar, it's pretty hard to follow and special cased. I think if people follow an intentional pattern of a condition per line (including where clauses) they won't get in trouble. (Also Swift is a lot smarter about inadvertent = vs ==) -- E > On May 24, 2016, at

Re: [swift-evolution] [Pitch] making where and , interchangeable in guard conditions.

27;. > > To be fair, though, since assignment in Swift doesn't return the new value as > it does in C, there is far less room for disastrous bugs caused by this sort > of mistake. > > Austin > > > > On Fri, May 20, 2016 at 10:07 AM, Erica Sadun via sw

Re: [swift-evolution] [Pitch] making where and , interchangeable in guard conditions.

n "if let x = y, z = q, ..."? I always use "let" > anyway; I think it's easier to read. > > On Tue, May 24, 2016 at 11:42 AM, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Okay, and here is where the problem is (thanks Chris

[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: https:

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 :help for assistance. >1>

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

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> Over the past couple of days, the Twi

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 dates from a time when the >> c

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> I like this pretty well, and I think "with()" makes sense as a peer of >> "withUnsafePointer()", "withExtendedLife

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 way to duplicate/modify value types to be >> st

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

> On May 25, 2016, at 9:37 PM, Chris Lattner via swift-evolution > wrote: > Swift currently accepts a trailing comma in array and dictionary collection > literals, for three reasons: evolution of a project often adds and removes > elements to the collection over time, these changes do not alt

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 programmers to learn > and under

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

On May 25, 2016, at 5:34 PM, Dany St-Amant wrote: > Le 25 mai 2016 à 14:28, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> a écrit : > >> Over the past couple of days, the Twitters have discovered some work I'd >> done on closure-based set

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 examples, it felt less readable and I suspect it

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

On May 27, 2016, at 5:35 PM, Brent Royal-Gordon via swift-evolution wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md > >> • What is your evaluation of the proposal? > > Oof. > > I am not a fan of this syntax. `;` reads v

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 semicolons from ObjC…now we will have

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 separate distinct >>> k

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 >> condition (after the `d`) could

[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 Sim

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 >> actual compiler diagnostics. > > +1. The IDE should j

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 implementation similar to the

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 Clauses” begins now and runs >> through June 3, 2016

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)) { >> // use valueA >> // use valueB >> } > > FWIW, Swift 1 sup

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 much this was disturbing for

[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 si

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

On May 31, 2016, at 10:20 AM, Kevin Nattinger wrote: > > Definitely an interesting idea, and I like it, but how would this be used > from Objective C? Interop is a separate question. I'm sticking mostly to pure Swift these days, or doing all my calls from Swift. In such a light, it falls unde

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 Swift team has made it clear how

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 criteria, and none have been

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: >> >> From: Charlie Monroe via swift-evolution

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 si

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 and the clause. There's

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 they could they would nee

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 right up > until the mo

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 contains vs member -- E, who has p

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 Royal-

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 believe, about 98% of the d

[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 discu

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

> On Jun 1, 2016, at 10:55 PM, Xiaodi Wu wrote: > > On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Upon accepting SE-0098, the core team renamed the proposed stdlib function > from dynamicType() to type

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 discoverability, we might want to have > @avai

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 disc

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

And following up to myself. Please look here: https://github.com/erica/swift-evolution/blob/0f93c3c31b1d59358a61a5e2608dc71a598d9316/proposals/-sidestride.md Plus, I fixed the typos in strideof/strideofValue's counts. -- E > On Jun 2, 2016, at 8:43 AM, Erica Sadun via swift-e

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

> On Jun 2, 2016, at 9:48 AM, Matthew Johnson via swift-evolution > wrote: > > struct MemoryLayout { > init() {} > init(t: T) { /* throw away the value */ } > > // we could omit the static properties and require > // writing MemoryLayout() if we don’t like the duplication

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> struct MemoryLayout { >>> init(

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 >> > wrote: >>> On Jun 2, 2016, at 12:01 PM, John McCall >

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 'UnsafeMutablePointer' vs '*T'. > Verbosity

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> I still think the value-based APIs are misleading and that it would be >> better to ask people to just use a type explicitly

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 >> mailto:swift-evolution@swift.org>> wrote: > > Yes, I think that it is

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

> On Jun 2, 2016, at 3:35 PM, Tony Allevato via swift-evolution > wrote: > > On Thu, Jun 2, 2016 at 2:25 PM Xiaodi Wu > wrote: > On the other hand, on its own sizeof() is not unsafe, and so the argument > that it should be longer to call attention to itself (by ana

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 'UnsafeMutablePointer' vs '*T'. >>

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 R

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 inheritin

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 ints, with .a=1, .b=2, > .c=1,

[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 ca

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 scope. In your example the

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 sounds crazy, but it’s the natu

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 are already allow

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 type inference for dropped pre

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

> On Jun 7, 2016, at 9:37 PM, Chris Lattner wrote: > > >> On Jun 6, 2016, at 8:35 AM, Erica Sadun via swift-evolution >> wrote: >> >> Did we ever get to a stopping point on SE-0045, with the take while / drop >> while methods? I remember we were

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

> On Jun 8, 2016, at 12:05 AM, Chris Lattner wrote: > >> >> On Jun 7, 2016, at 9:54 PM, Erica Sadun wrote: >> >> >>> On Jun 7, 2016, at 9:37 PM, Chris Lattner wrote: >>> >>> >>>> On Jun 6, 2016, at 8:35 AM, Erica Sa

  1   2   3   4   5   6   7   >