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

[Erica Sadun via swift-evolution]

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. Although this proposal is primarily additive, 
we feel it might just squeak in under Swift 4's gate as it targets potentially 
harmful language issues.

We appreciate your feedback about the substance of the proposal. At this time, 
we're not looking for bikeshedding on design details. We will welcome that once 
the question of whether the proposal is sufficiently substantive is settled.  

Given the extremely limited timeline and the high volume of list traffic, we're 
looking for specific concerns (or benefits) you see in this pitch instead of a 
flurry of "+1" and "-1" responses . Our primary question regards whether this 
is a suitable approach (it is strongly influenced by SE-0077) and flexible 
enough to cover at least some outstanding concerns raised in list threads over 
the past weeks.

Thank you in advance for your feedback,

-- Erica

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

 team have complete control over—the value of being able to protect yourself 
>> from yourself 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 value-added vs. implementation 
>> complexity and difficulty it would add to making the language readable and 
>> learnable.
>> 
>> On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Pull request: https://github.com/apple/swift-evolution/pull/681 
>> <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. Although this proposal is primarily 
>> additive, we feel it might just squeak in under Swift 4's gate as it targets 
>> potentially harmful language issues.
>> 
>> We appreciate your feedback about the substance of the proposal. At this 
>> time, we're not looking for bikeshedding on design details. We will welcome 
>> that once the question of whether the proposal is sufficiently substantive 
>> is settled.  
>> 
>> Given the extremely limited timeline and the high volume of list traffic, 
>> we're looking for specific concerns (or benefits) you see in this pitch 
>> instead of a flurry of "+1" and "-1" responses . Our primary question 
>> regards whether this is a suitable approach (it is strongly influenced by 
>> SE-0077) and flexible enough to cover at least some outstanding concerns 
>> raised in list threads over the past weeks.
>> 
>> Thank you in advance for your feedback,
>> 
>> -- Erica
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 string at all. A string might never be printed or read by 
> a human outside of the code it resides in. In this case it seems perfectly 
> reasonable to ask that it be possible to format the string nicely in the code 
> and disregard how it would actually be printed.
> 
> Can you give an example of such a use case, where a string is never seen by a 
> human but one cannot insert literal newlines and would need elided ones 
> instead?

The most common reason is that the code is maintained by a (non-human) 
developer, who wants to be able to see and update the code in a readable form, 
but that represents a single line that will automatically wrapped by, for 
example, a UITextView for (human) consumption. 

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Build configuration tests

[Erica Sadun via swift-evolution]

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, and would only need minimal coding. Given the extremely limited 
timeline and the high volume of list traffic, I'm looking for specific concerns 
(or benefits) you see in this pitch. 

Thank you,

-- Erica

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 many of these are already incorporated into the language 
>> as private calls, and would only need minimal coding. Given the extremely 
>> limited timeline and the high volume of list traffic, I'm looking for 
>> specific concerns (or benefits) you see in this pitch.
> 
> Instead of:
> 
>   ```swift
>   #if interop(objc)
>   // Code that depends on Objective-C
>   #endif
>   ```
> 
> Would the following be equivalent?
> 
>   ```swift
>   #if canImport(ObjectiveC)
>   // Code that depends on Objective-C
>   #endif
>   ```
> 
> Could the `canImport(ObjectiveC)` test also replace the `vendor(Apple)` test?
> 
> -- Ben
> 

It probably could replace that -- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Apr 24, 2017, at 4:19 PM, Xiaodi Wu  wrote:
> 
> I'm glad you've resurrected this idea. I think it's worth thinking about, 
> certainly. At the moment, I do have some thoughts, some of which I may have 
> already had but have now forgotten. They're more notions than objections, but 
> I'll share them as they are:
> 
> * The new integer protocols now provide `bitWidth` (note the spelling) on all 
> fixed-width integer types. Since Int is defined as 32 bits on 32-bit 
> platforms and 64 bits on 64-bit platforms, it is possible to write `if 
> Int.bitWidth == 64 { ... }`. It isn't a conditional compilation block as 
> written, but as I understand it, the compiler either already does or should 
> be able to make it effectively a compile-time conditional. The question 
> remains if an explicit conditional compilation feature with a subtly 
> different spelling makes possible significant additional use cases. I don't 
> know the answer, but I think it's worth re-considering in light of the new 
> protocols.
> 

The requests were community driven. I'd defer to the community to decide 
whether compile-time conditional blocks or runtime would be better here.

> * The new integer protocols had one chunk sent back for revision, which 
> consist of the parts about endianness. I think it might be wise to see how 
> that plays out before considering a conditional compilation feature, for the 
> reason that we may end up with a scenario similar to the one with `bitWidth`.

nod.

> * I have concerns about `vendor`. I get that it (a) allows you to write 
> something much shorter than `os(macOS) || os(iOS) || os(tvOS)`; and (b) lets 
> you anticipate any future OS from the same vendor. But two issues that come 
> to mind here are as follows. (1) In the Apple world, there's one vendor for 
> multiple platforms, but in the Linux world, there'd be many vendors for one 
> platform. It's unclear to me _how_ one might use `vendor` profitably when 
> it's so different. Is the only or main practical use envisioned here a 
> shorthand for Apple platforms? If so, couldn't we cut the pretense and just 
> write `#if apple`? (2) I get that part of the motivation is that Apple may 
> introduce a new platform and they often re-use their technologies, and it'd 
> be nice to get your code working "for free" on a new platform. However, it 
> seems to me that this would be unwise as a language feature. There are no 
> guarantees at all about what a future Apple platform will look like. In other 
> words, if `vendor(Apple)` is to evaluate `true` for every Apple OS, it is a 
> meaningless condition, as Apple makes no guarantees whatsoever about 
> commonalities between its current and future platforms, and one cannot reason 
> at all about code written for such a scenario.
> 
> * Intuitively, `interop` seems fine, but I don't have much experience with 
> Obj-C interop.
> 
> * I think a better option than testing the difference between `arch` and `os` 
> would be great for detecting a simulator. I also think--just to bikeshed a 
> little--we can 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 `#if os(macOS, 
> simulator)` if we want.


At this point, I'm just probably going to backburner this as well. No one seems 
particularly interested in it.

-- E


> 
> 
> On Mon, Apr 24, 2017 at 3:07 PM, Erica Sadun via swift-evolution 
> mailto:swift-evolution@swift.org>> 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 
> <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, and would only need minimal coding. Given the extremely 
> limited timeline and the high volume of list traffic, I'm looking for 
> specific concerns (or benefits) you see in this pitch. 
> 
> Thank you,
> 
> -- Erica
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 many of you will probably have 
> never had the chance to use: Tuple Shuffles.  I’ve attached a copy of the 
> first draft of the proposal below, but the latest copy can be read on Github 
> .
> 
> Thanks!
> 
> ~Robert Widmann
> 

I'm coming into this ridiculously late. Apologies, but I've had family 
responsibilities. I've tried to read through the thread before replaying. I 
hope I have not missed any significant points.

First, I dislike calling this "tuple shuffles". That phrase has an existing and 
useful meaning in the Swift community. It refers to what this proposal calls 
"re-assignment through a tuple pattern". This is what I want to keep calling a 
"tuple shuffle":

`(a, b, c) = (b, c, a)`

I'd rather call the problem space for this proposal "label-led tuple 
assignment" (or something like that) and reserve "tuple shuffle" for reordered 
value reassignment.

Second, I agree with TJ. I dislike that this pattern is legal:

```
// Declare using labels
let rgba: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)

// Declare using re-ordered labels
let argb: (a: Int, r: Int, g: Int, b: Int) = rgba // This is the line I have 
issue with

print(argb.a) // "0"
```

I find this usage counter to Swift's philosophy of clarity and simplicity. It 
is sufficiently obscure that I consider it a non-standard use regardless of 
Wux's  Google search results. 

Consider the example of Joe Groff's SE-0060 
(https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md
 
).
 I believe it's reasonable to mandate that the order of labels in declarations 
be ignored, with the types being compiler-checked.  I'd envision that the 
"correct" behavior should act like this instead:

```
// Declare using re-ordered labels
let argb: (a: Int, r: Int, g: Int, b: Int) = rgba // (Int, Int, Int, Int) 
assigned to (Int, Int, Int, Int)

print(argb.a) // "255"
```

This reworking is partially inspired by SE-0111 
(https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
 
),
 ensuring that the tuple argument labels are not considered in typing the new 
constant. In fact, this entire proposal might be better named "Removing the 
Ordering Significance of Tuple Argument Labels in Declarations"

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Quick question: Constraint Aliasing

[Erica Sadun via swift-evolution]

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 Element == ShippingOptions`?

Thanks,

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] VisualFoundation Framework

[Erica Sadun via swift-evolution]

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://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c 

Some ideas about types and functionality for core graphics here: 
https://github.com/erica/SwiftGeometry/tree/master/Sources 


If this idea has traction, it probably needs to be a separate development list 
or working group.

-- E


On Jun 1, 2017, at 5:33 AM, Jonathan Hull via swift-evolution 
 wrote:
> 
> I am not suggesting open sourcing UIKit or Cocoa (or any platform specific UI 
> code).  I am suggesting creating a very small open source swift-corelib that 
> sits on top of foundation, and adds basic visual concepts like Color, Image, 
> AttributedText, and (hat tip to T.J.) BezierPaths.  Things where the concepts 
> themselves are completely cross-platform, and they really should be in 
> foundation, except that they are visual concepts, and thus got packaged with 
> the whole platform framework for historical reasons.
> 
> Thanks,
> Jon
> 
>> On Jun 1, 2017, at 2:53 AM, Alex Blewitt > > wrote:
>> 
>>> On 1 Jun 2017, at 09:57, Jonathan Hull >> > wrote:
>>> 
>>> I could be wrong, but my understanding is that Foundation is being open 
>>> sourced as well, and distributed with Swift across various platforms.
>> 
>> It is already open source; the source code for the Swift/Linux port is here:
>> 
>> https://github.com/apple/swift-corelibs-foundation 
>> 
>> 
>> However, Foundation has never contained any UI code, which on macOS is in 
>> the Cocoa framework and on iOS in the UIKit framework. These are both Apple 
>> frameworks, which you can discuss on the Apple mailing lists. To find the 
>> appropriate one, you can consult https://lists.apple.com/mailman/listinfo 
>>  - I would suggest the cocoa-dev 
>> mailing list.
>> 
>> Alex
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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  > wrote:
> Any hopes for it in future?
> 
> On 4 June 2017 at 20:40, Xiaodi Wu  > wrote:
> No.
> 
> 
> 
> On Sun, Jun 4, 2017 at 10:07 Pranshu Goyal via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Is this proposal in the pipeline for Swift 4?
> 
> On 1 April 2017 at 12:03, Adrian Zubarev via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> First, you should fix the indent in the code samples. Second, remove any 
> access modifier from inside a protocol. Third, we don’t support default 
> implementations directly inside protocols yet, so that’s a not valid example.
> 
> Now my personal concerns. As far as I can tell XIB files in an iOS Project 
> are meant for UIViewControllers in first place, but it’s a common case that 
> they are also used to create reusable UIViews. The downside of that abusage 
> is view hierarchy clustering. Most developer creating a view of Self in Self, 
> which smells to me like really bad code.
> 
> MyCustomView // This view is useless
>+ MyCustomView
>+ CustomSubview1
>+ CustomSubview1 // This is probably a dead IBOutlet
> In fact Xcode does not use the initializer from NSCoding to show a live 
> rendered view inside interface builder, instead it will call a UIViews 
> designated initializer init(frame:). That results that a lot of the developer 
> write similar code like in the following snippet:
> 
> // This pattern results in a similar view cluster like mentioned above
> 
> class MyCustomView : UIView {
> override init(frame: CGRect) {
> let view = loadSomehowFromNib()
> self.addSubview(view)
> }
> }
> To solve this problem we’d need some functionality of factory initializers. I 
> believe as proposed the factory initializer won’t solve that problem, because 
> everything would be still restricted to a special initializer annotated with 
> factory.
> 
> Personally I would want to write something like this instead.
> 
> class MyCustomView : UIView {
>  
> override init(frame: CGRect) {
>  
> // Instantiating from a Nib file will call `init(coder:​)` on 
> MyCustomView
> self = loadSomehowFromNib() // assuming () -> MyCustomView
>  
> //
> self.frame = frame
> }
> }
> This should resolve the clustering issue by assigning the returned instance 
> from the function to self and create a correct view hierarchy.
> 
> + MyCustomView
>+ CustomSubview1
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Hi again everyone!
>> 
>> Now that Swift 4 Stage 2 proposals are being considered, I thought it might 
>> be time to revisit this proposal and see if it might align with the goals 
>> set forth for Swift 4.
>> 
>> As a quick tl;dr, this proposal describes a new "factory initializer" that 
>> would allow you to return a value from an initializer. This would have 
>> several benefits, as mentioned in the proposal itself as well as throughout 
>> this mailing list. For convenience, here's a link to the proposal on GitHub: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>>  
>> 
>> 
>> Would love to hear any more comments on this proposal, and if we feel this 
>> is appropriate for considering for Swift 4 I'll happily re-open the pull 
>> request!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian > > wrote:
>> 
>>> i would appreciate this feature.
>>> 
>>> For unexperienced developers, its often hard to recognize *when* factory is 
>>> a good fit to do the job, and how exactly approach the implementation. I 
>>> imagine having this feature built into the language may help to choose and 
>>> implement factory when its the right thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Is there any chance of reviving this? It seems to me that since this would 
 require Swift initializers to be implemented internally in such a way that 
 they can return a value (as Objective-C init methods do), it may affect 
 ABI stability and thus may be germane to the current stage of Swift 4 
 development.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Recently, I proposed the idea of addin

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

[Erica Sadun via swift-evolution]

> 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 Swift into an incoherent conglomeration of random 
>> use-cases (*cough*, C#, *cough*).
>> Now, the question is: when will be the time to officially push the factory 
>> initializers proposal and which stage should it be targeting?
> 
> I think there's definitely a need for greater clarity; we could really do 
> with better announcements on the list itself as to when the new phase begins 
> and exactly what is in-scope, it also needs to be put more clearly on the 
> swift-evolution repository.
> 
> Thing is; people are going to have ideas when they have them, and want to 
> discuss them right away. I've been caught out numerous times with proposals 
> that are almost immediately rejected as out of scope, and still have no idea 
> when I'm supposed to resubmit them.
> 
> To be honest it's demoralising, as I find myself apathetic towards my own 
> ideas as I have no idea when to revisit them, and by the time I do I've 
> largely lost interest and moved on to other things.
> ___

This.

I am sitting on a number of ideas that I think have merit (in a non-random 
use-case non-C# way) and I have no idea when the right time will be to bring 
them up. Several were marked as "bring forward to Swift 4" and obvious that was 
never going to happen for them.

I think having a queue to submit "proposals for eventually", written when the 
inspiration is there, and having a core team review (say once a month or even 
once a quarter) of their viability for future Swift directions would be 
amazingly valuable.

An example: https://github.com/apple/swift-evolution/pull/369 


-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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>> wrote:
>> 
>> 
>> Perhaps the solution is not necessarily throttling proposals per se, but 
>> having some mechanism for routing a proposal to something other than either 
>> a review cycle or the freezer: “this needs manifesto-ing,” “this needs 
>> prototyping to measure impact on existing code,” “this needs to simmer and 
>> find its context before we work it into a proposal,” etc. (That’s related to 
>> Daryle’s original message.)
> 
> I feel like I’m missing some part of the motivation for this thread.  Let me 
> try to explain why:
> 
> Lets say you’re interested in proposing a new feature or idea today, and are 
> told that it is out of scope.  One of two things happen.  When the next 
> release comes around, either:
> 
> 1) if you’re still engaged with swift-evolution, you can bring it back up.
> 
> 2) if you’re not still engaged, it will get dropped unless someone else is 
> interested in championing it.
> 
> 
> What good does a “queue” of proposals in the freezer do?  In practice, 
> getting a proposal to happen frequently requires editing and iteration, not 
> to mention active discussion about motivation.  We have no shortage of 
> important proposals to get through in each release, why should we make it 
> easier for proposals with no active proponent?  Wouldn’t that just encourage 
> people to drop off “drive-by” proposals for ideas?
> 
> I think this goes to the discussion above about what kind of list this is to 
> be. We've got, on the one hand, a significant number of proposals of the 
> following sort: how should indexing into the middle of a grapheme be handled? 
> which integer protocols should have the bitwise operators? These require 
> editing and iteration, as you say, and very active back-and-forth discussion. 
> These days it seems these sorts of threads rarely gain the greatest 
> attention. The most useful kind of feedback in such a discussion would be a 
> detailed and robust critique; much less useful is the ever more common "+1," 
> and storing the proposal in a freezer is the surest way to irrelevance as the 
> detailed design can quickly become nonsensical due to even small changes 
> elsewhere.
> 
> There are, however, a significant number of conversations that, at base, are 
> declarations that there exists some problem or issue. It's not 
> straightforwardly a bug that can be filed, and it's not a user knowledge 
> issue that can be solved by a question to swift-users, but it's something 
> else that may require a language change. This is, of course, a perfectly 
> understandable state of affairs for which some forum should probably exist. 
> However, the "format" of Swift Evolution requires a proposed solution and 
> detailed design, so the author feels compelled to put down _something_ that 
> might alleviate the problem. Frequently, later in the discussion, the author 
> will reply that he or she isn't actually married to the proposed solution 
> and/or does not really know if the detailed design will work at all, but 
> wanted the community to acknowledge that a problem or issue exists and needs 
> attention. Critiquing the placeholder proposed solution and detailed design 
> is kind of beside the point, even though it's the ostensible purpose of this 
> list. If anything is helpful in this scenario, it would be feedback that 
> validates and expounds on the issue (or in the absence of that, "+1"). 
> However, there's not an iterative process that will take you from that point 
> to an implementable design. It might be, however, a topic that fits nicely 
> into a "queue" of some sort.
> 
> There's another class of conversations that, from what I can tell, boil down 
> to a request for a feature--often one that is highly desired by many people. 
> The feature doesn't yet exist because it would require extensive design and 
> implementation effort. Perhaps the author is unaware that the feature is 
> already widely desired, or perhaps the author simply wants to make it known 
> that they wish that it would take higher priority. The actual motivation for 
> starting a thread isn't the promotion of any particular design for the 
> desired feature, just the feature itself. Also a perfectly understandable 
> situation, and should be accommodated in some form, somewhere. However, Swift 
> Evolution requires a detailed design, so the author feels compelled to sketch 
> out some sort of placeholder; sometimes, the "detailed design" recites more 
> and more elaborate variations of the feature but makes no attempt to actually 
> describe how it will come to be. Again, little point in critiquing it. Again, 
> there's not an iterative process from there to implementable design. This 
> 

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

[Erica Sadun via swift-evolution]

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 keywords. 

We'd love to know what you think of our idea, which is to introduce "role" 
keywords. Roles allow the compiler to automatically check the intended use of a 
extension member definition against its protocol declarations, and emit errors, 
warnings, and fixits as needed.  We think it's a pretty straightforward 
approach that, if adopted, eliminates an entire category of bugs.

The draft proposal is here: 
https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4 


Thanks in advance for your thoughtful feedback,

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 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 keywords.
>>> 
>>> We'd love to know what you think of our idea, which is to introduce
>>> "role" keywords. Roles allow the compiler to automatically check the
>>> intended use of a extension member definition against its protocol
>>> declarations, and emit errors, warnings, and fixits as needed.  We
>>> think it's a pretty straightforward approach that, if adopted,
>>> eliminates an entire category of bugs.
>>> 
>>> The draft proposal is here:
>>> https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
>>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>
>>> 
>>> Thanks in advance for your thoughtful feedback,
>> 
>> +1 on the idea of this.  
> 
> ditto.  IMO it also makes the protocol extension much more expressive
> and easy to read.
> 
> -- 
> -Dave


Pull request: https://github.com/apple/swift-evolution/pull/724 
<https://github.com/apple/swift-evolution/pull/724>

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

As we say in our introduction, we're pitching the most conservative approach. 

The proposal was designed for minimal language impact. It chooses a 
conservative approach that can be phased in first over time and language 
release over more succinct alternatives that would impact existing code bases.

We discuss the one keyword version (which most of us are a fan of) in the 
alternatives. The core team has to decide how much they're willing to allow 
existing code to warn and/or break, which is the consequence of the one keyword 
solution.

-- E

> On Jun 16, 2017, at 7:44 AM, 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> on Wed Jun 14 2017, Chris Lattner >> <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>>> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution
>>>>> mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> 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 keywords.
>>>>> 
>>>>> We'd love to know what you think of our idea, which is to introduce
>>>>> "role" keywords. Roles allow the compiler to automatically check the
>>>>> intended use of a extension member definition against its protocol
>>>>> declarations, and emit errors, warnings, and fixits as needed.  We
>>>>> think it's a pretty straightforward approach that, if adopted,
>>>>> eliminates an entire category of bugs.
>>>>> 
>>>>> The draft proposal is here:
>>>>> https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4 
>>>>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>
>>>>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4 
>>>>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>>
>>>>> 
>>>>> Thanks in advance for your thoughtful feedback,
>>>> 
>>>> +1 on the idea of this.  
>>> 
>>> ditto.  IMO it also makes the protocol extension much more expressive
>>> and easy to read.
>>> 
>>> -- 
>>> -Dave
>> 
>> 
>> Pull request: https://github.com/apple/swift-evolution/pull/724 
>> <https://github.com/apple/swift-evolution/pull/724>
>> 
>> -- E
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 16, 2017, at 8:44 AM, David Hart  wrote:
> 
> Okay, I undertand. I’m just worried that the proposal is a net negative if 
> the keywords stay optional. I’ll mention it in more detail once we get to the 
> review period.
> 
> Thanks for the work on the proposal!!


I believe a breaking change has little chance of being accepted at this point 
in the language lifecycle. Adding opt-in compiler auditing to increase safety 
is, IMO, a net positive. It's a deliberate trade-off. We have included other 
designs to allow the core team to choose an alternative they feel is best for 
the philosophy and direction of Swift. This doesn't close the door to future 
language releases enhancing the concept, phasing out the second keyword, or 
introducing keywords for additional safety auditing.

I find it a dangerous philosophy to insist that any new proposal be 
ideologically pure. Imperfect proposals can still improve the language within 
the realities of the timelines, user base, and code base of the Swift 
community.  

-- E

> 
>> On 16 Jun 2017, at 16:33, Erica Sadun > <mailto:er...@ericasadun.com>> wrote:
>> 
>> As we say in our introduction, we're pitching the most conservative 
>> approach. 
>> 
>> The proposal was designed for minimal language impact. It chooses a 
>> conservative approach that can be phased in first over time and language 
>> release over more succinct alternatives that would impact existing code 
>> bases.
>> 
>> We discuss the one keyword version (which most of us are a fan of) in the 
>> alternatives. The core team has to decide how much they're willing to allow 
>> existing code to warn and/or break, which 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 
>>> 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 
>>>> mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> 
>>>>> On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution 
>>>>> mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> 
>>>>> on Wed Jun 14 2017, Chris Lattner >>>> <mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>>>> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution
>>>>>>> mailto:swift-evolution@swift.org>> wrote:
>>>>>>> 
>>>>>>> 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 keywords.
>>>>>>> 
>>>>>>> We'd love to know what you think of our idea, which is to introduce
>>>>>>> "role" keywords. Roles allow the compiler to automatically check the
>>>>>>> intended use of a extension member definition against its protocol
>>>>>>> declarations, and emit errors, warnings, and fixits as needed.  We
>>>>>>> think it's a pretty straightforward approach that, if adopted,
>>>>>>> eliminates an entire category of bugs.
>>>>>>> 
>>>>>>> The draft proposal is here:
>>>>>>> https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4 
>>>>>>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>
>>>>>>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4 
>>>>>>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>>
>>>>>>> 
>>>>>>> Thanks in advance for your thoughtful feedback,
>>>>>> 
>>>>>> +1 on the idea of this.  
>>>>> 
>>>>> ditto.  IMO it also makes the protocol extension much more expressive
>>>>> and easy to read.
>>>>> 
>>>>> -- 
>>>>> -Dave
>>>> 
>>>> 
>>>> Pull request: https://github.com/apple/swift-evolution/pull/724 
>>>> <https://github.com/apple/swift-evolution/pull/724>
>>>> 
>>>> -- E
>>>> 
>>>> ___
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 valid Swift:
> 
> protocol Foo {
>   func bar() {
>   print("Default implementation called")
>   }
> }

I think there's a lot of people who want this. I'd have to do a search through 
the archives but hasn't it been said that this isn't likely to happen soon?


-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 = array.last !! "Array must be non-empty"

Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 


Thank you for your thoughtful feedback, -- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 accomplish the same thing, and it's more general because it 
>> doesn't imply fatalError.
>> 
>> IMO, I don't think we should be making it *easier* to hide traps in our 
>> code. I don't think having to write a full guard/fatalError is all that bad 
>> a thing—on the contrary, I want major failure points to stick out when I 
>> read code. That being said, if some users want something like this, Never + 
>> ?? would get us there with something already planned for the language, 
>> rather than introducing a new operator (for which the bar should be set 
>> high).
> 
> I disagree that this is making hiding traps easier. It’s asking you to put in 
> two exclamation points instead of only one to force unwrap, along with an 
> explanation of why you think it’s ok to be doing so. That’s much more “in 
> your face” than “array.last!”.
> 
> Dave

This ties in pretty closely with my goals for the "roles" proposal. I want 
Swift to evolve towards clarifying developer intent both for code inspection 
and compilation support.

I honestly wouldn't mind having both solutions available.

-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

I'll give this a kick around as soon as I get a moment and revise. I am 
slightly concerned that we discussed variations of this in the past (throwing 
if memory serves, with `Error` on the rhs) and that it broke the expectations 
of nil-coalescing. 

In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can 
argue both ways, with the goal in reading code as "unwrap or die".

-- E

> On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution 
>  wrote:
> 
> The compatibility testing revealed no related errors. And the full test suite 
> only shows one that I listed already.
> 
> Max
> 
> 
>> On Jun 27, 2017, at 3:28 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> This solution is nifty indeed, and has the chief advantage of working.
>> On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev 
>>> mailto:adrian.zuba...@devandartist.com>> 
>>> wrote:
>>> 
>>> How about?
>>> 
>>> public func ?? (optional: T?, noreturnOrError: @autoclosure () throws -> 
>>> Never) rethrows -> T {
>>> switch optional {
>>> case .some(let value):
>>> return value
>>> case .none:
>>> try noreturnOrError()
>>> }
>>> }
>>> 
>> 
>> Yeah, I saw your email right after I sent mine =)
>> This works, I tried it and also ran the test suite. There was only one error.
>> 
>>   var s: String = ns ?? "str" as String as String // expected-error{{cannot 
>> convert value of type 'NSString?' to expected argument type 'String?'}}
>>  
>> ^~~~
>>  cannot 
>> convert value of type 'String' to expected argument type 'NSString'
>> 
>> 
>> I now wonder what the effect on the source compatibility suite would be:
>> https://github.com/apple/swift/pull/10639 
>> <https://github.com/apple/swift/pull/10639>
>> 
>> 
>> Max
>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution 
>>> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:
>>> 
>>>> 
>>>>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution 
>>>>> mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> 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 function that returns a discardable result 
>>>>> of type T, which in turn calls the Never-returning overload?
>>>> 
>>>> I like this idea more than adding an extra operator, but overloading 
>>>> fatalError won’t work now because of 
>>>> https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668
>>>>  
>>>> <https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668>
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution 
>>>>> mailto:swift-evolution@swift.org>> wrote:
>>>>> 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 = array.last !! "Array must be non-empty"
>>>>> 
>>>>> Details here:  
>>>>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>>>>> <https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b>
>>>>> 
>>>>> Thank you for your thoughtful feedback, -- E
>>>>> 
>>>>> ___
>>&g

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

[Erica Sadun via swift-evolution]

> 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. It is useful to realize consistent behavior with
> `Array`'s `subscript`, forced unwrapping `!`, `&+` and so on. In this
> context, `precondition` does not mean a general word "precondition"
> but the `precondition` function in the Swift standard library, which
> is removed when -Ounchecked.


How would the line run then? Would it simply act as a forced unwrapped under 
-Ounchecked? 

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 therefore follow 
`!` and not `?`. 

The `!!` operator should follow the same semantics as 
`Optional.unsafelyUnwrapped`, which establishes a precedent for this approach:

> "The unsafelyUnwrapped property provides the same value as the forced unwrap 
> operator (postfix !). However, in optimized builds (-O), no check is 
> performed to ensure that the current instance actually has a value. Accessing 
> this property in the case of a nil value is a serious programming error and 
> could lead to undefined behavior or a runtime error."

By following `Optional.unsafelyUnwrapped`, this approach is consistent with 
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#logic-failures
 


> "Logic failures are intended to be handled by fixing the code. It means 
> checks of logic failures can be removed if the code is tested enough.
Actually checks of logic failures for various operations, `!`, `array[i]`, `&+` 
and so on, are designed and implemented to be removed
when we use `-Ounchecked`. It is useful for heavy computation like image 
processing and machine learning in which overhead of those checks is not 
permissible."

The right hand side should use a string (or more properly a string autoclosure) 
in preference to using a `Never` bottom type or a `() -> Never` closure. A 
string provides the cleanest user experience, and allows the greatest degree of 
self-documentation. 

- A string is cleaner and more readable to type. It respects DRY, and avoids 
using *both* the operator and the call to `fatalError` or `preconditionFailure` 
to signal an unsafe condition:
`let last = array.last !! “Array guaranteed non-empty" // readable`
than: 
`let last = array.last !! fatalError(“Array guaranteed non-empty”) // 
redundant, violates DRY`

- A string allows the operator *itself* to unsafely fail, just as the unary 
version of `!` does now. It does this with additional feedback to the developer 
during testing, code reading, and code maintenance. The string provides a 
self-auditing in-line annotation of the reason why the forced unwrap has been 
well considered, using a language construct to support this.

- A string disallows a potentially unsafe `Never` call that does not reflect a 
serious programming error, for example:
let last = array.last !! f() // where func f() -> Never { while true {} }

- Although as several list members mention, a `Never` closure solution is 
available today in Swift, so is the `!!` operator solution. Neither one 
requires a fundamental change to the language.

- Pushing forward on this proposal does not in any way reflect on adopting the 
still-desirable `Never` bottom type.

> On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
> On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong  > wrote:
>> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Well the main debate is that, we all want early access to a feature that 
>> will be part of Swift as soon as `Never` becomes the bottom type. When this 
>> happens the `??` will automatically support the pitched behavior. Until then 
>> if we all agree that we should add it now in a way that will not break 
>> anything we can simply add an overload to `??` as I previously showed.
>> 
> 
> I believe we should add it now, but I like the recent observation that making 
> ?? suddenly become a potentially crashing operator violates the expectation 
> that ? is an indication of safety.
> 
> ?? does *not* become a potentially crashing operator. The *fatalError* (or 
> whatever else the user chooses to put there) on the right-hand side is the 
> crashing operation.
> 
> 
> On the other hand, the existing semantics of Swift are that ! is always 
> dangerous, so making !! be the a potentially crashing operator is much more 
> consistent with the language.
> 
>> There is no need for `!!` because it will fade in the future. If you think 
>> of `Never` as a bottom type now then `??` will already make total sense. The 
>> default value for T from rhs might be T or Never. 
> 
> I respectfully disagree with your absolute position on this topic. Even with 
> Never as a bottom type in the future, it would still be more convenient for 
> me to type:
> 
> let last = array.last !! “Array must be non-empty"
> 
> … than it ever would be to type:
> 
> let last = array.last ?? fatalError(“Array must be non-empty”)
> 
> 
> There is a very high bar for additions to the standard library—a new operator 
> added to the language is going to be around (1) forever

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

[Erica Sadun via swift-evolution]

> 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.unsafelyUnwrapped`, which establishes a precedent for this 
>> approach:
>> 
>> > "The unsafelyUnwrapped property provides the same value as the forced 
>> > unwrap operator (postfix !). However, in optimized builds (-O), no check 
>> > is performed to ensure that the current instance actually has a value. 
>> > Accessing this property in the case of a nil value is a serious 
>> > programming error and could lead to undefined behavior or a runtime error."
> 
> Note that 'unsafelyUnwrapped' does not perform the check in optimized builds 
> (like 'assert'), while '!' does (like 'precondition'). If we go with '!!', it 
> should behave like 'precondition', not 'assert'.
> 
> Jordan

Noted and will incorporate into updated text

Thanks, -- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 = array.last! /// Array guaranteed non-empty`
> 
> I did not call this out initially, but I feel like this is an important point 
> to address:
> 
> In the initial example, repeated here in largely identical form, the desired 
> comment is "array must be non-empty." In what way does that provide more 
> information than a bare `!`?

That is why I changed it back to my "guarantee" version when replying:

guard !array.isEmpty else { ... }
/* ... */
let finalElement  = array.last !! "Array guaranteed non-empty"

The expected unwrap behavior is clear and audited, even when other code appears 
between the guard statement and the explained forced unwrap. 

As you point out, it's senseless to annotate a logical assertion known to be 
true ("must be non-empty") unless that annotation enhances the expression of 
why and how this otherwise dangerous operation is taking place. That 
explanation forms the mission statement of the `!!` operator.

By explaining, the `!!` operator differs from the direct use of `!`. It 
explains a fact known to hold true that allows the lhs to safely unwrap. It 
provides this in a way that is succinct and readable. It naturally moves with 
the line of code it is part of. The adoption of `!!` has already broadly been 
integrated into any number idiomatic libraries. Coders have done so to 
differentiate an audited known fact from the stray `!`, which may or may not be 
followed by a comment.

One last point: it is not the mission of document comments to provide any role 
beyond annotation. They are not there to guarantee preconditions, assertions, 
or any other behavioral contracts. They merely document.

-- Erica



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 be non-empty." In what way does that provide more 
>> information than a bare `!`?
> 
> I’m going to second this sentiment with the feeling that the message is 
> seemingly redundant. It feels akin to the comment in this line of code:
> 
> let value = 1 // This value is set to 1
> 
> On an error, one gets the trap with the optional unwrapped message, and goes 
> to the code where they see what is being forced by assumption.
> 
> Does the message spelling out the code in natural language help?
> 
> Alan

I have replied to another email but will repeat the point here: The proposed 
`!!` operator differs from the direct use of `!` in that it explains a fact 
known to hold true, allowing the lhs to safely unwrap. 

The alternatives are:

* forced unwrap -- comments do not transfer to runtime, which leads coders to 
use:
* using guard with fatalError -- the !! operator provides an elegant sugared 
shortcut for this common code

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 


-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

Fixed. Finger slipped during spell correct and I thought I had backed up 
through enough items -- apparently I didn't. :(

-- E


> On Jun 29, 2017, at 2:29 PM, Rod Brown  wrote:
> 
> Thanks Erica. That looks great.
> 
> As a side-note, one of the sentences in “The Black 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, Dave DeLong >> <mailto:del...@apple.com>> 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 
>> <https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b>
>> 
>> -- E
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

These are all excellent points. I also feel they sidestep the motivation of the 
proposal. Even if there were a bottom `Never` and you could use `?? 
fatalError()`, I still think the language would benefit from `!!`.

As the language is right now, you can write your own "or die" function using a 
`guard` statement, overloading `??`, or implementing `!!`. Being able to 
duplicate an explanatory fail path isn't the point. Offering a best-practices 
alternative to `!!` that is easy to use, obvious to understand, and simple to 
adopt is.

As for the `#line` and `#file` issue, that 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:
>> 
>> 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 = array.last !! "Array must be non-empty"
>> 
>> Details here:  
>> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b 
>> <https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b>
>> 
>> Thank you for your thoughtful feedback, -- E
> 
> Finally found a few minutes to read this thread.
> 
> I'm a big fan of the `Never`-based approach. (I was before, but I am more so 
> now.) Here are the points I can see in its favor:
> 
> 1. It is extremely clear about what's happening—`!!` is another random 
> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
> fairly self-explanatory, and `??` is something you might already be using.
> 
> 2. It allows you to control the optimization behavior by using `fatalError`, 
> `preconditionFailure`, or `assertionFailure` as desired.
> 
> 3. If we later change `throw` from being a statement to being a 
> `Never`-returning expression, you could use `throw` on the right-hand side of 
> `??`.
> 
> 4. It supports other `Never`-returning operations, like `abort()` or 
> `exit(_:)` or your custom `usage()` function, on the right side of `??`.
> 
> 5. It supports file-and-line error reporting without having to add any new 
> features; `!!` could not do this because an operator can't have extra, 
> defaulted parameters to carry the file and line.
> 
> 6. It harmonizes with the eventual idea of making `Never` a universal bottom 
> type, but we don't actually have to implement that today, because we can just 
> overload `??` for now.
> 
> Against these advantages, the only one I can see for `!!` is that it is 
> terse. Terseness is good, especially for a feature which is competing with 
> the single-character postfix `!` operator, but I can't help but be drawn to 
> the flexibility and power of `??` with a `Never` expression on the right-hand 
> side.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 the community.

Best regards,

-- Erica Sadun

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 to forget to unwrap optionals. 
>>> The compiler will offer a fixit, telling you you must insert either a ? or 
>>> a !. However, when you accept the fixit, ! is inserted (at least, it is for 
>>> me in Xcode 8.3).
>> When you treat an optional as non-optional, the compiler has no way to do a 
>> fixit that would appropriately handle the optional. Felix made a good 
>> example. The only direct fixit would be a force unwrap. If you used “?” then 
>> your non-optional use would turn into an optional and your parameter would 
>> generally be non-optional. The fixit is just explicitly doing what you 
>> implicitly expected it to do.
>> 
>>> 
>>> Ideally the fixit would default to ? because this is the preferred option; 
>>> ! is often a sign of non-Swifty code and does not interact well with 
>>> idiomatic Swift constructs such as if-let-(as?), guard-let-(as?)-else, etc. 
>>> Also I think it’s safe to say that fixits should not err on the side of 
>>> crashing at runtime.
>> 
>> " ! is often a sign of non-Swifty code “
>> I would strongly challenge this assumption. Many core team members have 
>> commented about appropriate uses of the ! operator. It shouldn’t be used 
>> lightly, but it’s there for a reason and it most definitely isn’t 
>> “non-swifty”.
> 
> I think it's not a farfetched assumption to imply that if the compiler 
> encounters that code, the programmer didn't realize or remember that they 
> were dealing with optionals.
> 
> If the compiler suggests to force unwrap that expression, it is also fair to 
> assume that most inexperience programmers will just apply that fix it. A more 
> experience programmer can decide whether to force unwrap it or to handle the 
> nil case in any other way, depending on the context and code style.
> 
> Personally, I'd prefer that the compiler didn't encourage so much to use 
> force unwrapping, not because I think that it has no use, but because I think 
> that newbies should not learn that pattern first.
> 
> Surely, if I were new to the language and the compiler kept doing that fix 
> it, I would think that it's "the way" to deal with optionals.
> 
> What would I prefer? At least, for the fix it to provide several options, 
> more or less in this order:
> 
> - checked unwrap (if applies)
> - if let
> - guard let
> - force unwrap

Unfortunately, I think `!` *is* the proper fix-it here. The mechanisms to 
insert conditional binding, for example, are too unwieldy a tool at the many 
arbitrary places where an optional is used in place of a non-optional. I 
believe introducing an unwrap-or-die operator in parens (see 
https://github.com/apple/swift-evolution/pull/729 
) would provide a better 
fixit:

* A sophisticated developer is unlikely to use fix-its as a blunt instrument to 
make code work. Their use of  `!` can be appropriate and, in their hands, 
unlikely to be fixit-driven.

* The unsophisticated developer is better served with `!!`, which 
self-documents the safety issue and can be further evaluated for refactoring, 
supporting safer learner patterns. Unlike the other approaches for conditional 
binding, `!!` is fix-it friendly. 

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

From 2016:

See: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160404/014272.html
 

and https://gist.github.com/erica/5a26d523f3d6ffb74e34d179740596f7 


-- E

> On Jul 30, 2017, at 12:30 PM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> I like the general direction where this is going, but I haven’t settled on an 
> opinion regarding its appearance yet.
> I’ve argued before that the gap between optionals and errors should be closed 
> by making it easy to swift from optionals to non-optionals with throwing.
> The “unwrap-or-die” idea discussed earlier is very similar to this.
> 
> In the end, I think all optional, throwing and fatalError-related proposals 
> have to be united and carefully considered as an overarching proposal to 
> extend and complete Swift’s representation of “less-than-normal” situations.
> 
>> On Jul 30, 2017, at 9:25 PM, Robert Bennett via swift-evolution 
>>  wrote:
>> 
>> This idea was sparked by conversation in another thread about a more concise 
>> way to write the following:
>> 
>> guard let x1 = f1(), let x2 = f2(), ... else { ... }
>> doSomething(with: x1)
>> doSomething(with: x2)
>> ...
>> 
>> It was suggested to write a function that throws when an optional is nil, 
>> and then wrapping the calls to f1, f2, ... in that function, and then 
>> wrapping *those* in a do-catch block. This would both exit early in case one 
>> value was nil, and also use the values as soon as they’re available instead 
>> of needing to assign them to a temp variable first and using the temp 
>> variable.
>> 
>> Instead of a throwing unwrap function, I am proposing a throwing unwrap 
>> operator. This operator would work like !, but instead of a fatal error when 
>> the value is nil, it would throw.
>> 
>> struct UnwrapError: Error {}
>> postfix operator ^?
>> extension Optional {
>>  static postfix func ^?(optional: Optional) throws -> Wrapped {
>>  guard let wrapped = optional else {
>>  throw UnwrapError()
>>  }
>>  return wrapped
>>  }
>> }
>> 
>> In addition, to round this out, I think it would be helpful to be able to 
>> throw arbitrary errors, as a nil value may carry meaning that should be 
>> propagated to the rest of the program. Thus there could be a throwing nil 
>> coalescing operator, which returns the unwrapped value if non-nil, or throws 
>> the specified error if nil.
>> 
>> infix operator ^??
>> extension Optional {
>>  static func ^??(lhs: Optional, rhs: Error) throws -> Wrapped {
>>  guard let wrapped = lhs else {
>>  throw rhs
>>  }
>>  return wrapped
>>  }
>> }
>> 
>> Thoughts? I think these would be helpful additions to allow doing something 
>> with Optionals while simultaneously exiting early in the case of a nil value 
>> — putting the unwrapping, the use, and the exiting early all on one line. 
>> 
>> Hopefully this doesn’t distract from the other important conversations 
>> happening on the mailing list!
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via 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 directions (such as 
mathematics, fp, merging features from other languages). 
I think announce should announce.  One thread, one purpose.
I think evolution should have a review forum: one thread for each proposal.
Pitches and RFC should have their own forum, with individual threads. The 
dangers here are (1) losing good ideas, (2) good ideas that are timed poorly, 
(3) redundant ideas from not having found previous discussions, (4) well 
intentioned but inappropriate ideas. Having a way to filter types 3 and 4 out 
to a subforum to raise the S:N should be possible but will require some kind of 
moderation (such as Xiodi Wu has put such effort into supporting)
Working groups need their own development area. There needs to be some sort of 
top-level organization to make this usable ("Generics", "Dispatch", 
"Calendar/Clocks/Time", "Mathematics", "Strings", "Collections", whatever), but 
there should also be a level of flexiblity. I'd recommend giving manifesto 
topics initial priority at the top level but I'd also suggest that there have 
to be some kind of effort to open a new discussion area, to limit the number of 
"ghost forums".
A SE version of a FAQ, be it "Commonly Proposed"/"Commonly Rejected" and some 
kind of Quinn-like Eskimo support for directing and moderating.

The measures of success are:

* Can track news ("announce")
* Can participate in active reviews
* Can read archived reviews
* Can pitch and develop proposals as part of a working group
* Can search for previous discussions
* Can look up whether common topics have already been hit 
* Can support a small and well-populated forum hierarchy with few orphans and 
ghosts
* Communicates that the forum is a non-social working area and a public record 
of language development.

-- E


> On Aug 1, 2017, at 11:13 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> A while back a decision was reached to move from using mailing lists for 
> swift-evolution to using a forum, specifically Discourse.  At the time that 
> decision was made, efforts had been already well committed for supporting the 
> development of Swift 4 — including efforts supporting important 
> infrastructure efforts such as the source compatibility suite.  I apologize 
> for not providing more transparency in why moving to a forum was being 
> delayed.  Some things took longer than expected.
> 
> To be clear, the plan is to still move to Discourse, and with Swift 4 winding 
> down there is now bandwidth to focus on making the transition from mailing 
> lists to a forum.  As part of that transition, I’d like to get some feedback 
> from the community.
> 
> There has been some good conversations on this mailing list on how 
> swift-evolution can possibly evolve to better serve the needs of the 
> community.  I’m not talking about whether or not we use a mailing list or a 
> forum — that decision has been made.  Specifically, I’m talking about how a 
> forum could best be structured to organize discussions and allow everyone to 
> optimally participate.  In the move to Discourse, we have the opportunity 
> here to possibly do things a bit differently than we have been so far.
> 
> For example, here are some of the questions I’m thinking about how we should 
> be use a forum:
> 
> -  We currently have swift-evolution and swift-evolution-announce.  Should we 
> use a specific “category” in the forum for "proposals that are in active 
> review" — and possibly remove the need to have something like 
> swift-evolution-announce?  
> 
> - Should we have other topical areas to organize discussions?  If so, at what 
> granularity?
> 
> We can certainly figure out a lot of this over time, but I’d like some 
> feedback from the community now on things they’d like to see in how we 
> organize the swift-evolution forum based on experiences we’ve had with 
> swift-evolution since it was created.
> 
> Please chime in on this thread if you have feedback, and focus on keeping 
> this constructive.
> 
> Thanks,
> Ted
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 the progress of the language and/or highly 
> popular — regardless of whether the proposal was authored by the core team or 
> a community member.
> 
> From what I know of the team, they’re not going to let a good idea languish 
> just because of the name that’s in the author field. I’m sure they _are_ 
> going to strategically prioritize what gets attention, and that’s not a bad 
> thing.
> 
> Cheers,
> 
> Paul

Perhaps I'm being overly optimistic but I see this change as enhancing 
collaboration between idea-level and code-level evolution. Requiring a 
preliminary implementation:

Ensures a proof of concept that the proposed change (like expanding `Self` to 
classes) is realistic and possible.
Ensures that the Swift codebase impact can be measured at the time the proposal 
is evaluated.
Encourages multi-author proposal teams, comprised of people who understand code 
impact as well those who can express the importance of the language expression 
from a user side. 
Provides real world "road testing" of proposed toolchain enhancements, letting 
the changes be "tuned" before proposal. This minimizes adoption regrets, 
because the beta toolchain can be used with real code. (As with the tuples and 
closures)
Upfront costs *will* be higher. Not only do you have to believe that a change 
is good, you must develop a working group that includes coders to create a 
prototype without any guarantee that the change will pass muster. 

Finding those coders and convincing them this will be a great change means that 
proposals will naturally skew towards Apple-driven rather than wider 
community-driven. However it does not exclude the latter, especially for 
passionate proposals that can find the coders to champion them.

-- Erica

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 approached this:

// Ugh
[UIView(), UIView(), UIView(), UIView(), UIView()]

// No:
let viewsA = Array(repeating: UIView(), count: 5) 
// You end up with 5 of the same view

// Two statements that really should be one
var views: [UIView] = []
for _ in 1 ... 5 { views.append(UIView()) }

// Wrong use of `map`,  because it's mapping over `Void`
let viewsA = (1 ... 5).map({ _ in UIView() }) 

// You can introduce `collect` specifically for the `_ in` in case, matching 
other languages:
public func collect(_ generator: () throws -> T) rethrows -> [T]

// I think these are just ugly
let viewsA__ = sequence(first: UIView(), next: { _ in UIView() }).lazy.prefix(5)
let viewsB__ = sequence(state: 5, next: { defer { $0 -= 1 }; $0 == 0 ? nil : 
UIView() }

// You can build an iterator

let labeler = AnyIterator({ return UILabel() })
let labels4 = Array(labeler.prefix(5))

// which lets you create multiple "slices" off the iterator

let randoms = AnyIterator({ return Int(arc4random_uniform(100) )})

print(Array(randoms.prefix(5)))
print(Array(randoms.prefix(5)))


// A little complex and I don't like making this `Int` based, because it pulls 
the semantics away from sequences/collections

extension Int {
func of(_ generator: @autoclosure () -> T) -> [T] {
assert(self >= 0, "cannot generate negative-count collection")
return (0 ..< self).map({ _ in generator() })
}
}

5.of(UIView())

// Even worse
protocol Constructable {
init()
}

extension UIView: Constructable {}

extension Int {
func of(_ generator: @autoclosure () -> T) -> 
UnfoldSequence {
assert(self > 0, "cannot generate negative-count collection")
return sequence(state: self, next: { (state: inout Int) -> T? in
defer { state -= 1 }; return state == 0 ? nil : T.init() })
}
}

print(Array(5.of(UIView(

// or

extension Int {
func of(_ generator: @escaping @autoclosure () -> T) -> 
LazyMapRandomAccessCollection<(CountableRange), T> {
assert(self > 0, "cannot generate negative-count collection")
return (0 ..< self).lazy.map({ _ in generator() })
}
}

// where some people preferred calling this `elements`, for example 
`5.elements(of: UIView())`

// You can go Array:

extension Array {
/// Creates a new array containing the specified number of values created 
by repeating a generating closure.
///
/// - Parameters:
///   - count: The number of times to apply the closure. `count` must be 
zero or greater.
///   - generator: The closure to execute
public init(count: Int, repeating: () -> Element) {
precondition(count >= 0, "")
self.init((1 ... count).map({ _ in repeating() }))
}
}

let labels = Array(count: 4) { UILabel() }

// Or similarly

extension Array {
init(repeat count: Int, byCalling generator: @autoclosure () -> Element) {
self = (1 ... count).map({ _ in generator() })
}
}

// From Oliver H:

extension Array {
  convenience init(count: Int, repeating: () -> Elements) {
self = Array( (0..(generator: @autoclosure () -> T, n: Int) -> [T] {
  (0.. On Aug 17, 2017, at 10:36 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
> On Thu, Aug 17, 2017 at 9:20 AM Ross O'Brien  > wrote:
> (0..<3).map{ _ in UIView() } - map already returns an Array.
> 
> Array((0..<3).map{ _ in UIView() }) is redundant.
> 
> Ah, right, thanks for pointing that out. I couldn't remember off the top of 
> my head whether it returned an array or some kind of special sequence type 
> that would need to be converted over.
> 
> In that case, I still think the map version wins—it's very clear that a 
> repeated *operation* is occurring, whereas the originally proposed 
> @autoclosure version hides that very important semantic information.
> 
> 
> I've fallen foul before, of trying to create an array of six buttons and 
> getting an array of one button six times; I think that should be easier. But 
> if each button corresponds to an existing value or needs to be initialised 
> based on its index in that array, map transposing values or indices into 
> buttons is already covered.
> 
> On Thu, Aug 17, 2017 at 5:03 PM, Tony Allevato via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Couldn't this be rewritten more simply today as:
> 
> Array((0..<3).map { index in MyView(forIndex: index) })
> 
> And the version that doesn't need the index could be written:
> 
> Array((0..<3).map { _ in UIView() })
> 
> The AnyIterator approach posted above is also nice—I wouldn't have thought of 
> that one. But I suppose that only works in the case where you don't need the 
> index.
> 
> So the ques

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

[Erica Sadun via swift-evolution]

> 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 
>> 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)
> 
> Can you please elaborate why (or maybe point me at the rant)? 


Summary:

. Since this application is a generator and not a transformative function, 
`map` is a misfit to usage semantics. It breaks the contract that map means to 
project from a domain to a range via a function. More languages conventionally 
use `collect` than `map` to collect n applications of a generator closure

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

What people are doing is taking a real set of values (1, 2, 3, 4, 5, for 
example), then discarding them via `_ in`, which is different from `Void -> T` 
or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,  
UIColor.red, { x: Int in x^x }). There are too many semantic shifts away from 
"I would like to collect the execution of this closure n times" for it to sit 
comfortably.

-- E


> On Aug 17, 2017, at 3:53 PM, Xiaodi Wu  wrote:
> 
> This is, I would argue, much too limiting in the way of semantics and not at 
> all required by “map”. It’s unclear to me how _any_ result with reference 
> semantics or any function with side effects could be used in a way that 
> comports with that definition.
> 
> On the other hand, just as y = 0x is a function, { _ in Foo() } is a closure 
> that very much does 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>> wrote:
> 
>> On Aug 17, 2017, at 12:04 PM, Max Moiseev > <mailto:mois...@apple.com>> 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 
>>> 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)
>> 
>> Can you please elaborate why (or maybe point me at the rant)? 
> 
> 
> Summary:
> 
> . Since this application is a generator and not a transformative function, 
> `map` is a misfit to usage semantics. It breaks the contract that map means 
> to project from a domain to a range via a function. More languages 
> conventionally use `collect` than `map` to collect n applications of a 
> generator closure
> 
> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu  wrote:
> 
> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun  <mailto:er...@ericasadun.com>> wrote:
> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for 
> example), then discarding them via `_ in`, which is different from `Void -> 
> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,  
> UIColor.red, { x: Int in x^x }). There are too many semantic shifts away from 
> "I would like to collect the execution of this closure n times" for it to sit 
> comfortably.
> 
> What arguments might help to alleviate this discomfort? Clearly, functions 
> exist that can map this delightfully heterogeneous domain to some sort of 
> range that the user wants. Would you feel better if we wrote instead the 
> following?
> 
> ```
> repeatElement((), count: 5).map { UIView() }
> ```

My favorite solution is the array initializer. Something along the lines of 
`Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_ reaches 
standard library but I think it is a solid way to say "produce a collection 
with a generator run n times". It's a common  task. I was asking around about 
this, and found that a lot of us who work with both macOS and iOS and want to 
stress test interfaces do this very often. Other use cases include "give me n 
random numbers", "give me n records from this database", etc. along similar 
lines.

The difference between this and the current `Array(repeating:count:)` 
initializer is switching the arguments and using a trailing closure  (or an 
autoclosure) rather than a set value. That API was designed without the 
possibility that you might want to repeat a generator, so there's a bit of 
linguistic turbulence.

-- E

>> On Aug 17, 2017, at 3:53 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> This is, I would argue, much too limiting in the way of semantics and not at 
>> all required by “map”. It’s unclear to me how _any_ result with reference 
>> semantics or any function with side effects could be used in a way that 
>> comports with that definition.
>> 
>> On the other hand, just as y = 0x is a function, { _ in Foo() } is a closure 
>> that very much does 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>> wrote:
>> 
>>> On Aug 17, 2017, at 12:04 PM, Max Moiseev >> <mailto:mois...@apple.com>> 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 
>>>> 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)
>>> 
>>> Can you please elaborate why (or maybe point me at the rant)? 
>> 
>> 
>> Summary:
>> 
>> . Since this application is a generator and not a transformative function, 
>> `map` is a misfit to usage semantics. It breaks the contract that map means 
>> to project from a domain to a range via a function. More languages 
>> conventionally use `collect` than `map` to collect n applications of a 
>> generator closure
>> 
>> -- E
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

`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 
initializer or `5.elements(of: UIView())`. I don't think I'm overstating how 
common this pattern is, and `Array(repeating:count:)` feels _close_ but not 
close enough.

-- E

> On Aug 17, 2017, at 7:13 PM, Robert Bennett  wrote:
> 
> Xiaodi, you pretty much took the words out of my mouth. I was going to 
> suggest a Count collection whose Element was Void and with the sole 
> initializer init(_ count: Int). The type 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>> wrote:
> 
>> 
>>> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu >> <mailto:xiaodi...@gmail.com>> wrote:
>>> 
>>> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun >> <mailto:er...@ericasadun.com>> wrote:
>>> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for 
>>> example), then discarding them via `_ in`, which is different from `Void -> 
>>> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,  
>>> UIColor.red, { x: Int in x^x }). There are too many semantic shifts away 
>>> from "I would like to collect the execution of this closure n times" for it 
>>> to sit comfortably.
>>> 
>>> What arguments might help to alleviate this discomfort? Clearly, functions 
>>> exist that can map this delightfully heterogeneous domain to some sort of 
>>> range that the user wants. Would you feel better if we wrote instead the 
>>> following?
>>> 
>>> ```
>>> repeatElement((), count: 5).map { UIView() }
>>> ```
>> 
>> My favorite solution is the array initializer. Something along the lines of 
>> `Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_ 
>> reaches standard library but I think it is a solid way to say "produce a 
>> collection with a generator run n times". It's a common  task. I was asking 
>> around about this, and found that a lot of us who work with both macOS and 
>> iOS and want to stress test interfaces do this very often. Other use cases 
>> include "give me n random numbers", "give me n records from this database", 
>> etc. along similar lines.
>> 
>> The difference between this and the current `Array(repeating:count:)` 
>> initializer is switching the arguments and using a trailing closure  (or an 
>> autoclosure) rather than a set value. That API was designed without the 
>> possibility that you might want to repeat a generator, so there's a bit of 
>> linguistic turbulence.
>> 
>> -- E
>> 
>>>> On Aug 17, 2017, at 3:53 PM, Xiaodi Wu >>> <mailto:xiaodi...@gmail.com>> wrote:
>>>> 
>>>> This is, I would argue, much too limiting in the way of semantics and not 
>>>> at all required by “map”. It’s unclear to me how _any_ result with 
>>>> reference semantics or any function with side effects could be used in a 
>>>> way that comports with that definition.
>>>> 
>>>> On the other hand, just as y = 0x is a function, { _ in Foo() } is a 
>>>> closure that very much does 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>> wrote:
>>>> 
>>>>> On Aug 17, 2017, at 12:04 PM, Max Moiseev >>>> <mailto:mois...@apple.com>> 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 
>>>>>> 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)
>>>>> 
>>>>> Can you please elaborate why (or maybe point me at the rant)? 
>>>> 
>>&g

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

[Erica Sadun via swift-evolution]

> 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 
> initializer or `5.elements(of: UIView())`. I don't think I'm overstating how 
> common this pattern is, and `Array(repeating:count:)` feels _close_ but not 
> close enough.
> 
> The first two have the benefit of being currently existing APIs;

I'm pretty sure Count isn't an  existing API. And as I said before, while I 
don't think this rises to stdlib inclusion, it's been a common problem domain 
for people both inside and outside Apple so it deserves a full discussion.

That said, `Count` is neat. It encapsulates an idea in a way that I haven't 
seen in Swift. 

-- E


> they capture the semantics perfectly, as I've argued, and I simply don't see 
> how they are impaired in elegance in any way--certainly not enough to justify 
> a standard library addition to create a third way of spelling the same thing. 
> Ultimately, any user is free to define something like:
> 
> ```
> func * (lhs: Int, rhs: @autoclosure () throws -> T) rethrows -> [T] {
>   return try repeatElement((), count: lhs).map { try rhs() }
> }
> 
> 5 * UIView()
> ```
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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:
>> 
>> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun > <mailto:er...@ericasadun.com>> wrote:
>> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for 
>> example), then discarding them via `_ in`, which is different from `Void -> 
>> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,  
>> UIColor.red, { x: Int in x^x }). There are too many semantic shifts away 
>> from "I would like to collect the execution of this closure n times" for it 
>> to sit comfortably.
>> 
>> What arguments might help to alleviate this discomfort? Clearly, functions 
>> exist that can map this delightfully heterogeneous domain to some sort of 
>> range that the user wants. Would you feel better if we wrote instead the 
>> following?
>> 
>> ```
>> repeatElement((), count: 5).map { UIView() }
>> ```
> 
> My favorite solution is the array initializer. Something along the lines of 
> `Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_ reaches 
> standard library but I think it is a solid way to say "produce a collection 
> with a generator run n times". It's a common  task. I was asking around about 
> this, and found that a lot of us who work with both macOS and iOS and want to 
> stress test interfaces do this very often. Other use cases include "give me n 
> random numbers", "give me n records from this database", etc. along similar 
> lines.
> 
> The difference between this and the current `Array(repeating:count:)` 
> initializer is switching the arguments and using a trailing closure  (or an 
> autoclosure) rather than a set value. That API was designed without the 
> possibility that you might want to repeat a generator, so there's a bit of 
> linguistic turbulence.
> 
> -- E
> 
> 
> To me at least, this is a very i-Centric complaint, since I can barely 
> remember the last time I needed something like this for anything that didn’t 
> involve UIKit. What you’re asking for is API sugar for generating reference 
> types with less typing. 

No, that's what the original thread poster wanted.

I want to avoid breaking math. For any x passed to a function, I expect f(x) to 
produce the same result. To map is to create a relation so that for every x in 
a domain, there is a single y that it produces. You can hand-wave and say the 
map is "producing" the closure, but it's not. It's executing it and recovering 
a value.

How we get past the `(n ... m).map({ _ in ... })` pattern may be through 
language guidance or through language evolution. Either way, it doesn't make 
this pattern not problematic and worthy of discussion.

Finally, I don't think Swift Evolution _can_ be considered entirely outside the 
auspices of the Apple halo. Look at SE-0005, SE-0006, and SE-0023 for example. 
i-Centricity is inescapable given the core team and the hosting domain for this 
project.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 11:59 AM, Austin Zheng  wrote:
> 
> I like the idea in principle.
> 
> However, right now you can write something like:
> 
> if let a = optionalA, frob = fooBarBaz() { ... }
> 
> It's clear that both clauses are optional binding clauses.
> 
> With this change, it's not clear anymore whether the second clause is an 
> optional binding clause, or a logic test erroneously using '=' instead of 
> '=='.
> 
> 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
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

Okay, and here is where the problem is (thanks Chris L)

`z = q` is an expression. It returns Void.

For example:

let q = 5
var z = 0
let foo = z = q // foo inferred to have type `()` which may be unexpected

So if you have the following statement:

guard let x = optional, z = q else {...}

where q is non-optional, there's issues in that `q` is not an optional and `z = 
q` is an expression.

-- E


> On May 24, 2016, at 11:59 AM, Austin Zheng  wrote:
> 
> I like the idea in principle.
> 
> However, right now you can write something like:
> 
> if let a = optionalA, frob = fooBarBaz() { ... }
> 
> It's clear that both clauses are optional binding clauses.
> 
> With this change, it's not clear anymore whether the second clause is an 
> optional binding clause, or a logic test erroneously using '=' instead of 
> '=='.
> 
> 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 swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Earlier on Swift Evolution:
> 
> Me: "Is there a technical reason that Swift cannot be expanded to allow 
> arbitrary mixes of conditional binding and boolean assertions within a single 
> compound guard statement?"
> 
> Joe Groff: "No. You already can, we just have the somewhat strange rule that 
> to separate `guard` conditions uses `,` before optional or pattern 
> conditions, but `where` before Boolean conditions. There's no technical 
> reason we couldn't accept either 'where' or ',' consistently."
> 
>   guard x == 0,
> let y = optional where
> z == 2 {
>   }
> 
> Pitch: 
> 
> I'd like to update Swift's grammar to interchangeably and consistently accept 
> `where` or `,` to separate guard conditions. This would allow a more 
> consistent approach that supports intermingling conditional binding and 
> boolean assertions. Here's a real-world bit of code I was helping someone 
> with a few evenings ago. It's attempting to navigate through some JSON, using 
> optional conditions with where clauses.
> 
> guard
> let fileContents = fileContents,
> let jsonDict = try NSJSONSerialization.JSONObjectWithData(fileContents, 
> options: []) as? NSDictionary,
> let featuresArray = jsonDict["features"] as? NSArray where 
> featuresArray.count > 0,
> let featuresDict = featuresArray[0] as? NSDictionary,
> let coordinatesArray = featuresDict["geometry"] where 
> coordinatesArray.count > 0,
> let coordinateArray = coordinatesArray[0] as? NSArray where 
> coordinateArray.count > 3
> else { fatalError("Reason") }
> 
> Each `where` test is a separate test. While there are semantic ties between 
> the conditional binding and the count tests, there doesn't have to be. Under 
> Swift's current rules,  you must use the `where` keyword to introduce a 
> Boolean test after a binding or pattern, regardless of whether or not there's 
> an underlying semantic link between the two.
> 
> By removing this requirement and allowing interchangeability between `where` 
> and `,`, you're given the option of tying the boolean to the binding/pattern 
> match or introducing a boolean statement with no connection to previous 
> steps. Here's what this example looks like after excluding `where`:
> 
> guard
> let fileContents = fileContents,
> let jsonDict = try NSJSONSerialization.JSONObjectWithData(fileContents, 
> options: []) as? NSDictionary,
> let featuresArray = jsonDict["features"] as? NSArray,
> featuresArray.count > 0,
> let featuresDict = featuresArray.firstObject as? NSDictionary,
> let coordinatesArray = featuresDict["geometry"],
> coordinatesArray.count > 0,
> let coordinateArray = coordinatesArray.firstObject as? NSArray,
> coordinateArray.count > 3
> else { fatalError("Reason") }
> 
> The motivation for this approach becomes more compelling when the Boolean 
> tests are disjoint from binding or pattern matches.
> 
> guard
> minimumShapeCount > 4,
> let shapes = decompose(map, minimum: minimumShapeCount),
> availableArea > minimumArea,
> let map = placeShapes(shapes, availableArea) else {
> fatalError()
> }
> 
> would be allowed compared to current Swift which mandates where between the 
> second and third tests:
> 
> let shapes = decompose(map, minimum: minimumShapeCoun

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

[Erica Sadun via swift-evolution]

Or you can make sure every expression is boolean, which would take care of this 
as well...

-- E


> On May 24, 2016, at 12:47 PM, Jacob Bandes-Storch  wrote:
> 
> Could we just require "let" (or var) to introduce every binding, rather than 
> allowing the combination "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 L)
> 
> `z = q` is an expression. It returns Void.
> 
> For example:
> 
> let q = 5
> var z = 0
> let foo = z = q // foo inferred to have type `()` which may be unexpected
> 
> So if you have the following statement:
> 
> guard let x = optional, z = q else {...}
> 
> where q is non-optional, there's issues in that `q` is not an optional and `z 
> = q` is an expression.
> 
> -- E
> 
> 
>> On May 24, 2016, at 11:59 AM, Austin Zheng > <mailto:austinzh...@gmail.com>> wrote:
>> 
>> I like the idea in principle.
>> 
>> However, right now you can write something like:
>> 
>> if let a = optionalA, frob = fooBarBaz() { ... }
>> 
>> It's clear that both clauses are optional binding clauses.
>> 
>> With this change, it's not clear anymore whether the second clause is an 
>> optional binding clause, or a logic test erroneously using '=' instead of 
>> '=='.
>> 
>> 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 swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Earlier on Swift Evolution:
>> 
>> Me: "Is there a technical reason that Swift cannot be expanded to allow 
>> arbitrary mixes of conditional binding and boolean assertions within a 
>> single compound guard statement?"
>> 
>> Joe Groff: "No. You already can, we just have the somewhat strange rule that 
>> to separate `guard` conditions uses `,` before optional or pattern 
>> conditions, but `where` before Boolean conditions. There's no technical 
>> reason we couldn't accept either 'where' or ',' consistently."
>> 
>>  guard x == 0,
>>let y = optional where
>>z == 2 {
>>  }
>> 
>> Pitch: 
>> 
>> I'd like to update Swift's grammar to interchangeably and consistently 
>> accept `where` or `,` to separate guard conditions. This would allow a more 
>> consistent approach that supports intermingling conditional binding and 
>> boolean assertions. Here's a real-world bit of code I was helping someone 
>> with a few evenings ago. It's attempting to navigate through some JSON, 
>> using optional conditions with where clauses.
>> 
>> guard
>> let fileContents = fileContents,
>> let jsonDict = try NSJSONSerialization.JSONObjectWithData(fileContents, 
>> options: []) as? NSDictionary,
>> let featuresArray = jsonDict["features"] as? NSArray where 
>> featuresArray.count > 0,
>> let featuresDict = featuresArray[0] as? NSDictionary,
>> let coordinatesArray = featuresDict["geometry"] where 
>> coordinatesArray.count > 0,
>> let coordinateArray = coordinatesArray[0] as? NSArray where 
>> coordinateArray.count > 3
>> else { fatalError("Reason") }
>> 
>> Each `where` test is a separate test. While there are semantic ties between 
>> the conditional binding and the count tests, there doesn't have to be. Under 
>> Swift's current rules,  you must use the `where` keyword to introduce a 
>> Boolean test after a binding or pattern, regardless of whether or not 
>> there's an underlying semantic link between the two.
>> 
>> By removing this requirement and allowing interchangeability between `where` 
>> and `,`, you're given the option of tying the boolean to the binding/pattern 
>> match or introducing a boolean statement with no connection to previous 
>> steps. Here's what this example looks like after excluding `where`:
>> 
>> guard
>> let fileContents = fileContents,
>> let jsonDict = try NSJSONSerialization.JSONObjectWithData(fileContents, 
>> options: []) as? NSDictionary,
>> let featuresArray = jsonDi

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

[Erica Sadun via swift-evolution]

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://gist.github.com/erica/96d9c5bb4eaa3ed3b2ff82dc35aa8dae 


If the community demand is this high, I think we should re-consider pushing it 
before 3. 
Feedback as always welcome, including criticism.

-- E

Introducing with to the Standard Library

Proposal: TBD
Author: Erica Sadun 
Status: TBD
Review manager: TBD
 
Introduction

This proposal introduces a with function to the standard library to simplify 
the initialization and modification of constants and Foundation-sourced complex 
objects.

Swift-evolution thread: What about a VBA style with Statement? 

 
Motivation

Closure-based initialization enables clean and highly directed set-up in Swift 
code. Numerous variations on the theme have been introduced on the Swift 
Evolution list and in third party github repositories. Although you can build 
solutions natively without functions, current Swift technology has drawbacks:

let questionLabel: UILabel = {
$0.textAlignment = .Center
$0.font =  UIFont(name:"DnealianManuscript", size: 72)
$0.text = questionText
$0.numberOfLines = 0
return $0
}(UILabel())

let mySwitch : UISwitch = {
view.addSubview($0)
CenterViewInSuperview($0, horizontal: true, vertical: true)
$0.addTarget(self, action: "action", forControlEvents: .TouchUpInside)
return $0
}(UISwitch())
Assignment must be explicitly typed.
The source item must be postpended to the set-up closure.
The closure must return the item.
This approach is better suited to setting up Foundation objects than modifying 
Swift constants. When duplicating and modifying a constant, the closure must 
create a var copy and modify that copy.
While the implementation is imperfect, the wins are notable. Code naturally 
groups into a clear set-up sequence. The scoped setup avoids clumpy redundant 
lines where the same variable is accessed over and over. 

let questionLabel = UILabel()
questionLabel.textAlignment = .Center
questionLabel.font =  UIFont(name:"DnealianManuscript", size: 72)
questionLabel.text = questionText
questionLabel.numberOfLines = 0
In the case of non-reference types, a constant's fields may be set-up 
sequentially without forcing the constant to be a variable.

 
Detailed
 Design

This proposal introduces a with function that enables modification and use of 
an instance using positional references. It's not quite as clean as a solution 
with implicit self but it offers sufficient utility that a vast swath of Swift 
developers have adopted this function in some form or another.

@discardableResult
public func with(_ item: T, update: @noescape (inout T) throws -> Void) 
rethrows -> T {
var this = item; try update(&this); return this
}
In use:

struct Person { var name: String, favoriteColor: UIColor }
let john = Person(name: "John", favoriteColor: .blueColor())
let jane = with(john){ $0.name = "Jane" }
print(jane) // Person(name: "Jane", favoriteColor: UIDeviceRGBColorSpace 0 0 1 
1)

struct Point { var (x, y) : (Double, Double) }
let p1 = Point(x: 2, y: 3)
let p2 = with(p1){ $0.y = 4 }
print(p1, p2) // Point(x: 2.0, y: 3.0) Point(x: 2.0, y: 4.0)
 
Impact
 on Existing Code

This proposal is purely additive and has no impact on existing code

 
Alternatives
 Considered

Not adopting this proposal___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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> func dynamicType_(_ x: T) -> T.Type { return x.dynamicType }
>2> dynamicType_(42)
>  $R0: Int.Type = Int
>3> class B {}
>4. class C : B {}
>5. dynamicType_(C() as B)
>  $R1: B.Type = __lldb_expr_5.C
>6>
> 
> IMO exposing it as a special language feature is a mistake unless
> there's something wrong with the implementation above.  There are many
> ways we can implement the body of the generic function and still remove
> the .dynamicType property from the language's user model.


I'm going to defer to Joe Groff to respond specifically to this. I believe the
issue was that the type signature could not be described in today's Swift
but would be possible in future Swift, as the current type system wouldn't
work for protocol metatypes.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On May 25, 2016, at 1:00 PM, Adriano Ferreira  wrote:
> 
> Hi all,
> 
> I really like this idea and appreciate the effort. However, I’d rather have a 
> method similar to Ruby Object#tap <http://apidock.com/rails/Object/tap> and 
> not a free function.
> 
> Well, since there’s no "Object class" in Swift, the way I see it is through a 
> protocol, much like the Then <https://github.com/devxoul/Then> project is 
> done.
> 
> — A

In Swift, there's no root object like NSObject, which is what the 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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://gist.github.com/erica/96d9c5bb4eaa3ed3b2ff82dc35aa8dae 
>> <https://gist.github.com/erica/96d9c5bb4eaa3ed3b2ff82dc35aa8dae>
>> 
>> If the community demand is this high, I think we should re-consider pushing 
>> it before 3. 
>> Feedback as always welcome, including criticism.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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
>> compiler was very immature and many design avenues we might have taken
>> were not available.  I find the `sequence` forms to be superior in
>> general, and IMO at some point we should re-evaluate the interfaces to
>> AnySequence and AnyIterator.
> 
> That sounds like a reasonable justification for keeping sequence(state:next:).
> 
> -Kevin Ballard


I think Kevin will agree that I was really slow on uptake in terms of the state 
version, but once
I *got* it, I found that I kept using it. Yesterday, I was showing someone some 
math using cubic 
Beziers, and boom there was the extra "var t = 0.0" sitting out there, which I 
immediately recognized 
and refactored into the sequence(state:next:) version instead. It produced a 
much cleaner and
more pleasing result, imo. (I also found a dandy playground bug unrelated.)

I know that the idea of an extra capture mentally feels ugly but it's really 
useful. A week ago, 
I wouldn't have fought to keep the option. Now, I would.

-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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()", "withExtendedLifetime()", etc.
>> 
>> I'd also be okay with waiting for a comprehensive method-cascading solution. 
>> I don't find this issue particularly urgent, because it's pretty easily 
>> solvable with an extension or just using closures.
> 
> +1.  I’ve been playing around with it in my own code a little bit.  I’m still 
> uncertain about when I think it is good style and when I think it is best 
> avoided.  I would certainly feel more comfortable using it if it was in the 
> standard library.  
> 
> At the same time, I think we can and should do better in the future.  If that 
> is the plan, do we really want `with` in the standard library?  I don’t mind 
> waiting for a better solution, especially if it means a better solution is 
> more likely to happen and / or we aren’t left with an unnecessary and 
> duplicative function in the standard library.
> 
> So I’m on the fence here.  

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 stored into 
constants. That alone should argue for its value.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 
>> stored into constants. That alone should argue for its value.
> 
> Can you point us to the latest draft of what you have in mind for cascading 
> in the future?  

Haven't really touched it since I got the "sit and wait" but I've come around 
to preferring Dartism.

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 alter the type of 
> the collection (so those changes are typically spot changes), and the closing 
> sigil of the collection (a right square bracket) is often placed on the line 
> *following* the elements of the collection.  Because of these properties, 
> accepting a trailing comma in a collection literal can help reduce spurious 
> diffs when elements are added or removed.
> 
> That said, these properties do not translate to other comma separated lists 
> in Swift, such as variable bindings in a var/let declaration, parameter lists 
> or tuples.  For parameter lists and tuples (the specific topic of the 
> proposal), the trailing terminator of the list is typically placed on the 
> same line as the other elements.  Further, changes to add or remove an 
> element to a parameter list or tuple element list change the type of the 
> tuple or the signature of the call, meaning that there is almost always 
> changes in other parts of the code to allow the change to build.  Finally, 
> the core team does not want to encourage or endorse a coding style that puts 
> the terminating right parenthesis on a line following the arguments to that 
> call.


To be honest, I was hoping the core team might agree that they be allowed just 
at call-sites, where changes would not propagate to other parts of the code but 
allow the easy inclusion and exclusion of defaulted arguments. 

Sad to see this one go down but gratified that it got a fair consideration. 
Thank you again, -- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 understand what is possible with them.
> 
> Did you consider allowing the semicolon to be omitted when a newline 
> separates conditions?  Something like this:

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 would 
negatively affect the clarity of parsing this proposal aims to introduce.

I'd really like to see a separate newline-as-separator proposal brought forward 
and formally reviewed. It's garnered a few very vocal supporters but it really 
doesn't fall under the umbrella of this proposal. I'd like the matter to be 
settled one way or the other for the sake of closure.

-- Erica

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 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://gist.github.com/erica/96d9c5bb4eaa3ed3b2ff82dc35aa8dae 
>> <https://gist.github.com/erica/96d9c5bb4eaa3ed3b2ff82dc35aa8dae>
>> 
>> If the community demand is this high, I think we should re-consider pushing 
>> it before 3. 
>> Feedback as always welcome, including criticism.
>> 
> 
> Recently there was another possible 'with' variant:
> - instead of being a: with 'instance' create new 'instance' using 'closure'
> - it was a: with(/on) 'instance/s' perform 'closure' (same idea as the 
> closure-based initialization, described in the motivation)
> 
> The thread "What about a VBA style with Statement?": 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/14384 
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/14384>
> 
> In either case the 'with' can be misleading/confusing; with, on its own 
> doesn't suggest creation of a new entity, nor does it strongly suggest 
> possible mutation.
> 
> Just mentioning it as to end up... with the proper name for this new function.
> 
> Dany
> 

Naming can always be bikeshedded. 
Brent's submitted a pull request: 
https://github.com/apple/swift-evolution/pull/346
Here's a gist: https://gist.github.com/brentdax/ce3272e3d35f5ccac56483666f86b8fb
The current state of the proposal follows 
-- E

Introducing with to the Standard Library

Proposal: TBD
Author: Erica Sadun <https://github.com/erica>, Brent Royal-Gordon 
<https://github.com/brentdax>
Status: TBD
Review manager: TBD
 
<https://gist.github.com/brentdax/ce3272e3d35f5ccac56483666f86b8fb#introduction>Introduction

This proposal introduces a with function to the standard library. This function 
simplifies the initialization of objects and modification of value types.

Swift-evolution thread: What about a VBA style with Statement? 
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/14384>
 
<https://gist.github.com/brentdax/ce3272e3d35f5ccac56483666f86b8fb#motivation>Motivation

When setting up or modifying an instance, developers sometimes use an 
immediately-called closure to introduce a short alias for the instance and 
group the modification code together. For example, they may initialize and 
customize a Cocoa object:

let questionLabel: UILabel = {
$0.textAlignment = .Center
$0.font = UIFont(name: "DnealianManuscript", size: 72)
$0.text = questionText
$0.numberOfLines = 0
mainView.addSubview($0)
return $0
}(UILabel())
Or they may duplicate and modify a constant value-typed instance:

let john = Person(name: "John", favoriteColor: .blueColor())
let jane: Person = { (var copy) in
copy.name = "Jane"
return copy
}(john)
This technique has many drawbacks:

The compiler cannot infer the return type.
You must explicitly return the modified instance.
The instance being used comes after, not before, the code using it.
Nevertheless, developers have created many variations on this theme, because 
they are drawn to its benefits:

The short, temporary name reduces noise compared to repeating a variable name 
like questionLabel.
The block groups together the initialization code.
The scope of mutability is limited.
SE-0003, which removes var parameters 
<https://github.com/apple/swift-evolution/blob/master/proposals/0003-remove-var-parameters.md>,
 will make this situation even worse by requiring a second line of boilerplate 
for value types. And yet developers will probably keep using these sorts of 
tricks.

Fundamentally, this is a very simple and common pattern: creating a temporary 
mutable variable confined to a short scope, whose value will later be used 
immutably in a wider scope. Moreover, this pattern shortens the scopes of 
mutable variables, so it is something we should encourage. We believe it's 
worth codifying in the standard library.

 
<https://gist.github.com/brentdax/ce3272e3d35f5ccac56483666f86b8fb#proposed-solution>Proposed
 Solution

We propose introducing a function with the following simplified signature:

func with(_: T, update: (inout T -> Void)) -> T
with assigns the value to a new variable, passes that variable as a parameter 
to the closure, and then returns the potentially modified variable. That means:

When used with val

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

[Erica Sadun via swift-evolution]

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 
>> would negatively affect the clarity of parsing this proposal aims to 
>> introduce.
> 
> Maybe Joe can comment on the parsing question.
> 
> What kinds of examples did you look at where you felt that way?  IMO the 
> example in the proposal reads better without the semicolons:
> 
> guard
> x == 0;
> let y = optional;
> z == 2 
> else { ... }
> 
> vs
> 
> guard
> x == 0
> let y = optional
> z == 2 
> else { ... }
> 
> 

I think this is going to be a matter of taste. I do not prefer the second 
example.

>> 
>> I'd really like to see a separate newline-as-separator proposal brought 
>> forward and formally reviewed. It's garnered a few very vocal supporters but 
>> it really doesn't fall under the umbrella of this proposal. I'd like the 
>> matter to be settled one way or the other for the sake of closure.
> 
> The other discussion has been about introducing newline-as-separator for 
> comma separated lists.  
> 
> I raised the question in my review because Swift already uses 
> newline-as-separator for semicolon separated lists (statements).

If the guard elements were in a braced scope, I might feel differently. I 
prefer the form that is presented. 

-- E



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 very strongly as a statement ender 
> to me, and yet at the same time, it's still visually quite close to `,`. My 
> first impression was that the proposal had an embarrassing typo in the very 
> first example.
> 
> My suggestion would be to reuse our normal && operator:
> 
>   guard
>   x == 0 &&
>   let y = optional &&
>   z == 2
>   else { ... }


In theory because if/guard/when create a mini scope, this might be possible to 
use in this context but I'll defer to Chris to reply to the issue of whether 
it's a better separator. Keep in mind that the proposal doesn't update the 
grammar for each of the conditions so the following is possible

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 be very challenging to the compiler.

-- Erica

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 to 
> use them a lot again?
> 
> 
> Third, the format will look like this in most people’s code:
> guard x == 0; let y = optional; y == 2 else {  //can the third bool condition 
> even refer to y? Is it still in scope?
>   ... 
> }
> (in the above example, y == 2 is related to the optional that precedes it. 
> Now it looks like a distinct statement)
> 
> compared to
> 
> guard x == 0, let y = someOptional where y == 2 else { 
>   ... 
> }
> 
> 
> To my eyes: the old way reads more naturally and looks less heavy. I think it 
> keeps its expressiveness and also keeps it somewhat poetic.

This proposal serves the grammar, enabling it to simplify,  the compiler to 
avoid errors, and the developer to intermingle tests more naturally, as you 
would in processing JSON without having to nest or sequence separate guard 
statements. A main goal is differentiating the commas between conditions and in 
binding conditions, as you ask about below

I don't think it's practical to use a second braced scope:

guard {
   condition
   condition
   condition
} else {
   leave scope
}

This would be confusing to anyone doing conditional binding for use in the top 
level scope; the bindings would "escape" the braces. Using semicolons 
establishes a balance between separating different kinds of conditions and 
allowing comma-delineated multiple bindings.

Current state:

* Confusing, complicated, organically grown grammar
* Inability to use independently standing Boolean assertions after the first 
(except for one outlier availability case)

Proposed state:

* Very simple grammar
* Developer-directed ordering of binding, availability, Boolean assertions, 
cases, used in the order they're consumed
* Slightly uglier

The cost for this is a separator between conditions

> 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 
> kinds of clauses (which aligns with the rest of the Swift language)”

guard let x = opt1, y = opt2, z = opt3; booleanAssertion else { }

> 
> I rarely see any semicolons after the removal of C loops. So if someone could 
> put me to where this is used elsewhere in Swift, please do!

Using semicolons brings conditions in-line with how semicolons are used as 
separators elsewhere in the Swift grammar.

-- Erica


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 
>>> kinds of clauses (which aligns with the rest of the Swift language)”
>> 
>> guard let x = opt1, y = opt2, z = opt3; booleanAssertion else { }
>> 
>>> 
>>> I rarely see any semicolons after the removal of C loops. So if someone 
>>> could put me to where this is used elsewhere in Swift, please do!
>> 
>> Using semicolons brings conditions in-line with how semicolons are used as 
>> separators elsewhere in the Swift grammar.
> 
> Not really.  We can use a newline instead of the semicolon elsewhere.

Outside of braces? Think of the guard/if/while creating a new miniscope that 
has no braces, and whose value assignments escape to the surrounding scope. I 
defer to Chris for better technical answers.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 be very challenging to the compiler.
> 
> I'm not sure it is. `let` and `case` are not valid in an expression, so an 
> `&&` followed by `let` or `case` must be joining clauses. On the other side 
> of things, Swift's `&&` doesn't ever produce an optional, so if we're parsing 
> an expression at the top level of an if-let, an `&&` must indicate the end of 
> the clause. An if-case *could* theoretically include an `&&`, but pattern 
> matching against a boolean value seems like a fairly useless thing to do in a 
> context that's specifically intended to test booleans.

Let me answer in another way that speaks to my background which isn't in 
compiler theory: The use of && may produce cognitive overload between the use 
in Boolean assertions and the use in separating condition clauses.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 Simulator/Emulator vs Hardware targets
A way to test for debug builds
A way to test for platform conditions (bigendian, littlendian, bitwidth 32 and 
64, objc-interop, see lib/Basic/LangOptions.cpp)

This splintered down into a series of draft proposals. The first adopted 
proposal, SE-0075 

 adds a build configuration import test similar to Clang's __has_include. It 
lets you test whether a module like UIKit is available, letting you customize 
code for specific modules.

Next up on my list is debug-specific coding. Summarizing to date:

There's a general consensus that a debug state occurs when assertions can fire 
and are not disabled by compile-time optimizations.
The concept of "debug" is nuanced enough that introducing a single  #if debug 
build configuration test is insufficient for substantial set of community 
members who interacted in previous discussions and Swift developers who have 
sent me feedback outside this list.
Conditioning debug on Xcode debug/release schemes is a no-go.
Hidden helper functions already exist in Swift.
Members of the core team believe using build configurations is the wrong point 
to conditionalize code. 

Joe Groff wrote, "We specifically avoided making debug/release an #if condition 
because we considered #if to be the wrong point at which to start 
conditionalizing code generation for assertions. Though the final executable 
image's behavior is unavoidably dependent on whether asserts are enabled, we 
didn't want the SIL for inlineable code to be, since that would mean libraries 
with inlineable code would need to ship three times the amount of serialized 
SIL to support the right behavior in -Onone, -O, and -Ounchecked builds. 
Instead, the standard library has some hidden helper functions, 
_isDebugAssertConfiguration, _isReleaseAssertConfiguration, and 
_isFastAssertConfiguration, which are guaranteed to be constant-folded away 
before final code generation."

My pitch: I want to promote these three helper functions to the standard 
library and remove their underscore prefixes. My primary use case is to limit 
logging and development-servicing functions (for example, statistical 
measurements) to "debug" builds. I believe a sufficient quorum of the community 
has similar needs that would be served by making these first class "listed" 
functions.

Doing so:

Eliminates the build configuration approach
Eliminates the need to define what "debug" means
Conditions configuration testing on assertion firing state not Xcode schemes or 
build flags (e.g. -D debug)
Uses already-existing global functions, requiring no coding

Thoughts?

-- E
p.s. I'd warmly welcome any third party assistance with the outstanding requests


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 just pick up "// FIXME: “ comments and summarize them as 
> issues.  Xcode already shows them in its jump bar.
> 
> That said, I can see a use for #error, as Charlie shows downthread:
> 
> #if os(OSX)
>   /// ...
> #if os(Linux)
>   /// ...
> #else
>   #error("This OS isn't supported yet.").
> #endif
> 
> -Chris

One could make a weak argument that #warning/#error/#message make a nice family 
of flexible alerts
just because they're kind of what we're used to already. A possible use case 
for warning:

#if canImport(Cocoa)
#warning("Your UI will look bad. This code works under OS X but this 
library is intended for iOS-like environments")
#elseif !canImport(UIKit)
#error("Unsupported target GUI")
#endif

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 one proposed in SE-0050 
>> (but potentially extended) seems sufficiently general to solve the existing 
>> use cases as well as solve the floating point error accumulation issue.  
>> Once the design of this iterates on swift-evolution, it would be great to 
>> see a revised version of this proposal.
> 
> Can you give any indication of what's wrong with the proposed API?

Piling on because it would really help to get a sense of what direction the 
core team is looking for. Unless we can figure out in advance what the core 
team is actually looking for, it's hard to respond with the request for 
revision. The feedback says: "they don't think this API change is the right 
approach" and "The core team believes that the existing strideable API cannot 
efficiently and correctly handle all the real-world use cases one would want." 

I'd like to iterate the design as requested, but it's hard to know where to 
start. So let me discuss things that can be strode along:

There are four types of bounded intervals (open and closed on each end) that 
can be traversed in either direction, four types of unbounded interval (open 
and closed starting points, heading positively and negatively), and both 
integer and floating point applications of strides along these:

Bounded Intervals: [A, B), (A, B], (A, B), [A, B]
Unbounded Intervals: (A, ∞), [A,  ∞), ( -∞, A), (-∞, A]

(Technically, there's also the empty interval (), and the full number line (-∞, 
∞), which really don't come into play for sequences but might play a role in 
pattern matching.)

The simplest API to handle all these cases would be:

`stride(from/off:, by:, towards/to/through:)` for sequences along bounded 
intervals and 
`stride(from/off:, by:)` for sequences along unbounded intervals. 

In these calls, `from` is inclusive and `off` is exclusive of the first value.

SE-0051 

 covers the details of what the semantics of `towards`/`to`/`through` mean: 

towards meaning a..=b, a>=..b, for example: 1 through 5 by 1 is [1, 2, 3, 4, 5] and 1 
through 10 by 8 is [1, 9, 17]

The acceptance of SE-0045 and SE-0099 and makes implementing each of these 
sequence types much easier.  The state version can use the error-reducing 
iteration multiplier. The non-state version is perfect for integer math.

-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md
>>  
>> 
> Thanks everyone.  FYI, Erica and I discussed it offlist and agreed to amend 
> the proposal: now you can use semicolons or a newline to separate clauses of 
> different types.
> 
> -Chris

Also, I updated the proposal to make clear that `where` clauses are being 
removed from both binding conditions and case conditions. This will not affect 
the use of where clauses elsewhere, such as in for-in loops and switch 
statements.

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 supported tuple destructuring in parameter lists, and we took 
> it out to simplify the language and eliminate special cases.  Whereas as a 
> very early version of swift modeled parameter lists using patterns (something 
> very common in functional programming languages) we have progressively and 
> intentionally move away from that approach.
> 
> -Chris

You can't splat but you can decompose a tuple by assignment:

let a = (1, 2, 3)
func foo(v1: Int, v2: Int, v3: Int) { print (v1, v2, v3) }

// Still works:
let (b, c, d) = a; print(b, c, d)

// And this works after the assignment:
foo(v1: b, v2: c, v3: d)

// No longer works:
foo(a) // tuple splat is gone

// These all work though:
func bar(arg: (Int, Int, Int)) { print(arg.0, arg.1, arg.2) }
bar(arg: a)
bar(arg: (b, c, d))

// You can add field names in the func's decl type
func blort(arg: (x: Int, y: Int, z: Int)) { print(arg.x, arg.y, arg.z) }
blort(arg: a) // works
blort(arg: (b, c, d)) // works

// But the following doesn't work, Error is "cannot 
// convert value of (l: Int, m: Int, n: Int)"
blort(arg: (l: b, m: c, n: d))

I vaguely remember a discussion onlist about creating typealiases and then 
using casting to convert between structurally identical tuples but I don't 
think it went anywhere or had a strong use case.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 newcomers, when 
> explaining closure shorthand argument names to a classroom of computer 
> science students (aged 21) discovering Swift.
> 
> The feedback some gave me, during the course, was quite surprisingly strong 
> and negative about this “$n” convention. This convinced me to write this 
> proposal : for newcomers, the “$n” zero-based is something wrong.
> 
> I understand that association between tuples and function parameters in Swift 
> is to be removed, but, in this case, as we have no parameters at all, I 
> thought this was a distinct enough situation.
> 
> As suggested, considering this is a kind of compiler magic, using #0, #1 
> instead, may indeed be a better alternative.
> 
> I’m still waiting some feedback before writing an official proposal.

I really don't see a pressing need to change this. Zero-based counting is used 
in Swift arrays. I don't think the $-prefix is either superior or inferior to 
alternatives such as # or %, and has precedent in unix shell programming. Swift 
closures allow you to easily introduce meaningful names by using a closure 
signature with a parameter clause. 

-- E
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Ad hoc enums / options

[Erica Sadun via swift-evolution]

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 size: CGSize,
operation: (.Fit | .Fill) = .Fit
) -> UIImage {


where I don't have to establish a separate enumeration to include ad-hoc 
enumeration-like semantics for the call. A while back, Yong hee Lee introduced 
anonymous enumerations (and the possibility of anonymous option flags) but the 
discussion rather died.

I'm bringing it up again to see whether there is any general interest in 
pursuing this further as I think the second example is more readable, 
appropriate, and Swifty than the first, provides better semantics, and is more 
self documenting.

Thanks for your feedback,

-- Erica

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 under the "not 
available to ObjC" or "if made available to ObjcC, does not fall under the 
scope of introduction of this idea" umbrellas.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 much 
responsibility Swift has to this area, especially when considering the language 
going multiplatform.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 proposed here, that 
> would be useful to restrict what can come after `where`. Moreover, I see no 
> contention with the argument that arbitrary Boolean assertions should be 
> possible after a let binding.
> 
> Finally, it is a stated goal of the core team that there shouldn't be 
> multiple 'dialects' of Swift, and that where possible there should be one 
> general solution rather than two options.
> 
> Given these premises, I have to conclude that *if* the motivating issue is to 
> be fixed, we must get rid of `where`.


This proposal does affect where clauses in:
case conditions (case pattern initializer where-clause?)
optional binding conditions (optional-binding-head 
optional-binding-continuation-list? where-clause?)
This proposal does not affect where clauses in:
for-in statements (for case? pattern in expression where-clause? code-block)
case item lists (case-item-list → pattern where-clause? | pattern where-clause? 
, case-item-list)
catch clauses (catch pattern? where-clause? code-block)
generic parameter clause's requirement clause
What I'm hearing is that at least some developers would like to retain where 
clauses in case conditions and optional binding conditions but still allow the 
more controllable logic introduced by differentiating condition types with 
semicolons or newlines. Is that a fair summary? 

Here is the where clause grammar:

where_clause = where where_expression
where_expression = expression

I think technically, by adding the new separators, the `where` need not be 
disallowed. That leaves the following questions:

* Should `where` clauses be allowed where the contents of the where clause have 
no connection to the condition that precedes it?
* Is there a technical way to to check for such conformance?
* Should the `where` clause be left unconstrained, as it currently is in switch 
statements and for loops, etc, which is consistent with the rest of the 
language but contrary to the spirit of safety in Swift?
* Should `where` clauses be re-evaluated throughout the language?

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 > >
>> Subject: Re: [swift-evolution] Ad hoc enums / options
>> Date: May 31, 2016 at 11:43:43 AM MDT
>> To: Charles Constant mailto:char...@charlesism.com>>
>> Cc: Swift Evolution > >, Christopher Kornher > >
>> Reply-To: Charlie Monroe > >
>> 
>> I have mixed feelings about this since it may lead to redeclarations over 
>> and over of the same values instead of actually declaring an enum.
> 
> 
> 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.
> 
> #2  does add to the length of function declarations, so it is a tradeoff. 
> Perhaps the name could be optional, but...
> 
> #2 would improve debug representations of the value by providing a name that 
> can be found in source code
> 
> In a full-featured metadata system, it would probably be nice to have a type 
> for the enum to simply the handling of all enums. 
> 
> #2 is more future-proof. Systems get more complex over time and one use of a 
> type becomes many. 
> The enum type name (auto-generated or required, it makes no difference) would 
> be scoped to the function’s namespace e.g. (fixing the typo) :
> 
> class MyImage  {
>   func scaleAndCropImage(
>   image: UIImage,
>   toSize size: CGSize,
>   operation: ScaleCropFitFill{ .Fit | Fill} = .Fit
> 
>   ) -> UIImage {…}
> }
> 
> would be equivalent to:
> 
> class MyImage  {
>   enum  ScaleCropFitFill {
>   case  Fit
>   case  Fill
>   } 
> 
>   func scaleAndCropImage(
>   image: UIImage,
>   toSize size: CGSize,
>   operation: ScaleCropFitFill = .Fit
>   ) -> UIImage {…}
> }
> 
> There are two ways that an implementation could evolve from having one use of 
> the enum in a call to multiple uses;
> 
> 1) The function is refactored into more functions internal to the original 
> function’s namespace: module/class/struct/enum.
>   In this case, it would be appropriate to leave the enum declaration in 
> function declaration to indicate that this is the only public use of the enum.
> 2) More public functions are created that use the enum
>   In this case, it would be appropriate to declare the enum within the 
> same scope. Existing code would not be affected. Smart editors could provide 
> this refactoring.
> 
> - Chris K

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

>> 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 size: CGSize,
>>  operation: ScaleCropFitFill{ .Fit | Fill} = .Fit
>> 
>>  ) -> UIImage {…}
>> }
>> 
>> would be equivalent to:
>> 
>> class MyImage  {
>>  enum  ScaleCropFitFill {
>>  case  Fit
>>  case  Fill
>>  } 
>> 
>>  func scaleAndCropImage(
>>  image: UIImage,
>>  toSize size: CGSize,
>>  operation: ScaleCropFitFill = .Fit
>>  ) -> UIImage {…}
>> }

This is not the direction I'm hoping to move in.

If an enumeration is to be used in more than one place, it should be a proper 
enumeration. Swift already offers dependent type support.  Single-point ad-hoc 
enumerations create better semantics for moving from if statements that test on 
Boolean values to switch statements that test on phrases, without creating 
dependencies on other types. As Tony A points out, 

> Having argument labels solves some of the problems that come along with 
> boolean arguments, but "fitImage" is a great example where the false case 
> ("not fit?") doesn't really convey enough information (or can convey 
> misleading information).


-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 no way as 
far as I know this to enforce it in the grammar and the proposal allows both 
clauses to be stated even without the connecting word. You could make a vague 
argument, I suppose, for renaming `where` to `when` but all in all, even 
killing `where` we benefit with better expressive capabilities and a simpler 
grammar.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 need to list out all cases in the type 
> of the variable (unless these anonymous enums have structural subtyping).  
> This is fragile.  Any time that list changes all variable declarations will 
> have to be updated.
> 
> Functions are implemented once and usually called more many times.  It's 
> better for callers if you just write it like this:
> 
> enum FitOrFill { case fit, fill }
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> operation: FitOrFill = .fit
> ) -> UIImage {
> 
> So unless these anonymous enums are structurally subtyped I think it's a bad 
> idea.  And introducing structural subtyping here seems like a pretty large 
> hammer for this use case.


>From the caller's point of view, the type must be inferable and exactly match 
>a token listed in the declaration (which would also appear in Quick Help):

let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill)

You would not be able to assign `.fill` to a variable and use that for the 
operation value.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 moment you need `operation` to be computed or kept in a variable. 
> Then you need to start copying your anonymous enum type all over your source, 
> and there's no central place to make changes. The same thing is true of 
> tuples, but tuples are easy to structure and destructure from individual 
> values on the spot; anonymous enums aren't really like that.

And the obvious answer is you can have up to 255 of these babies for the 
anonymous enum type, and be able to pass numerical equivalents UInt8 with 
compile time substitution. That the ad-hoc enumeration is basically a syntactic 
shorthand for UInt8, with an enforced upper bound compile time check simplifies 
everything including switch statements.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 probably digressed more than she really should
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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-Gordon  
> wrote:
> 
>> My pitch: I want to promote these three helper functions to the standard 
>> library and remove their underscore prefixes.
> 
> These functions currently have implementations like this:
> 
>   @_transparent
>   @warn_unused_result
>   public // @testable
>   func _isDebugAssertConfiguration() -> Bool {
> // The values for the assert_configuration call are:
> // 0: Debug
> // 1: Release
> // 2: Fast
> return Int32(Builtin.assert_configuration()) == 0
>   }
> 
> I think how this works is:
> 
> * @_transparent makes sure these functions are always inlined at the call 
> site.
> * Most things in the standard library are *also* @_transparent.
> * Therefore, after both (or more!) inlinings happen, you get the 
> `Builtin.assert_configuration()` of the code calling into the standard 
> library.
> 
> Needless to say, this is *extremely* weird and magical, and I'm skeptical of 
> the idea that we should expose it as a normal function call.
> 
> I think a better design which would accurately convey its magic is to add a 
> type to the standard library:
> 
>   enum BuildKind: Int32 { case debug, release, unchecked }
> 
> (Note: the names in this could use some bikeshedding. Put that aside.)
> 
> And then add a `#buildKind` compiler substitution which is equivalent to:
> 
>   BuildKind(rawValue: Int32(Builtin.assert_configuration()))
> 
> Now you can surround your debug-only code with `#buildKind == .debug`. Or you 
> can capture the *call site's* build kind with a default parameter:
> 
>   func log(_ message: String, level: LogLevel = .info, buildKind: 
> BuildKind = #buildKind)
> 
> Even the standard library might be able to do this if it wanted to, allowing 
> your code to enable or disable asserts based on whether your caller's code is 
> in debug mode or not:
> 
>   func assert(@autoclosure condition: () -> Bool, @autoclosure _ message: 
> () -> String = default, file: StaticString= #file, line: UInt = #line, 
> buildKind: BuildKind = #buildKind)
> 
> (I wouldn't suggest that every stdlib member add such a default parameter; 
> most should continue to rely on `@_transparent`. But I think that could be 
> useful for calls like `assert()` and `precondition()`.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 demand for this feature
> 
> -- E


Following up to myself, now that I'm actually using this, I realize that 
avoiding using a build configuration test might not be the best idea from the 
developer experience side of things: 

main.swift:7:9: warning: will never be executed
print("Not debug assert configuration")
^
main.swift:4:8: note: condition always evaluates to true
if isDebugAssertConfiguration() {
   ^
Testing debug assertion

Whereas going with if #if debugassert() would simply make code "disappear".

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 discussion started. Have at it.

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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(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 discussion started. Have at it.
> 
> See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830 
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830>
>  


And added alignof/alignofValue plus the original discussion thread

https://github.com/apple/swift-evolution/pull/350/files

-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 
> @availability(*, unavailable, message: "use MemoryLayout.size, etc.") 
> public init(){}.
> 
> It's a nice syntax, but I'm not fully comfortable with the suggestion that 
> sizeofValue(), etc. should go.  Also, I wonder about the static vs. dynamic 
> type issue here (despite having started the last thread, I still haven't sat 
> down to think it through).
> 

Updated with all the feedback so far. Will keep an eye on this.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 discussion) is:

/// Returns the contiguous memory footprint of `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `size(of: X.self)`, when `X` is a class type, is the
/// same regardless of how many stored properties `X` has.
public func size(of: T.Type) -> Int

/// Returns the contiguous memory footprint of  `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `size(of: a)`, when `a` is a class instance, is the
/// same regardless of how many stored properties `a` has.
public func size(ofValue: T) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func spacing(of: T.Type) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func spacing(ofValue: T) -> Int

/// Returns the minimum memory alignment of `T`.
public func align(of: T.Type) -> Int

/// Returns the minimum memory alignment of `T`.
public func align(ofValue: T) -> Int


> On Jun 1, 2016, at 11:24 PM, Patrick Smith  wrote:
> 
> I really like this idea. This IMO is lower level functionality than 
> `type(of:)` (née dynamicType), so I think it makes sense for it to be grouped 
> under its own domain, the MemoryLayout type.
> 
> Plus MemoryLayout can be extended with new convenience methods.
> 
> I’m fine with those old methods being removed, but I never use them so! Is it 
> the same as calling type(of:) then using that with MemoryLayout? I imagine 
> they could be fixit’d easily, and that they compile down to the same 
> underlying code.
> 
> Patrick
> 
>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 2. Dave A. and others expressed the opinion that these should probably not 
>> be global functions; his preference was for:
>> 
>> ```
>> MemoryLayout.size // currently sizeof()
>> MemoryLayout.spacing // currently strideof()
>> MemoryLayout.alignment // currently alignof()
>> ```
>> 
>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
>> are better off removed altogether. I don't know if people are going to be 
>> happy about this idea.
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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
alignofValue5   5   154
strideof347 19  347
strideofValue   4   5   163
Type-based calls like sizeof() are poor candidates for parameter labels. While 
it's acceptable to write sizeof(Int), but one must write size(of: Int.self) 
(with the trailing self) when the function has a label. For this reason, this 
proposal prefers using no-label calls for types (otherwise they would have been 
ofType) and labeled calls for values:

print(sizeof(Int)) // works
print(sizeof(Int.self)) // works

func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
func withLabel(label label: T.Type) -> Int { return sizeof(T) }


// Works
print(withoutLabel(Int))

// Works
print(withLabel(label: Int.self))

// Does not work
// error: cannot create a single-element tuple with an element label
// print(withLabel(label: Int)) 


So with this in mind:

/// Returns the contiguous memory footprint of `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `size(X.self)`, when `X` is a class type, is the
/// same regardless of how many stored properties `X` has.
public func size(_: T.Type) -> Int

/// Returns the contiguous memory footprint of  `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `size(of: a)`, when `a` is a class instance, is the
/// same regardless of how many stored properties `a` has.
public func size(of: T) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func spacing(_: T.Type) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func spacing(of: T) -> Int

/// Returns the minimum memory alignment of `T`.
public func alignment(_: T.Type) -> Int

/// Returns the minimum memory alignment of `T`.
public func alignment(of: T) -> Int
-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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-evolution 
>  wrote:
> 
> Supporting Dave A, type-based calls are much more likely to be used than 
> instance calls, unlike with dynamicType/type(of:)
> 
> Term  stdlib search   gist search Google site:github +swift
> sizeof157 169 4880
> sizeofValue   4   34  584
> alignof   44  11  334
> alignofValue  5   5   154
> strideof  347 19  347
> strideofValue 4   5   163
> Type-based calls like sizeof() are poor candidates for parameter labels. 
> While it's acceptable to write sizeof(Int), but one must write size(of: 
> Int.self) (with the trailing self) when the function has a label. For this 
> reason, this proposal prefers using no-label calls for types (otherwise they 
> would have been ofType) and labeled calls for values:
> 
> print(sizeof(Int)) // works
> print(sizeof(Int.self)) // works
> 
> func withoutLabel(thetype: T.Type) -> Int { return sizeof(T) }
> func withLabel(label label: T.Type) -> Int { return sizeof(T) }
> 
> 
> // Works
> print(withoutLabel(Int))
> 
> // Works
> print(withLabel(label: Int.self))
> 
> // Does not work
> // error: cannot create a single-element tuple with an element label
> // print(withLabel(label: Int)) 
> 
> 
> So with this in mind:
> 
> /// Returns the contiguous memory footprint of `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(X.self)`, when `X` is a class type, is the
> /// same regardless of how many stored properties `X` has.
> public func size(_: T.Type) -> Int
> 
> /// Returns the contiguous memory footprint of  `T`.
> ///
> /// Does not include any dynamically-allocated or "remote" storage.
> /// In particular, `size(of: a)`, when `a` is a class instance, is the
> /// same regardless of how many stored properties `a` has.
> public func size(of: T) -> Int
> 
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(_: T.Type) -> Int
> 
> /// Returns the least possible interval between distinct instances of
> /// `T` in memory.  The result is always positive.
> public func spacing(of: T) -> Int
> 
> /// Returns the minimum memory alignment of `T`.
> public func alignment(_: T.Type) -> Int
> 
> /// Returns the minimum memory alignment of `T`.
> public func alignment(of: T) -> Int
> -- E
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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
> static let size: Int
> static let spacing: Int
> static let alignment: Int
> 
> let size: Int
> let spacing: Int
> let alignment: Int
> }
> 
> let size = MemoryLayout.size
> let sizeOfValue = MemoryLayout(42).size

And amended Alternatives with this. :)

- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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() {}
>>> init(t: T) { /* throw away the value */ }
>> 
>> And amended Alternatives with this. :)
> 
> Thanks!  Can you change the init signature with Pyry’s improvement: `init(_: 
> @autoclosure () -> T) {}`?

https://github.com/erica/swift-evolution/blob/sizestride/proposals/-sidestride.md

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 >> > wrote:
>>> 
> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu > > wrote:
> We could have a primary initializer like this:
> 
> init(_ type: T.Type)
> 
> It would look better than a default initializer that requires the type to be 
> passed as a generic argument.  The fact that it is not labeled would make it 
> clear that this is the primary initializer.
> 
>> 
>> I still think the value-based APIs are misleading and that it would be 
>> better to ask people to just use a type explicitly.
> 
> Sure.  I don't necessarily disagree.  But I think it's important to make 
> clear that this is orthogonal to the struct vs free function discussion.  
> That was the main point I was trying to make.  :)
> 
>> 
>>> Adding the label will eliminate the potential for confusion about type vs 
>>> metatype.  Wanting to know the size of the metatype is probably extremely 
>>> rare, but there is not reason to prohibit it.
>> 
>> I agree that the label makes the problem better.
>> 
>> John.


I do want to say that while I'm including this in Alternatives Considered (and 
will update as soon as we finish lunch), that I stand by the freestanding 
functions as preferable to this clever but extremely indirect approach.

I believe the MemoryLayout type introduces a level of indirection that is less 
helpful in the rare times the user will consume this functionality, that it 
clutters calls and adds cognitive burden for reading code.

Let me give you some examples:

let errnoSize = sizeof(errno.dynamicType)
return sizeof(UInt) * 8
sendBytes(from: &address, count: sizeof(UInt.self))
_class_getInstancePositiveExtentSize(bufferClass) == sizeof(_HeapObject.self)
bytesPerIndex: sizeof(IndexType))

In every example, calling a size function's clarity is simpler than using the 
Memory Layout approach:

let errnoSize = MemoryLayout.init(t: errno).size
return MemoryLayout.size * 8
sendBytes(from: &address, count: MemoryLayout.size)
_class_getInstancePositiveExtentSize(bufferClass) == 
MemoryLayout<_HeapObject.self>.size
bytesPerIndex: MemoryLayout.size

The full type specification lends the calls an importance and verbosity they 
don't deserve compared to their simpler counterparts. The eye is drawn every 
time to the "MemoryLayout" pattern:

* Prominence of the type constructor
* Simplicity of the function call
* Number of code characters used
* Swift's adherence to a mantra of concision and clarity.

It fails all these. To put it in usability terms: it's a big stinking mess 
compared to the readability and eye tracking of the simpler function. (I've 
cc'ed in Chris Lattner, who has people who can test this kind of thing on call.)

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 was a deliberate choice in that case.

And mentioned.

https://github.com/erica/swift-evolution/blob/sizestride/proposals/-sidestride.md

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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.
>> 
>> John.
> 
> 
> I agree; in fact why aren’t these properties on the type itself? The type is 
> what matters; why can’t the type just tell me it’s size? 
> Having free functions or magic operators seems to be another holdover from C. 
> 
> 
> Int.size
> Int.alignment
> Int.spacing
> 
> let x: Any = 5
> type(of: x).size
> 
> 
> The compiler should be able to statically know the first three values and 
> inline them. The second is discovering the size dynamically.
> 
> 
> Russ

If achievable, this would certainly be clean and elegant.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 clear that, even if we added a property on all types, 
> it would not be acceptable to name that property something like "size"; it 
> would have to be something longer like "storageSize".

Suggested names so far for augmenting the base:

* memorySize, memoryAlignment, memorySpacing/memoryStride
* storageSize, storageAlignment, storageSpacing/storageStride

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 analogy with 
> UnsafePointer) isn't quite apt.
> 
> And I'm not sure we really want to encourage anyone else to be defining a 
> global function named size(of:) anyway, so I wouldn't consider vacating that 
> name for end-user purposes to be a meaningful positive.
> 
> I was thinking more of situations where someone is in a scope (such as a 
> method in a struct or class) that has its own size(of:) method but also needs 
> to do something with the global size(of:) and now has to distinguish the two. 
> I'll admit that the likelihood of all of those stars aligning is probably 
> rare, though.
> 
> That being said, I see no reason to choose a very general name over one that 
> is far more descriptive. We should optimize for the N times an expression is 
> read instead of the one time it's written.

/// Returns the contiguous memory footprint of `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `memorySize(ofType: X.self)`, when `X` is a class type, is 
the
/// same regardless of how many stored properties `X` has.
public func memorySize (ofType: T.Type) -> Int

/// Returns the contiguous memory footprint of  `T`.
///
/// Does not include any dynamically-allocated or "remote" storage.
/// In particular, `memorySize(of: a)`, when `a` is a class instance, is the
/// same regardless of how many stored properties `a` has.
public func memorySize (of: T) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func memoryInterval(ofType: T.Type) -> Int

/// Returns the least possible interval between distinct instances of
/// `T` in memory.  The result is always positive.
public func memoryInterval (of: T) -> Int

/// Returns the minimum memory alignment of `T`.
public func memoryAlignment(ofType: T.Type) -> Int

/// Returns the minimum memory alignment of `T`.
public func memoryAlignment (of: T) -> Int


https://github.com/erica/swift-evolution/blob/sizestride/proposals/-sidestride.md
 


-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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'.  
>> Verbosity was a deliberate choice in that case.
> 
> You know...rather than introducing a new type like MemoryLayout, would it 
> make sense to do this with static properties on UnsafePointer?
> 
>   UnsafePointer.pointeeSize
>   UnsafePointer.pointeeAlignment
>   UnsafePointer.pointeeSpacing
> 
> If you need this information, 90% of the time you're probably using 
> UnsafePointer or one of its friends, right?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

Some quick greppage -- E

public/core/BridgeObjectiveC.swift:_sanityCheck(sizeofValue(self) >=
public/core/Builtin.swift:public func sizeofValue(_:T) -> Int {
public/core/Character.swift:let bits = sizeofValue(initialUTF8) &* 8 &- 1
public/core/Unicode.swift:  if utf8Count < sizeofValue(result) {

private/SwiftPrivateLibcExtras/Subprocess.swift:let errnoSize = 
sizeof(errno.dynamicType)
private/SwiftPrivateLibcExtras/SwiftPrivateLibcExtras.swift:return 
sizeof(UInt) * 8
private/SwiftReflectionTest/SwiftReflectionTest.swift:  sendBytes(from: 
&address, count: sizeof(UInt.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  sendBytes(from: &value, 
count: sizeof(T.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  fread(&value, 
sizeof(UInt.self), 1, stdin)
private/SwiftReflectionTest/SwiftReflectionTest.swift:  sendBytes(from: 
&numInfos, count: sizeof(UInt.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  let pointerSize = 
UInt8(sizeof(UnsafePointer.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  let anyPointer = 
UnsafeMutablePointer(allocatingCapacity: sizeof(Any.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
anyPointer.deallocateCapacity(sizeof(Any.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  allocatingCapacity: 
sizeof(ThickFunction0.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
fn.deallocateCapacity(sizeof(ThickFunction0.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  allocatingCapacity: 
sizeof(ThickFunction1.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
fn.deallocateCapacity(sizeof(ThickFunction1.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  allocatingCapacity: 
sizeof(ThickFunction2.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
fn.deallocateCapacity(sizeof(ThickFunction2.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  allocatingCapacity: 
sizeof(ThickFunction3.self))
private/SwiftReflectionTest/SwiftReflectionTest.swift:  
fn.deallocateCapacity(sizeof(ThickFunction3.self))
public/core/BridgeObjectiveC.swift:   
sizeof(Optional>.self) * count)
public/core/Builtin.swift:/// In particular, `sizeof(X.self)`, when `X` is a 
class type, is the
public/core/Builtin.swift:public func sizeof(_:T.Type) -> Int {
public/core/Builtin.swift:  return Int(Builtin.sizeof(T.self))
public/core/Builtin.swift:/// In particular, `sizeof(a)`, when `a` is a class 
instance, is the
public/core/Builtin.swift:  return sizeof(T.self)
public/core/Builtin.swift:  _precondition(sizeof(T.self) == sizeof(U.self),
public/core/Builtin.swift:sizeof(_HeapObject.self),
public/core/Character.swift:// Notice that the result of sizeof() is a 
small non-zero number and can't
public/core/HeapBuffer.swift:  sizeof(_HeapObject.self),
public/core/HeapBuffer.swift:  _valueOffset() + sizeof(Value.self),
public/core/ManagedBuffer.swift:  
_class_getInstancePositiveExtentSize(bufferClass) == sizeof(_HeapObject.self)
public/core/ManagedBuffer.swift:  == _valueOffset + sizeof(Value.self)),
public/core/ManagedBuffer.swift:  
_class_getInstancePositiveExtentSize(bufferClass) == sizeof(_HeapObject.self)
public/core/ManagedBuffer.swift:  == _valueOffset + sizeof(Value.self)),
public/core/ManagedBuffer.swift:  sizeof(_HeapObject.self),
public/core/ManagedBuffer.swift:  _valueOffset + sizeof(Value.self),
public/core/Runtime.swift.gyb:  _sanityCheck(sizeof(_Buffer32.self) == 32)
public/core/Runtime.swift.gyb:  _sanityCheck(sizeof(_Buffer72.self) == 72)
public/core/Runtime.swift.gyb:  for _ in 0..<(2 * sizeof(UnsafePointer) - 
result.utf16.count) {
public/core/Sequence.swift:// `n` * sizeof(Iterator.Element) of memory, 
because slices keep the entire
public/core/StringUTF8.swift:  let utf16Count = 
Swift.min(sizeof(_UTF8Chunk.self), count - i)
public/core/StringUTF8.swift:return 0xFF << 
numericCast((sizeof(Buffer.self) &- 1) &* 8)
public/core/Unicode.swift:  let utf8Max = sizeof(_UTF8Chunk.self)
public/core/VarArgs.swift:count: (sizeof(T.self) + sizeof(Int.self) - 1) / 
sizeof(Int.self))
public/core/V

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

[Erica Sadun via swift-evolution]

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 Request: https://github.com/apple/swift-evolution/pull/350

Thanks, -- Erica

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 
inheriting behavior).
* Mention how enum specialization tends to limit possible cases, and consider 
how enum expansion/inheritance might be another direction for expanding 
existing enums (for example, when adding new phone models, but using an 
existing enum, with an extension), and how this might impact footprint in 
associated types.
* Discuss how behavior extensions on narrowed enums could be limited to the 
subset, so would be syntactically limited to the semantic subset as a 
motivation for why LCD colors might appropriately be used in a calibrate 
functions but the full color cases would not, etc.

-- E



> On Jun 3, 2016, at 3:35 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> Since this seems to have some interest, I've made a gist.
> 
> https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c 
> 
> Introduction
> 
> This proposal adds/creates syntax to allow ad hoc creation of enums whose 
> members are strict subsets of explicitly defined enums.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
> Motivation
> 
> Consider a situation where we have an enum Color which represents the entire 
> set of colors relevant to your application with many salient methods and 
> operations. We have also declared an enum LCDColorModel with only three 
> colors, red, blue, green .
> 
> enum Color {
> case red, orange, yellow, green, blue, indigo, violet
> …
> }
> 
> enum LCDColor {
> case red, green, blue
> }
> The cases in LCDColor in our scenario do not require different behavior from 
> their similarly named cases in Color. We would like, simply stated, to 
> explicitly restrict the cases allowed within a specific portion of our 
> software. There are, currently, a few approaches
> 1. Duplicate functionality in LCDColor
> - Completely manually
> - Protocols with ‘minimal’ manual duplication
> 2. Avoid duplication by allowing conversion to Color. 
> 
> Neither of these solutions make the subset relationship between Color and 
> LCDColor clear or strict.
> 
> Proposed solution
> 
> Add syntax to describe a restricted set of cases from an enum. 
> 
> typealias LCDColor = Color.(red|green|blue)
> LCDColor has all of the type and instance methods of Color.
> 
> Barring any technical reason, the ‘actual’ name of the type, in this example, 
> is Color.(red|green|blue) This makes the relationship to Colorsyntactically 
> clear. If a typealias is not desired, Color.(red|green|blue) should refer to 
> the same type as LCDColor
> Switching over Color.(red|green|blue) should only need to be exhaustive for 
> the three cases .red, .green, and .blue.
> Two initializers should be implicitly created
> Color to LCDColor?
> returns nil for all cases not in LCDColor
> LCDColor to Color
> Obvious and trivial implementation mapping cases from LCDColor to Color
> Casting should be allowed
> from superset to subset only using as? or as! syntax.
> from subset to superset using as
> Creating subsets of subsets is not allowed but reasonable conversions among 
> subsets should be allowed if technically feasible such that:
> Given subsets of C A and B, where A is a superset of B, the casting 
> relationship between A and B should be similar to that between C and either 
> of the other two named subsets.
> Detailed design
> 
> While I am unsure of the entirety of the design, I propose that name mangling 
> be used which, along with the declaration order restriction should mean that 
> all possible subsets have a stable and predictable name which contains all of 
> the information necessary to infer cases.
> If a mangled name approach is taken, the ordering of cases should be sorted 
> to ensure stability.
> 
> Alternatives considered
> 
> Do nothing. This feature is not strictly necessary but does allow for 
> expressivity not currently available in the language.
> implicitly create properties which convert to superset type.
> Impact on existing code
> 
> This is an additive change which should have no breaking change to existing 
> code.
> 
> 
> On Fri, Jun 3, 2016 at 4:57 PM, Austin Zheng  > wrote:
> I really like the idea behind this proposal.
> 
> Some questions:
> 
> - Would the enum 'slice' be a distinct type relative to the base enum?
> - On a related note, would shared cases between the sliced enum and the base 
> enum be implicitly convertible?
> - If they aren't implicitly convertible between each other, would there be an 
> affordance to perform conversions (e.g. a "parentEnumType" property and an 
> "init?(p

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

[Erica Sadun via swift-evolution]

> 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, .d=2.
> 
> The naive implementation breaks when a newly-loaded shared library or some 
> library evolution adds this type:
> 
>   (.a | .b | .c | .d)
> 
> In order to provide ABI stability in the face of arbitrary ad-hoc enum types 
> we must ensure that every ad-hoc enum value has a globally unique ABI 
> representation. 
> 
> You could constrain ad-hoc enum values to module or class boundaries and 
> prevent creation of types that use values from different places. For example, 
> if Foundation defines (.a | .b) then you can't define your own ad-hoc enum 
> (.a | .b | .c) that is compatible with Foundation's value for .a. Then the 
> implementation could use ordinary symbols. If usage of ad-hoc enums is not 
> constrained then ordinary symbols don't work because there is no universally 
> agreed-upon place where .a is defined.

In my mind, the ad hoc enum must be tied to a specific function or method 
signature. In doing so, it has a unique module/selector associated with it, so 
it's not just .a but rather Foo.funcname.a (assuming no more than one ad hoc 
enum per function) or Foo.funcname.3.a (assuming its the third parameter of the 
selector). The conversation has drifted a bit from my request.

If the enum needs to be used in more situations, it needs to be a proper enum 
because the semantics are tied to a higher level of visibility.

I'm striving for enhanced readability in intent (for example, where !x is a 
poor description of the option other than x, or even when there are >2 options 
that will never be used elsewhere such as fill, fit, scale) and in expression 
(choosing self-annotating switch statements over if statements, where its clear 
what each branch intends to do).

These enums would be limited to basic hashValue types, and would appear in 
QuickHelp as annotations of legal values to supply to the argument. My intent 
is that there never be more than 3-5 enumeration cases used in this anonymous 
fashion.

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] SE-0045 status?

[Erica Sadun via swift-evolution]

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 can't seem 
to find anything on either one. I'm hoping I'm just missing something but 
fearing it never got settled. If not, I'd be happy to jump in and do the 
paperwork, but I'd really prefer if the two methods were there and I was just 
somehow overlooking them.

Thanks!

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 PM, donny wals via swift-evolution 
>  wrote:
> 
> Hi,
> 
> When we’re using defer we write some code that we want to execute the moment 
> a scope exits.
> This leads to code that could read like:
> 
> let fibonacci = sequence(state: (0, 1)) { (pair: inout (Int, Int)) -> Int in
>defer { pair = (pair.1, pair.0 + pair.1) }
>return pair.0
> }
> 
> What I find strange about this is that we have to write the code that we want 
> to execute after the return before the return.
> 
> I’d like to propose a change to defer that would allow the above code to be 
> written as:
> 
> let fibonacci = sequence(state: (0, 1)) { (pair: inout (Int, Int)) -> Int in
>return pair.0
>defer { pair = (pair.1, pair.0 + pair.1) }
> }
> 
> This would make the intent of the code more clear (return first, then mutate 
> state). Not all cases can benefit from this change, but anytime you exit a 
> scope using a return I think it might be more clear to define the defer after 
> the return. The code would more closely mirror the intent of the code.
> 
> A rule of thumb I’ve come up with for this is that whenever you’re using 
> return to exit a scope, any defer in that same scope should be executed 
> regardless of it’s position in that same scope. This proposal would 
> supplement the way defer currently works.
> 
> What do you all think?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 
> allocate memory line is in a different scope that the guard/else statements. 
> Therefor, the defer { release memory } shouldn’t be executed if the guards 
> don’t hold.
> 
> D
> 
>> On 06 Jun 2016, at 22:09, Erica Sadun  wrote:
>> 
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 nature of the while loop. A where clause in a 
> while loop also has a different result than a where clause in a for loop.

The where_clause appears in the for in statement 

for_in_statement : 'for' 'case'? pattern 'in' expression where_clause? 
code_block

It's syntactic sugar because the expression can be already be limited through 
functional chaining of some sort or another. At the same time, it's nice and 
pleasant to have `where` and I'm not itching to throw it out. The same courtesy 
could be easily extend to `when` (because I don't really want to use the 
`while` keyword here, but I could easily be convinced otherwise because I don't 
have a strong stance either way):

for_in_statement : 'for' 'case'? pattern 'in' expression (where_clause | 
when_clause)? code_block
when_clause : 'when' expression

and again it could be nice and pleasant to have, although not necessary. The 
question comes down to how much does the language benefit by this sugar.

I'd say that in both cases, combining chaining and statements is marginally 
less good than either using standalone chaining or statements without chaining. 
But as I say this, I know as a fact, I fully intend to use `sequence(_:, 
next:).take(while:)` with for0in statements, so I'm starting from a 
hypocritical vantage point.

To summarize, I'm more +0.01 than I am -0.01 on this.

-- E
p.s. Sorry, wux


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 allowed to declare an enum inside the 
> function, compiler can generate  an enum scoped inside the function named the 
> label of the enum:
> 
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> operation: (.Fit | .Fill) = .Fit
> ) -> UIImage {
>   @_exposed num operation {
>   case Fit
>   case Fill
> }
> 
> Then you could declare a var:
> 
> var myOperation: scaleAndCropImage.operation = .Fill
> 
> Then you can call:
> 
> let scaledImage = scaleAndCropImage(image: myImage, toSize: theSize, 
> operation: myOperation)
> 
> @_exposed above would be a compiler private annotation for the auto generated 
> enum that will make if visible outside of the function. This way the impact 
> is minimal and such ad hoc enum would be just the same as any other enum. The 
> only big change in the compiler would be the ability to make some declaration 
> inside functions visible to the outside code.

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 prefixes because the compiler can 
unambiguously match the ad hoc enumeration type to the parameter.
It introduces the possibility (for Matthew) of assigning a value to a variable.
It preserves the notion that an ad-hoc enum makes syntactic and semantic sense 
only with respect to its use in a function/method parameter list.

If an enumeration needs wider semantics, it should be a standalone type, 
whether as a nested or not.

Reiterating the reasons for this pitch:
It streamlines coding, eliminating standalone enumeration types that are used 
only once
It enables you to see all enumeration options at a glance, and can be reflected 
in the QuickHelp documentation
It encourages `switch` coding over `if-then-else` coding so each case is 
labeled and self documenting
It pushes semantics to the call-site in a way that simple Boolean flags cannot: 
`operation: .Fit` means more than `shouldFill: false`.
I'd like to know at this point whether Hooman's approach is even technically 
feasible, although it's horrible timing the Tuesday before WWDC to get core 
team feedback on anything.

-- Erica

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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 prefixes because the compiler can 
>> unambiguously match the ad hoc enumeration type to the parameter.
>> It introduces the possibility (for Matthew) of assigning a value to a 
>> variable.
>> It preserves the notion that an ad-hoc enum makes syntactic and semantic 
>> sense only with respect to its use in a function/method parameter list.
>> 
>> If an enumeration needs wider semantics, it should be a standalone type, 
>> whether as a nested or not.
>> 
>> Reiterating the reasons for this pitch:
>> It streamlines coding, eliminating standalone enumeration types that are 
>> used only once
>> It enables you to see all enumeration options at a glance, and can be 
>> reflected in the QuickHelp documentation
>> It encourages `switch` coding over `if-then-else` coding so each case is 
>> labeled and self documenting
>> It pushes semantics to the call-site in a way that simple Boolean flags 
>> cannot: `operation: .Fit` means more than `shouldFill: false`.
>> I'd like to know at this point whether Hooman's approach is even technically 
>> feasible, although it's horrible timing the Tuesday before WWDC to get core 
>> team feedback on anything.
>> 
> 
> There is currently a draft circulating for the removal of @noreturn. If 
> memory serves, I think there was another annotation recently removed. There 
> was also the recent change of dynamicType into something like type(of:).. all 
> these changes have one thing in common: they are streamlining the language, 
> chasing the magic out and replacing it with the careful application of a few 
> simple principles. @_exposed would IMVHO be a setback: 
> 
> it would introduce a new special annotation
> the annotation would have very little chance of being anything but a one of, 
> used for a single scenario
> 
> Scala went that way years ago, going left right and center, with all sort of 
> great ideas. In the end, for the past few Scala Days Oderski has been going 
> on stage explaining why a language with too many clever tricks is in nobody’s 
> interest.
> 
> if and when they decide to focus on small syntactic sugaring enhancements 
> (akin to javac's Project Coin), then they have an easy way to make it happen 
> without any magic or special rules.

What appeals to me is scoping the enumeration to the function: Semantic sugar 
that creates a global

function.parameterName.enum {case ... }

You had suggested using semantic sugar in a different way, did you not? 

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 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 
>> can't seem to find anything on either one. I'm hoping I'm just missing 
>> something but fearing it never got settled. If not, I'd be happy to jump in 
>> and do the paperwork, but I'd really prefer if the two methods were there 
>> and I was just somehow overlooking them.
> 
> My understanding is that prefix(while:) and drop(while:) were accepted, per 
> the rationale:
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/16119
> 
> -Chris

After that was a lively discussion about rationalizing 
first/last/prefix/suffix/drop/take/etc. methods was there not?

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 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 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 
>>>> can't seem to find anything on either one. I'm hoping I'm just missing 
>>>> something but fearing it never got settled. If not, I'd be happy to jump 
>>>> in and do the paperwork, but I'd really prefer if the two methods were 
>>>> there and I was just somehow overlooking them.
>>> 
>>> My understanding is that prefix(while:) and drop(while:) were accepted, per 
>>> the rationale:
>>> http://thread.gmane.org/gmane.comp.lang.swift.evolution/16119
>>> 
>>> -Chris
>> 
>> After that was a lively discussion about rationalizing 
>> first/last/prefix/suffix/drop/take/etc. methods was there not?
> 
> Hah, entirely possible, who can say?  So much email! :-) :-)
> 
> -Chris

Here's where things seem to have ended up (thank you Guillaume!)

http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/ 
<http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/>

-- E

On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote:
> 
> on Fri May 06 2016, Kevin Ballard  swift.org> wrote:
> 
> > On Fri, May 6, 2016, at 05:31 PM, Kevin Ballard wrote:
> >> On Fri, May 6, 2016, at 05:19 PM, Dave Abrahams via swift-evolution wrote:
> >> > 
> >> > on Wed May 04 2016, Chris Lattner  swift.org> wrote:
> >> > 
> >> > > Proposal link: 
> >> > > https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
> >
> >> > >
> >> > > Hello Swift Community,
> >> > >
> >> > > The review of SE-0045: "Add scan, prefix(while:), drop(while:), and
> >> > > unfold to the stdlib" ran from April 28...May 3, 2016. A subset of the
> >> > > proposal is *accepted, with modifications* for Swift 3.  This proposal
> >> > > included four new additions to the standard library:
> >> > >
> >> > > Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted* 
> >> > > as specified in revision
3 of the proposal.
> >> > 
> >> > I know the review is over and all, but…
> >> > 
> >> > Chris brought to my attention an idea that I liked, and asked me to post
> >> > here about it.  Specifically, the argument label “where:” would probably
> >> > be better than “while:”.  “While” makes it sound to me like it's going
> >> > to take a nullary predicate and be much more active.  But it's hard to
> >> > love
> >> > 
> >> >  s.drop(where: { $0 > 1 })
> >> >  s.drop { $0 > 1 }
> >> > 
> >> > because it makes it sound like a general filtering operation.
> >> > 
> >> > Therefore, I'd much rather see
> >> > 
> >> >s.droppingPrefix(where: {$0 > 1})
> >> 
> >> Using "where:" has a very high potential for confusion, because
> >> "where" makes it sound like it runs the predicate against every
> >> single element, whereas "while" makes it clear that it stops
> >> evaluating elements once the predicate returns false. Or in other
> >> words, `drop(where: predicate)` looks like it should be equivalent
> >> to `filter({ !predicate($0) })`.
> >
> > Oops, I read your message too fast and missed the fact that you
> > changed the function name too in the very last line.
> 
> And made the exact point that you made :-)

Indeed. My apologies, I was trying to get through my email too fast and ended 
up skimming too much.

> > If we switched to `droppingPrefix(where:)` then we'd need to change 
> > `dropFirst(_:)` as well.
> 
> Yes, as I noted in my response to Erica, I would like to see some more design
> coherence in this whole area.  I think
> 
>   xs.dropFirst()  =>  xs.dropping