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

[L Mihalkovic via swift-evolution]

> On Jun 2, 2016, at 5:05 AM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> 
>> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution 
>> > wrote:
>> 
>> 
>> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>>> 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.
>> 
>> This is my objection to this idea. It does not encourage reuse.
> 
> -1For me too. Introducing this quasi-enum would increase cognitive load with 
> little, if any, net benefit. This is the sort of feature that looks great and 
> works wonderfully in example apps, but does not scale well to real systems, 
> where options show up in more methods through time, get passed around to 
> helpers, stored, marshaled into various formats, etc.
> 
> As someone mentioned, this would probably be a good fit If Swift adopts a 
> structural type system (I suppose, I have ever used a language with one to my 
> knowledge, unless duck typing counts)
> 
> As syntactic sugar for a true enum declaration, it would be a “cool” feature, 
> but reuse would still be problematic. 


there is no reuse problem in the interpretation I propose, and the long/short 
form names are completely interchangeable.

> 
>> 
>> I would not be able to assign to a variable:
>> 
>> let selectedOperation = .fill
>> 
>> In order to then do this later in the program:
>> 
>> scaleAndCropImage(image: myImage, toSize: size, operation: selectedOperation)
>> ___
>> 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] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Austin Zheng via swift-evolution]

Excellent.

I put together a PR with a revised proposal containing the core team's 
recommended approach. If anyone is curious they can see it here: 
https://github.com/austinzheng/swift-evolution/blob/ef6adbe0fe09bff6c44c6aa9d73ee407629235ce/proposals/0095-any-as-existential.md
 


Since this is the de-facto second round discussion thread, I'll start with my 
personal opinion (which is *not* reflected in the PR): the '&' separators in 
lieu of commas are a good idea, but I would still prefer the types to be 
wrapped in "Any<>", at least when being used as existentials.

My reasons:

- Jordan Rose brought up a good point in one of the discussion threads today: a 
resilience goal is to allow a library to add an associated type to a protocol 
that had none and not have it break user code. If this is true whatever syntax 
is used for existentials in Swift 3 should be a valid subset of the generalized 
existential syntax used to describe protocol compositions with no associated 
types.

- I would rather have "Any<>" be used consistently across all existential types 
eventually than have it only be used for (e.g.) existential types with `where` 
constraints, or allowing two different representations of the same existential 
type (one with Any, and one without).

- I think any generalized existential syntax without delimiting markers (like 
angle braces) is harder to read than syntax with such markers, so I would 
prefer a design with those markers.

Best,
Austin

> On Jun 1, 2016, at 10:17 PM, Chris Lattner  wrote:
> 
> 
>> On Jun 1, 2016, at 9:53 PM, Austin Zheng  wrote:
>> 
>> This was indeed a very thorough review by the core team. I'll prepare a v2 
>> proposal with this feedback taken into account so we can continue moving 
>> things along.
>> 
>> One quick question - is making whatever syntax is chosen for Swift 3 
>> "forward-compatible" with a future generalized existential feature a concern?
> 
> Yes it is a concern, but we assume that the “X & Y” syntax will always be 
> accepted going forward, as sugar for the more general feature that is yet to 
> be designed.
> 
> -Chris

___
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

[Patrick Smith via swift-evolution]

Yes but, if they weren’t functions now, what would be the best design?

How many Swift developers will be using this functionality? Less than 1%? I 
trust Dave’s judgement because he is in that small group.

> On 2 Jun 2016, at 3:27 PM, Xiaodi Wu  wrote:
> 
> On Thu, Jun 2, 2016 at 12:24 AM, 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.
> 
> I'm actually souring to the idea. It goes in the diametrically opposite 
> direction from dynamicType. There, something was changed from being 
> property-like to being function-like. Here, Dave's proposal would take 
> something that's a function and turn it into a property. Hmm.
>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>> > 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] Ad hoc enums / options

[L Mihalkovic via swift-evolution]

> On Jun 1, 2016, at 11:20 PM, Vladimir.S  wrote:
> 
> OK, I understand most of your points and feel the same regarding the proposed 
> feature... but:
> 
> > .. the compiler does not like when we define the same thing twice, and thse 
> > short form amount to doing what he does not let us do. ..
> > .. if we use an annotation that lets it know that "it is not a mistake..
> > I really dont want to write that enum myself, even though I am using the
> > same abbreviation twice". Otherwise, the compiler would let us know that
> > the second time could be a mistake because there is already something
> > with the same name...
> 
> I just wanted to understand how such enums are different than tuples in 
> meaning of "I don't want to write the struct myself", "Yes, I'm using the 
> same tuple twice", "Compiler will let us know that we used the same tuple 
> again and probably mistake as has already the same". (Not about differences 
> in implementation/representation on compiler level, but on level of one who 
> is writting the code)
> 
> Should we use the same arguments to propose the special annotation when we 
> have the same tuple more than once? No. So I believe there should be no such 
> limitation and special annotation for proposed enums.
> 

I am not sure the parallel can be made. A tuple is characterized by its 
structure, BUT the scope of its use is the VARIABLE where it is being used (I 
am simplifying by only referring to var/let cases). So from the compiler’s 
point of view, there is not a giant Tuples hash table where it can look for a 
given tuple definition based on its intrinsic name. So even if you repeat the 
same tuple definition every other line in your source code, the compiler never 
thinks that they are the same type because they ARE NOT the same. Each one is a 
different variable (the compiler would complain that the variable is defined 
multiple times though). To simplify the model, you could almost think that a 
tuple is a degenerate struct that is internally given the name of its usage 
site. It is not quite true but it is a close-enough approximation of what it 
really is.

The only rational for allowing a 
@I_know_what_I_am_doing_so_please_dont_complain annotation is to allow (and I 
am not saying it should be allowed)


func scaleAndCropLargeImage(
image: UIImage,
toSize size: CGSize,
operation: (.Fit | .Fill) = .Fit
) -> UIImage {
  whoCaresThereIsReallyASingleTypeOfImagesAnyhow()
}

func scaleAndCropSmallImage(
image: UIImage,
toSize size: CGSize,
operation: (.Fit | .Fill) = .Fit
) -> UIImage {
  whoCaresThereIsReallyASingleTypeOfImagesAnyhow()
}


private 
func whoCaresThereIsReallyASingleTypeOfImagesAnyhow(
image: UIImage,
toSize size: CGSize,
operation: (.Fit | .Fill) = .Fit
) -> UIImage {

___
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

[Xiaodi Wu via swift-evolution]

On Thu, Jun 2, 2016 at 12:24 AM, 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.
>

I'm actually souring to the idea. It goes in the diametrically opposite
direction from dynamicType. There, something was changed from being
property-like to being function-like. Here, Dave's proposal would take
something that's a function and turn it into a property. Hmm.

> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution <
> 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]

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 
>> > 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] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch  wrote:
> 
> On imported Objective-C API, the core team did a quick study of the Cocoa 
> APIs and found that most closure/block parameters are escaping in practice.  
> As such, the core team feels that it isn’t overly burdensome to ask that 
> imported Objective-C APIs annotate their semantically noescape block 
> parameters with the clang __attribute__((noescape)) attribute.
> 
> This part is what I proposed last year; still waiting on an update:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md
>  
> 
>  

The problem with that proposal, and the reason it is sitting around in limbo is:

1) it is prescriptive of a process “Audit system C/Objective-C libraries...", 
not a proposal for a set of specific changes.

2) swift-evolution isn’t the right place to propose changes for Foundation or 
other APIs outside of the standard library.  

It has been stuck in a crack for a long time, and has no hope of getting 
unstuck.  I think that at this point the right thing is to close it.  Is that 
ok with you?

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

[Patrick Smith via swift-evolution]

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 
>  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] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

> On Jun 1, 2016, at 9:22 PM, Trent Nadeau  wrote:
> 
> I'd like to write this proposal.

Go for it!  Thanks,

-Chris

> 
> On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution 
> > wrote:
> On Jun 1, 2016, at 9:02 PM, Chris Lattner  > wrote:
> > 2) For noescape, the core team feels that the right solution is for closure 
> > arguments to *default* to noescape, which means that the attribute we 
> > should really need is @escaping.
> 
> To provide some more details, this approach has the following advantages:
> 
> - Most functional algorithms written in pure Swift will benefit because they 
> are naturally noescape.  The core team feels that this will reduce the 
> boilerplate involved with writing these algorithms.
> 
> - The compiler has enough logic in it to provide a great QoI experience when 
> a developer doesn’t think about escaping, and tries to escape a closure - it 
> can provide a fixit that suggests adding @escaping.
> 
> - Recent changes (to disallow escaping closures to close over an inout 
> parameter) are pushing the language to prefer noescape closures.  noescape 
> closures have also always been the preferred default, since they eliminate a 
> class of retain cycle issues.
> 
> - "@autoclosure(escaping)" can be simplified and standardized to 
> "@autoclosure @escaping”
> 
> 
> The two primary concerns with taking this direction were that it is would 
> adversely impact resilience, and that imported Objective-C APIs would be too 
> annoying to work with, because the compiler would have to be conservative and 
> assume they are escaping:
> 
> 
> 
> On resilience, the concern with this approach is that an API may not thinking 
> about whether a closure parameter should be escaping or not, and this 
> behavior makes it possible that someone could write “V1” of an API and not 
> accidentally promise noescape semantics, but then need it in “V2” of the same 
> API.
> 
> John McCall pointed out that resilience in the type system is different than 
> resilience in practice: An API changing to capture a closure and use it long 
> after it was originally passed is likely to break the clients regardless of 
> whether the type system captures this as an issue.  He argues (and the 
> argument is strong IMO) that it is *better* for resilient APIs to default to 
> @noescape, since that forces the author of V2 to think about whether they are 
> breaking their clients.  If they are doing something that is “logically” 
> noescape in their V2, then they can unsafe bitcast away the escaping aspect 
> of the closure.  This is better than changing the client’s view of the API in 
> any case.
> 
> 
> On imported Objective-C API, the core team did a quick study of the Cocoa 
> APIs and found that most closure/block parameters are escaping in practice.  
> As such, the core team feels that it isn’t overly burdensome to ask that 
> imported Objective-C APIs annotate their semantically noescape block 
> parameters with the clang __attribute__((noescape)) attribute.
> 
> 
> I’m happy to write up this proposal, but won’t have cycles to do so for 
> several weeks.  If someone else wants to take it up, that would be great :-)
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> -- 
> Trent Nadeau

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

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Chris Lattner via swift-evolution]

> On Jun 1, 2016, at 9:53 PM, Austin Zheng  wrote:
> 
> This was indeed a very thorough review by the core team. I'll prepare a v2 
> proposal with this feedback taken into account so we can continue moving 
> things along.
> 
> One quick question - is making whatever syntax is chosen for Swift 3 
> "forward-compatible" with a future generalized existential feature a concern?

Yes it is a concern, but we assume that the “X & Y” syntax will always be 
accepted going forward, as sugar for the more general feature that is yet to be 
designed.

-Chris
___
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] Ad hoc enums / options

[Patrick Smith via swift-evolution]

Yes, great point! I think this is a sign it’s better to just have one way with 
an enum, so there’s no deciding on which method to use, or reluctance to switch 
away from ad hoc enums because they felt nicer initially. And enums aren’t that 
much to write.

With the addition of a macro system in future Swift you could probably create 
your own ad hoc enums, and that would be perfect for something like a 
playground.

Patrick

> On 2 Jun 2016, at 2:57 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> Thinking of your example: where might the value for .fit or .fill come from? 
> In most cases it won't be hardcoded in the call, but be either the result of 
> a user setting or an algorithm. Both would need to be able to assign this 
> value.

___
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

[Xiaodi Wu via swift-evolution]

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).
___
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

[Xiaodi Wu via swift-evolution]

On Wed, Jun 1, 2016 at 11:55 PM, Xiaodi Wu  wrote:

> On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution <
> 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
>
>

To summarize the previous discussion:

1. Per Joe Groff, although sizeof() and friends are treated as
terms-of-art, these names were lifted straight from C and do not correspond
to anything named "sizeof" in LLVM.

2. There are issues with using a name such as stride(of:), because
stride(...) already means something else in the stdlib; moreover, size(of:)
isn't the best name for something that doesn't do what its C namesake does;
therefore, larger changes to the naming were suggested.

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.

* * *

If we take inspiration from type(of:), then it's actually sizeofValue(),
etc., that should be renamed size(of:), etc. Also, a fun tidbit is that
what's currently called sizeof(), etc.--the ones that take types rather
than values--are actually not very good candidates for having parameter
labels, because it's OK to write `sizeof(Int)`, but one must currently
write `size(of: Int.self)` when the function has a label.
___
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 
> > 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 
> 
>  


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

[Jacob Bandes-Storch via swift-evolution]

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(){}.

Jacob

On Wed, Jun 1, 2016 at 9:55 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution <
> 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
>
>
> ___
> 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] Ad hoc enums / options

[Thorsten Seitz via swift-evolution]

> Am 31.05.2016 um 21:04 schrieb 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.

That's a big negative point. This means that a small convenience for the 
implementor results in heavy restrictions for the caller who cannot structure 
his algorithm appropriately and will probably have to create (i.e. duplicate) 
the enum anyway.
Thinking of your example: where might the value for .fit or .fill come from? In 
most cases it won't be hardcoded in the call, but be either the result of a 
user setting or an algorithm. Both would need to be able to assign this value.

As a consequence this is just a feature for use in a Playground where it is 
very convenient, but that means it doesn't pull its own weight, because it 
degrades the design outside of Playgrounds.
So a -1 from me.

-Thorsten 

-Thorsten ___
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

[Xiaodi Wu via swift-evolution]

On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution <
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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Austin Zheng via swift-evolution]

This was indeed a very thorough review by the core team. I'll prepare a v2 
proposal with this feedback taken into account so we can continue moving things 
along.

One quick question - is making whatever syntax is chosen for Swift 3 
"forward-compatible" with a future generalized existential feature a concern?

Austin

> On Jun 1, 2016, at 9:47 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
> 
> Hello Swift Community,
> 
> The review of SE-0095: "Replace protocol syntax with Any" ran 
> from May 24…30, 2016. The proposal is returned with revision requested - 
> ideally the revised proposal will be included in Swift 3.
> 
> There was an incredible amount of feedback from the community, continuing 
> even today.  The principle problem identified by community about the proposal 
> is that "Any” implies very strongly an “any of T1 OR T2” relationship 
> (aka disjunction) and not “any type conforming to T1 AND T2” relationship 
> (aka conjunction).  There was also some related discussion as to how the 
> “Any<>” syntax aligns with future generalized existential syntax, much 
> discussion as to whether it should be spelled Any<> or any<>, and some 
> discussion about "angle bracket blindness".
> 
> The core team extensively discussed the feedback and considered many 
> different possible paths forward.  The conclusion of this is that it 
> recommends that SE-0095 be revised into a fairly different proposal, one that 
> introduces a new infix “&” type operator for representing protocol and other 
> type compositions.  Instead of:
> 
>   func f(a : protocol) {}
>   func g(x : T) where T : B {}or   func g B>>(x : T) {}
> 
> You would instead write:
> 
>   func f(a : A & B) {}
>   func g(x : T) {}
> 
> The degenerate case of protocol<> needs an answer, but only for the 
> definition of the Any typealias in the standard library, so it can be left 
> out of the proposal.
> 
> The core team feels that this is an elegant solution for Swift 3 that conveys 
> exactly the right intent.  When generalized existentials are introduced, an 
> elaborated syntax can be introduced to generalize this, e.g. "Any … >” or “(T : A & B where …)” or whatever else makes sense in context of its 
> design.
> 
> The principle concern with this is that having an “&" operator for generic 
> constraints leads the question of whether the language should introduce an 
> "|" operator to represent disjunctions in type constraints (something that 
> the type system cannot and should not support).  This is a topic that the C++ 
> committee grappled with in its discussions of C++ concepts.  That said, the 
> core team feels that “&” directly expresses the relationship that we want, 
> that “|” can be addressed in the “commonly rejected proposals" list, and that 
> other proposals for an infix operator (like +) skirt this issue but are 
> strictly worse at communicating intent in code.
> 
> Many thanks to Adrian Zubarev, Austin Zheng for driving this discussion!
> 
> -Chris Lattner
> Review Manager
> ___
> 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] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md

Hello Swift Community,

The review of SE-0095: "Replace protocol syntax with Any" ran 
from May 24…30, 2016. The proposal is returned with revision requested - 
ideally the revised proposal will be included in Swift 3.

There was an incredible amount of feedback from the community, continuing even 
today.  The principle problem identified by community about the proposal is 
that "Any” implies very strongly an “any of T1 OR T2” relationship (aka 
disjunction) and not “any type conforming to T1 AND T2” relationship (aka 
conjunction).  There was also some related discussion as to how the “Any<>” 
syntax aligns with future generalized existential syntax, much discussion as to 
whether it should be spelled Any<> or any<>, and some discussion about "angle 
bracket blindness".

The core team extensively discussed the feedback and considered many different 
possible paths forward.  The conclusion of this is that it recommends that 
SE-0095 be revised into a fairly different proposal, one that introduces a new 
infix “&” type operator for representing protocol and other type compositions.  
Instead of:

func f(a : protocol) {}
func g(x : T) where T : B {}or   func g>(x : T) {}

You would instead write:

func f(a : A & B) {}
func g(x : T) {}

The degenerate case of protocol<> needs an answer, but only for the definition 
of the Any typealias in the standard library, so it can be left out of the 
proposal.

The core team feels that this is an elegant solution for Swift 3 that conveys 
exactly the right intent.  When generalized existentials are introduced, an 
elaborated syntax can be introduced to generalize this, e.g. "Any” or “(T : A & B where …)” or whatever else makes sense in context of its 
design.

The principle concern with this is that having an “&" operator for generic 
constraints leads the question of whether the language should introduce an "|" 
operator to represent disjunctions in type constraints (something that the type 
system cannot and should not support).  This is a topic that the C++ committee 
grappled with in its discussions of C++ concepts.  That said, the core team 
feels that “&” directly expresses the relationship that we want, that “|” can 
be addressed in the “commonly rejected proposals" list, and that other 
proposals for an infix operator (like +) skirt this issue but are strictly 
worse at communicating intent in code.

Many thanks to Adrian Zubarev, Austin Zheng for driving this discussion!

-Chris Lattner
Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

I don't understand this. All of what you said applies to structs and does not 
apply to tuples. What makes it fundamentally impossible to have a "tuple-like 
enum"?

Félix

> Le 1 juin 2016 à 20:56:27, L. Mihalkovic via swift-evolution 
>  a écrit :
> 
> 
> 
> On Jun 1, 2016, at 11:38 PM, Tony Allevato  > wrote:
> 
>> I find myself agreeing with the idea that ad hoc enums are to enums as 
>> structs are to tuples. Based on that analogy, why should an ad hoc enum 
>> *need* a name (autogenerated or otherwise) any more than a tuple needs a 
>> name?
> 
> A nameless enum is basically a square circle. An enum is a nominal type, 
> which entails that it is characterized by the existence of its name. Two 
> enums with the exact same internal shape are different if their names are 
> different, and two enums with different internal shapes but the same name 
> will trigger a compiler type redefinition error because the name is what 
> identities the enum. 
> 
> 
>> Would those who dislike ad hoc enums argue that this also shouldn't be 
>> allowed:
>> 
>> func foo(bar: (x: Int, y: Int)) {}
>> let t: (x: Int, y: Int) = (x: 5, y: 5)
>> 
>> If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax 
>> might be), that should just *be* the type the same way that `(x: Int, y: 
>> Int)` is a type without a name, and that type can be used in argument lists, 
>> variables, or whatever. There shouldn't be any worry about declarations 
>> across multiple functions colliding or being incompatible any more than we 
>> would worry about two functions declaring arguments of type `(x: Int, y: 
>> Int)` would collide or be incompatible.
>> 
>> One side of ad hoc enums that I'd like to see explored is that, by being 
>> unnamed, they're basically anonymous finite sets and we could apply 
>> well-defined subset relationships to them: in other words, we could consider 
>> allowing this:
>> 
>> func foo(bar: (.fit | .fill)) {
>>   baz(bar: bar)
>> }
>> func baz(bar: (.fit | .fill | .florp) { ... }
>> 
>> In other words, an ad hoc enum T can be used wherever an ad hoc enum U is 
>> expected if T ⊆ U.
>> 
>> 
>> On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution 
>> > wrote:
>> 
>> 
>> > On Jun 1, 2016, at 6:51 PM, Vladimir.S > > > wrote:
>> >
>> > Yes, I also can support the idea of autogenerated type name (like 
>> > Enum_fit_OR_fill) as long as it allows to do all the things we are 
>> > discussing here: declare (.fit|.fill) in function, use .fit on calling 
>> > side, use (.fit|.fill) to declare temporary variable of type compatible 
>> > with such function parameter etc.
>> >
>> 
>> It all works because the compiler is just being a thoughless scribe that 
>> just writes the standard enum we don't bother to write ourselves. Because 
>> the heuristic is simple and straightforward then it is predictible. The enum 
>> can be used with its long name be ause it is a real enum. And writing the 
>> short form of it also works because the compiler knowns uniquely what the 
>> long name is everytime it runs into the short name.
>> 
>> 
>> > But how do you suggest to define a type of such function in `typealias` 
>> > for example? i.e. for func my(option: (.fit|.fill) {..}
>> >
>> > typealias MyFunc = ((.fit|.fill)) -> ()
>> > or as
>> >
>> > typealias MyFunc = (Enum_fit_OR_fill) -> ()
>> >
>> 
>> Ideally there is no difference whatsoever, there is a single enum, it is 
>> produced at the module level, and it has the long form name.
>> 
>> There can be rules that would prevent us from doing that with externally 
>> visible APIs, if the core team fuges that we should take the time to write 
>> our enums manually and cleanly to make them visible to the world, but it is 
>> not a necessary rule.
>> 
>> 
>> >
>> > But I still can't support the idea of limiting the usage of such enums - 
>> > i.e. "To deal with milti site definition, the compiler would simply flag a 
>> > error/warning, or be silent in the presence of a new annotation:". I 
>> > really think we need then introduce the same rule for tuples - so no one 
>> > can use the same tuple declaration in function - they then should declare 
>> > separate struct type or use @something for such functions. Nobody wants 
>> > such rule for tuples.
>> >
>> 
>> Multi site thing is not a limitation... Is is a proposed rule to say that we 
>> are able to be lazy twice without being penalized. Yhe compiler does not 
>> like when we define the same thing twice, and thse short form amount to 
>> doing what he does not let us do. But because this is about concise and 
>> lazy, then the compiler can let us get away with it if we use an annotation 
>> that lets it know that "it is not a mistake.. I really dont want to write 
>> that enum myself, even though I am using the 

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

[Brent Royal-Gordon via swift-evolution]

> Brent, for needing "both Int and Double values" there is a proposal to add 
> tuples instead of the current raw values or allowing assessor properties per 
> case, you should check those out. Perhaps this could also be used to 
> cryptoghaphically sign a raw value but I'm not sure.

I know; I was the one who suggested accessors.

> As for working with enum values by name a few examples have already been 
> posted in today but I've done a lot more research in the subject along the 
> day and found there is a correlation between enums and nominal level values 
> in statistics; we cannot test them for a particular order (this could also be 
> interesting for statistic apps but it's another case) and no math with them 
> is valid. So, e.g., the result of the following operation on the planets enum 
> is nonsense:
> 
> |   let planet = Planet(rawValue: Planet.Mars.rawValue - 
> Planet.Mercury.rawValue)
> 
> The result will be different if the enum values are zero based than if not. 
> Also any change in list order or the base index or add a new element to the 
> middle of the list will break your intended code if you're storing the raw 
> value in a database. And we know these changes happen.

All of this is true. And all of this is an argument that *you're using raw 
values wrong*.

Raw values are a serialization mechanism. You might be serializing merely 
within your process, or you might be writing out to disk, through IPC, or 
across the network, but in all cases you are serializing. You should not be 
doing arithmetic with a serialized representation (unless that arithmetic is a 
part of the serialization process, like an error-correcting code you're 
applying to it). You should not be sorting serialized representations. You 
should be either communicating the raw value or recreating the instance with 
it—nothing else.

In other words, all of these are arguments for putting the order of the Planet 
in a separate property rather than in the `rawValue`. This would free up the 
`rawValue` to be a `String` containing the case name. This is not an argument 
for having both an Int `rawValue` and a String `caseName`; this is an argument 
for having both a String `rawValue` and an Int property.

enum Planet: String {
accessor var order: Int

case mercury { order = 0 }
case venus { order = 1 }
...etc...
}

(Want it to be automatic? One could imagine having a compiler substitution for 
"the index of this case" which could be used as the default value for an 
accessor:

enum Planet: String {
accessor var order: Int = #caseIndex
case mercury, venus, ...
}

Or let you choose a base:

enum Planet: String {
accessor var order: Int = #caseOrder(from: 1)
case mercury, venus, ...
}

Or the `ValuesEnumerable` proposal would give you a convenient, though slightly 
slow, way to do two-way lookup by order:

enum Planet: String, ValuesEnumerable {
var order: Int {
return Planet.allValues.index(of: self)!
}
init(order: Int) {
self = Planet.allValues[order]
}
case mercury, venus, …
}

In short, there are several plausible mechanisms to automate assignment of 
these numbers, should you want to do that.)

> Actually, given this characteristic of nominal types (statistic), we should 
> vow to removing init(rawValue:) completely from the language.

That doesn't follow. The fact that changing something would break code doesn't 
mean that thing should be removed; it means you should be cautious about 
changing that thing. If you rename a case, its name changes; does that mean we 
shouldn't have case name lookups either? Changing any identifier could break 
something; maybe we should abolish all identifiers from Swift?

> The real value you're working with in enums is the enum case name not any 
> associated values. By working with the name you're safe should any associated 
> value change, should their order change, you'll only break your app if the 
> case is removed/renamed (with the raw value, you risk having the wrong 
> treatment being given should another enum case takes the value of a removed 
> one).

RawRepresentable is a serialization mechanism, so *of course* changing the raw 
value can break serialization. This is true whether you're using `Int` raw 
values or `String` raw values; it's just that `Int`s are a little easier to 
change.

If you create an enum with raw values, the raw values are more or less part of 
that enum's contract. You shouldn't expect things to continue to work properly 
if you change them, any more than you should expect them to continue to work 
properly if you delete a case. In fact, the library resilience document 
specifically calls out changing raw values as a 

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Jacob Bandes-Storch via swift-evolution]

On Wed, Jun 1, 2016 at 9:11 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
> > 2) For noescape, the core team feels that the right solution is for
> closure arguments to *default* to noescape, which means that the attribute
> we should really need is @escaping.
>
> To provide some more details, this approach has the following advantages:
>
> - Most functional algorithms written in pure Swift will benefit because
> they are naturally noescape.  The core team feels that this will reduce the
> boilerplate involved with writing these algorithms.
>
> - The compiler has enough logic in it to provide a great QoI experience
> when a developer doesn’t think about escaping, and tries to escape a
> closure - it can provide a fixit that suggests adding @escaping.
>
> - Recent changes (to disallow escaping closures to close over an inout
> parameter) are pushing the language to prefer noescape closures.  noescape
> closures have also always been the preferred default, since they eliminate
> a class of retain cycle issues.
>
> - "@autoclosure(escaping)" can be simplified and standardized to
> "@autoclosure @escaping”
>
>
> The two primary concerns with taking this direction were that it is would
> adversely impact resilience, and that imported Objective-C APIs would be
> too annoying to work with, because the compiler would have to be
> conservative and assume they are escaping:
>
>
>
> On resilience, the concern with this approach is that an API may not
> thinking about whether a closure parameter should be escaping or not, and
> this behavior makes it possible that someone could write “V1” of an API and
> not accidentally promise noescape semantics, but then need it in “V2” of
> the same API.
>
> John McCall pointed out that resilience in the type system is different
> than resilience in practice: An API changing to capture a closure and use
> it long after it was originally passed is likely to break the clients
> regardless of whether the type system captures this as an issue.  He argues
> (and the argument is strong IMO) that it is *better* for resilient APIs to
> default to @noescape, since that forces the author of V2 to think about
> whether they are breaking their clients.  If they are doing something that
> is “logically” noescape in their V2, then they can unsafe bitcast away the
> escaping aspect of the closure.  This is better than changing the client’s
> view of the API in any case.
>
>
> On imported Objective-C API, the core team did a quick study of the Cocoa
> APIs and found that most closure/block parameters are escaping in
> practice.  As such, the core team feels that it isn’t overly burdensome to
> ask that imported Objective-C APIs annotate their semantically noescape
> block parameters with the clang __attribute__((noescape)) attribute.
>

This part is what I proposed last year; still waiting on an update:

https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md


>
>
> I’m happy to write up this proposal, but won’t have cycles to do so for
> several weeks.  If someone else wants to take it up, that would be great :-)
>
> -Chris
> ___
> 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] [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] #warning

[Ben Langmuir via swift-evolution]

> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
>> 
>> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> On May 29, 2016, at 12:58 PM, Erica Sadun >> > wrote:
>>> 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. 
>> 
>> Right: it isn’t a bad thing at all, but it is certainly the case that people 
>> often request adding features to Swift that they see in other languages.  
>> Our task is to look at whether the problem is real and significant enough to 
>> solve, and if the proposal solves it in the best possible way consistent 
>> with the rest of Swift.
>> 
>> An similar example is "#pragma mark”.  Instead of introducing language 
>> support for it, we codified a comment marker (since it is semantically 
>> identical to a comment).  Xcode picks it up and does the right thing, and I 
>> think it has worked out well.
>> 
>> As to #warning, Swift’s use of warnings are significant different than the 
>> use in C.  In C compilers, many of the warnings produced *should* be errors, 
>> but can’t be because that effects language conformance and could break a 
>> large body of code.  Swift doesn’t have this problem, so it treats warnings 
>> as “things that should be addressed before you commit your patch, but 
>> shouldn’t block a build if (e.g.) you’re in the middle of a big 
>> refactoring”.  For example, an unused variables is a warning in Swift.
> 
> This sounds exactly like what I’d use #warning for. “I’m in the middle of a 
> big refactoring, and I haven’t gotten to this part yet; let me put a warning 
> in so I can test the other part but won’t forget to come back to it.” It 
> might also make sense for doing a series of commits on a branch when you need 
> to fix something before merging back to trunk.

+1 to the proposal, and Jordan has captured my feelings very well here so I 
won’t repeat him.

> 
> I think it is important for such diagnostics to show up in compilation, not 
> just in IDEs, especially with people using the Swift Package Manager. We 
> could have the compiler parse every comment looking for TODOs and FIXMEs by 
> default, and emit those as warnings, but I’d want to find out if that creates 
> a noticeable difference in parsing time. (It also seems odd that comments 
> would be controlled by #if, but maybe that’s silly.)
> 
> +1 to the proposal from me, though I agree with Brent that the parentheses 
> don’t feel right. This is closer to #if and #setline than #available and 
> #selector.
> 
> Jordan
> 
> P.S. #error is also interesting, but more for “things that should never 
> happen” (like the else branch of a platform check), which makes it a bit less 
> important. #info/#message can be useful but I’d like to see a concrete case 
> before designing it.
> 
> 
> ___
> 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] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Austin Zheng via swift-evolution]

+1. It would be great to get this reviewed and in for Swift 3.

Austin

> On Jun 1, 2016, at 9:22 PM, Trent Nadeau via swift-evolution 
>  wrote:
> 
> I'd like to write this proposal.
> 
> On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution 
> > wrote:
> On Jun 1, 2016, at 9:02 PM, Chris Lattner  > wrote:
> > 2) For noescape, the core team feels that the right solution is for closure 
> > arguments to *default* to noescape, which means that the attribute we 
> > should really need is @escaping.
> 
> To provide some more details, this approach has the following advantages:
> 
> - Most functional algorithms written in pure Swift will benefit because they 
> are naturally noescape.  The core team feels that this will reduce the 
> boilerplate involved with writing these algorithms.
> 
> - The compiler has enough logic in it to provide a great QoI experience when 
> a developer doesn’t think about escaping, and tries to escape a closure - it 
> can provide a fixit that suggests adding @escaping.
> 
> - Recent changes (to disallow escaping closures to close over an inout 
> parameter) are pushing the language to prefer noescape closures.  noescape 
> closures have also always been the preferred default, since they eliminate a 
> class of retain cycle issues.
> 
> - "@autoclosure(escaping)" can be simplified and standardized to 
> "@autoclosure @escaping”
> 
> 
> The two primary concerns with taking this direction were that it is would 
> adversely impact resilience, and that imported Objective-C APIs would be too 
> annoying to work with, because the compiler would have to be conservative and 
> assume they are escaping:
> 
> 
> 
> On resilience, the concern with this approach is that an API may not thinking 
> about whether a closure parameter should be escaping or not, and this 
> behavior makes it possible that someone could write “V1” of an API and not 
> accidentally promise noescape semantics, but then need it in “V2” of the same 
> API.
> 
> John McCall pointed out that resilience in the type system is different than 
> resilience in practice: An API changing to capture a closure and use it long 
> after it was originally passed is likely to break the clients regardless of 
> whether the type system captures this as an issue.  He argues (and the 
> argument is strong IMO) that it is *better* for resilient APIs to default to 
> @noescape, since that forces the author of V2 to think about whether they are 
> breaking their clients.  If they are doing something that is “logically” 
> noescape in their V2, then they can unsafe bitcast away the escaping aspect 
> of the closure.  This is better than changing the client’s view of the API in 
> any case.
> 
> 
> On imported Objective-C API, the core team did a quick study of the Cocoa 
> APIs and found that most closure/block parameters are escaping in practice.  
> As such, the core team feels that it isn’t overly burdensome to ask that 
> imported Objective-C APIs annotate their semantically noescape block 
> parameters with the clang __attribute__((noescape)) attribute.
> 
> 
> I’m happy to write up this proposal, but won’t have cycles to do so for 
> several weeks.  If someone else wants to take it up, that would be great :-)
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> -- 
> Trent Nadeau
> ___
> 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] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Trent Nadeau via swift-evolution]

I'd like to write this proposal.

On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
> > 2) For noescape, the core team feels that the right solution is for
> closure arguments to *default* to noescape, which means that the attribute
> we should really need is @escaping.
>
> To provide some more details, this approach has the following advantages:
>
> - Most functional algorithms written in pure Swift will benefit because
> they are naturally noescape.  The core team feels that this will reduce the
> boilerplate involved with writing these algorithms.
>
> - The compiler has enough logic in it to provide a great QoI experience
> when a developer doesn’t think about escaping, and tries to escape a
> closure - it can provide a fixit that suggests adding @escaping.
>
> - Recent changes (to disallow escaping closures to close over an inout
> parameter) are pushing the language to prefer noescape closures.  noescape
> closures have also always been the preferred default, since they eliminate
> a class of retain cycle issues.
>
> - "@autoclosure(escaping)" can be simplified and standardized to
> "@autoclosure @escaping”
>
>
> The two primary concerns with taking this direction were that it is would
> adversely impact resilience, and that imported Objective-C APIs would be
> too annoying to work with, because the compiler would have to be
> conservative and assume they are escaping:
>
>
>
> On resilience, the concern with this approach is that an API may not
> thinking about whether a closure parameter should be escaping or not, and
> this behavior makes it possible that someone could write “V1” of an API and
> not accidentally promise noescape semantics, but then need it in “V2” of
> the same API.
>
> John McCall pointed out that resilience in the type system is different
> than resilience in practice: An API changing to capture a closure and use
> it long after it was originally passed is likely to break the clients
> regardless of whether the type system captures this as an issue.  He argues
> (and the argument is strong IMO) that it is *better* for resilient APIs to
> default to @noescape, since that forces the author of V2 to think about
> whether they are breaking their clients.  If they are doing something that
> is “logically” noescape in their V2, then they can unsafe bitcast away the
> escaping aspect of the closure.  This is better than changing the client’s
> view of the API in any case.
>
>
> On imported Objective-C API, the core team did a quick study of the Cocoa
> APIs and found that most closure/block parameters are escaping in
> practice.  As such, the core team feels that it isn’t overly burdensome to
> ask that imported Objective-C APIs annotate their semantically noescape
> block parameters with the clang __attribute__((noescape)) attribute.
>
>
> I’m happy to write up this proposal, but won’t have cycles to do so for
> several weeks.  If someone else wants to take it up, that would be great :-)
>
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



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

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

On Jun 1, 2016, at 9:02 PM, Chris Lattner  wrote:
> 2) For noescape, the core team feels that the right solution is for closure 
> arguments to *default* to noescape, which means that the attribute we should 
> really need is @escaping.

To provide some more details, this approach has the following advantages:

- Most functional algorithms written in pure Swift will benefit because they 
are naturally noescape.  The core team feels that this will reduce the 
boilerplate involved with writing these algorithms.

- The compiler has enough logic in it to provide a great QoI experience when a 
developer doesn’t think about escaping, and tries to escape a closure - it can 
provide a fixit that suggests adding @escaping.

- Recent changes (to disallow escaping closures to close over an inout 
parameter) are pushing the language to prefer noescape closures.  noescape 
closures have also always been the preferred default, since they eliminate a 
class of retain cycle issues.

- "@autoclosure(escaping)" can be simplified and standardized to "@autoclosure 
@escaping”


The two primary concerns with taking this direction were that it is would 
adversely impact resilience, and that imported Objective-C APIs would be too 
annoying to work with, because the compiler would have to be conservative and 
assume they are escaping:



On resilience, the concern with this approach is that an API may not thinking 
about whether a closure parameter should be escaping or not, and this behavior 
makes it possible that someone could write “V1” of an API and not accidentally 
promise noescape semantics, but then need it in “V2” of the same API.  

John McCall pointed out that resilience in the type system is different than 
resilience in practice: An API changing to capture a closure and use it long 
after it was originally passed is likely to break the clients regardless of 
whether the type system captures this as an issue.  He argues (and the argument 
is strong IMO) that it is *better* for resilient APIs to default to @noescape, 
since that forces the author of V2 to think about whether they are breaking 
their clients.  If they are doing something that is “logically” noescape in 
their V2, then they can unsafe bitcast away the escaping aspect of the closure. 
 This is better than changing the client’s view of the API in any case.


On imported Objective-C API, the core team did a quick study of the Cocoa APIs 
and found that most closure/block parameters are escaping in practice.  As 
such, the core team feels that it isn’t overly burdensome to ask that imported 
Objective-C APIs annotate their semantically noescape block parameters with the 
clang __attribute__((noescape)) attribute.


I’m happy to write up this proposal, but won’t have cycles to do so for several 
weeks.  If someone else wants to take it up, that would be great :-)

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

[swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0097-negative-attributes.md

Hello Swift Community,

The review of SE-0097: "Normalizing naming for "negative" attributes" ran from 
May 24…30, 2016. The proposal is *rejected* for Swift 3.  

The core team agrees with the principle guiding the proposal (that negative 
attributes should start with “non” instead of “no”) and highly values 
standardized naming for attributes.  The community was lukewarm about 
“nonescaping” but pretty significantly opposed to “nonreturning”.

The core team discussed this at length and agreed that the problem identified 
by the proposal needs to be solved, but prefers to explore directions that 
would define away these attributes completely:


1) For noreturn, the core team prefers to explore a solution where a function 
can be declared as returning an non-constructable “bottom” type (e.g. an enum 
with zero cases).  This would lead to something like:

func abort() -> NoReturn { … }

This will require some new support in the compiler, but should flow better 
through the type system than @noreturn in function composition and other 
applications.  Joe Groff offered to write a proposal for this.


2) For noescape, the core team feels that the right solution is for closure 
arguments to *default* to noescape, which means that the attribute we should 
really need is @escaping.


Many thanks to Erica Sadun for driving this discussion and writing the 
proposal.  This was an important topic for the community and core team to 
re-evalute, and it was very effective at forcing progress.

-Chris Lattner
Review Manager

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

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

[L. Mihalkovic via swift-evolution]

> On Jun 1, 2016, at 11:38 PM, Tony Allevato  wrote:
> 
> I find myself agreeing with the idea that ad hoc enums are to enums as 
> structs are to tuples. Based on that analogy, why should an ad hoc enum 
> *need* a name (autogenerated or otherwise) any more than a tuple needs a name?

A nameless enum is basically a square circle. An enum is a nominal type, which 
entails that it is characterized by the existence of its name. Two enums with 
the exact same internal shape are different if their names are different, and 
two enums with different internal shapes but the same name will trigger a 
compiler type redefinition error because the name is what identities the enum. 


> Would those who dislike ad hoc enums argue that this also shouldn't be 
> allowed:
> 
> func foo(bar: (x: Int, y: Int)) {}
> let t: (x: Int, y: Int) = (x: 5, y: 5)
> 
> If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax might 
> be), that should just *be* the type the same way that `(x: Int, y: Int)` is a 
> type without a name, and that type can be used in argument lists, variables, 
> or whatever. There shouldn't be any worry about declarations across multiple 
> functions colliding or being incompatible any more than we would worry about 
> two functions declaring arguments of type `(x: Int, y: Int)` would collide or 
> be incompatible.
> 
> One side of ad hoc enums that I'd like to see explored is that, by being 
> unnamed, they're basically anonymous finite sets and we could apply 
> well-defined subset relationships to them: in other words, we could consider 
> allowing this:
> 
> func foo(bar: (.fit | .fill)) {
>   baz(bar: bar)
> }
> func baz(bar: (.fit | .fill | .florp) { ... }
> 
> In other words, an ad hoc enum T can be used wherever an ad hoc enum U is 
> expected if T ⊆ U.
> 
> 
>> On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution 
>>  wrote:
>> 
>> 
>> > On Jun 1, 2016, at 6:51 PM, Vladimir.S  wrote:
>> >
>> > Yes, I also can support the idea of autogenerated type name (like 
>> > Enum_fit_OR_fill) as long as it allows to do all the things we are 
>> > discussing here: declare (.fit|.fill) in function, use .fit on calling 
>> > side, use (.fit|.fill) to declare temporary variable of type compatible 
>> > with such function parameter etc.
>> >
>> 
>> It all works because the compiler is just being a thoughless scribe that 
>> just writes the standard enum we don't bother to write ourselves. Because 
>> the heuristic is simple and straightforward then it is predictible. The enum 
>> can be used with its long name be ause it is a real enum. And writing the 
>> short form of it also works because the compiler knowns uniquely what the 
>> long name is everytime it runs into the short name.
>> 
>> 
>> > But how do you suggest to define a type of such function in `typealias` 
>> > for example? i.e. for func my(option: (.fit|.fill) {..}
>> >
>> > typealias MyFunc = ((.fit|.fill)) -> ()
>> > or as
>> >
>> > typealias MyFunc = (Enum_fit_OR_fill) -> ()
>> >
>> 
>> Ideally there is no difference whatsoever, there is a single enum, it is 
>> produced at the module level, and it has the long form name.
>> 
>> There can be rules that would prevent us from doing that with externally 
>> visible APIs, if the core team fuges that we should take the time to write 
>> our enums manually and cleanly to make them visible to the world, but it is 
>> not a necessary rule.
>> 
>> 
>> >
>> > But I still can't support the idea of limiting the usage of such enums - 
>> > i.e. "To deal with milti site definition, the compiler would simply flag a 
>> > error/warning, or be silent in the presence of a new annotation:". I 
>> > really think we need then introduce the same rule for tuples - so no one 
>> > can use the same tuple declaration in function - they then should declare 
>> > separate struct type or use @something for such functions. Nobody wants 
>> > such rule for tuples.
>> >
>> 
>> Multi site thing is not a limitation... Is is a proposed rule to say that we 
>> are able to be lazy twice without being penalized. Yhe compiler does not 
>> like when we define the same thing twice, and thse short form amount to 
>> doing what he does not let us do. But because this is about concise and 
>> lazy, then the compiler can let us get away with it if we use an annotation 
>> that lets it know that "it is not a mistake.. I really dont want to write 
>> that enum myself, even though I am using the same abbreviation twice". 
>> Otherwise, the compiler would let us know that the second time could be a 
>> mistake because there is already something with the same name...
>> 
>> But again this is a separate idea from the core notion of a syntax sugaring 
>> for writing real enums the lazy (clever) way
>> 
>> >> On 01.06.2016 19:04, L. Mihalkovic wrote:
>> >> The only problem with this proposal is to consider them ad-hoc enums... 
>> 

[swift-evolution] [Accepted with Revision] SE-0098: Converting dynamicType from a property to an operator

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md

Hello Swift Community,

The review of SE-0098: "Converting dynamicType from a property to an operator" 
ran from May 24…30, 2016. The proposal is *accepted* for Swift 3.  

The feedback on the community on the proposal was very light, but there were 
significant concerns about its name.  After discussion, the core team agrees 
that “x.dynamicType" should use the syntax of a global function as stated by 
the proposal, but would prefer for that function to be spelled "type(of: x)” to 
follow the naming guidelines.  The rationale is:

- The function is side-effect free, so it should have a noun that describes 
what is returned.
- “type” is ambiguously a noun, verb, and perhaps other things, so the “of” 
preposition is necessary for clarity.

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.

Many thanks to Erica Sadun for driving this discussion and writing a great 
proposal!

-Chris Lattner
Review Manager

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

[swift-evolution] [Rejected] SE-0098: Lowercase didSet and willSet for more consistent keyword casing

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md

Hello Swift Community,

The review of SE-0098: "Lowercase didSet and willSet for more consistent 
keyword casing" ran from May 24…30, 2016. The proposal is *rejected* for Swift 
3.  

The feedback on the proposal from both the core team and the community was that 
these should remain camel cased, particularly given that they may become 
user-definable aspect names in a future release.

Many thanks to Erica Sadun for driving this discussion and writing the 
proposal.  This was an important topic for the community and core team to 
re-evalute.

-Chris Lattner
Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

What if (.Fit | .Fill) was just a shorthand for enums that you could use 
anywhere, like a tuple type?

let foo: (.Fit | .Fill) = .Fit
let bar: (.Fit | .Fill) = .Fill
let frob = cond ? foo : bar // foo and bar have the same type

You could typealias it too.

Félix

> Le 1 juin 2016 à 20:05:06, Christopher Kornher via swift-evolution 
>  a écrit :
> 
> 
>> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution 
>> > wrote:
>> 
>> 
>> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>>> 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.
>> 
>> This is my objection to this idea. It does not encourage reuse.
> 
> -1For me too. Introducing this quasi-enum would increase cognitive load with 
> little, if any, net benefit. This is the sort of feature that looks great and 
> works wonderfully in example apps, but does not scale well to real systems, 
> where options show up in more methods through time, get passed around to 
> helpers, stored, marshaled into various formats, etc.
> 
> As someone mentioned, this would probably be a good fit If Swift adopts a 
> structural type system (I suppose, I have ever used a language with one to my 
> knowledge, unless duck typing counts)
> 
> As syntactic sugar for a true enum declaration, it would be a “cool” feature, 
> but reuse would still be problematic. 
> 
>> 
>> I would not be able to assign to a variable:
>> 
>> let selectedOperation = .fill
>> 
>> In order to then do this later in the program:
>> 
>> scaleAndCropImage(image: myImage, toSize: size, operation: selectedOperation)
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Jordan Rose via swift-evolution]

> On Jun 1, 2016, at 14:18, Austin Zheng  wrote:
> 
> I'd also like to express my support for the proposal to delineate generic and 
> existential syntax: all existentials must be written with Any<...>; generic 
> type constraints cannot use it. I hope this will make it clear to people 
> learning and using the language that, despite their superficial similarities, 
> they are actually two different concepts.

This is definitely getting off-topic for this particular review, but I’ve come 
to agree with you. I can only speak for myself, but back when we were 
implementing protocols in Swift it felt great to eliminate the wedge between 
’NSTableView *’ and ‘id ’. But then we started using 
protocols for many more things in Swift, and it turns out that the simple use 
case of “I have a protocol-typed property” isn’t really the one worth 
optimizing for anymore. When they’re arguments, you more often than not might 
want to use them generically, and you should at least be thinking about that 
when you define a function.

Where we are today, the protocol-typed value is the obvious choice, and then 
you move to generics when the compiler tells you no. Having the choice be 
between these two:

func foo(value: T)
func foo(value: Any)

makes it a little more likely that someone will stop and think about picking 
the first.

(Then again, Joe’s talked about making the second use the ABI of the first 
anyway as an optimization, though that can backfire if the value is copied 
around a lot.)

I suppose a middle ground would restrict the protocol-name-only syntax to 
class-bound protocols, which are the most likely to be used in properties 
(“delegate-like protocols”). I’d be hesitant to restrict to “class-bound 
protocols without associated types” because we want adding an associated type 
to be a non-breaking change 
 (if we can 
figure out how to do it).

Jordan

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

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

[Christopher Kornher via swift-evolution]

> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution 
> > wrote:
> 
>> 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.
> 
> This is my objection to this idea. It does not encourage reuse.

-1For me too. Introducing this quasi-enum would increase cognitive load with 
little, if any, net benefit. This is the sort of feature that looks great and 
works wonderfully in example apps, but does not scale well to real systems, 
where options show up in more methods through time, get passed around to 
helpers, stored, marshaled into various formats, etc.

As someone mentioned, this would probably be a good fit If Swift adopts a 
structural type system (I suppose, I have ever used a language with one to my 
knowledge, unless duck typing counts)

As syntactic sugar for a true enum declaration, it would be a “cool” feature, 
but reuse would still be problematic. 

> 
> I would not be able to assign to a variable:
> 
> let selectedOperation = .fill
> 
> In order to then do this later in the program:
> 
> scaleAndCropImage(image: myImage, toSize: size, operation: selectedOperation)
> ___
> 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] Ad hoc enums / options

[Patrick Smith via swift-evolution]

> On 2 Jun 2016, at 7:38 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Would those who dislike ad hoc enums argue that this also shouldn't be 
> allowed:
> 
> func foo(bar: (x: Int, y: Int)) {}
> let t: (x: Int, y: Int) = (x: 5, y: 5)


I would argue that example contains a code smell, so while it compiles, I 
personally wouldn’t allow it.

But it depends on the semantics of course. And there should always be a pull as 
a writer to turn a tuple into a struct.

My issue with ad hoc enums is that their context is to the function. They 
should instead be an independent concept, and that’s why an enum type is so 
useful, because it even names the concept.

Tuples from what I see are primarily function based, so it’s really overcoming 
the fact that while you can pass multiple parameters to a function, you only 
get one back, so a tuple is the best way to solve that. (And of course they 
work with callbacks too, an asynchronous version of returning from a function, 
or functions that alter and return their input).

As soon as you start passing a tuple around, it has meaning, and our job as 
programmers is to assign names and flesh out meaning.

And if you are translating from (.fit | .fill) to (.fit | .fill | .florp), 
that’s a lot of boilerplate code, which goes against the whole reason for 
having ad hoc enums (or just imagine going the opposite way, there’s a lot more 
to be discussed on how ad hoc enums work I think). It would be better in mind 
to break them up into thoughtful pieces, such as two enums or an enum and an 
extra bool. This isn’t always easy of course. Them’s the breaks!

Patrick

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

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

[Ricardo Parada via swift-evolution]

> On Jun 1, 2016, at 5:38 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> we could consider allowing this:
> 
> func foo(bar: (.fit | .fill)) {
>   baz(bar: bar)
> }
> func baz(bar: (.fit | .fill | .florp) { ... }
> 
> In other words, an ad hoc enum T can be used wherever an ad hoc enum U is 
> expected if T ⊆ U.

If that were the case then it may not be that bad. 

I would not use it that much as I favor reusability and would normally create 
an enum for it for maximum flexibility and reuse. 

I like tuples but I don't use them much and I have survived in other languages 
without them. :-)

This is all sugar to me. I may use it when putting code together quickly but 
not in formal APIs. 

I really look forward to seeing other features in Swift that will elevate the 
language and run-time to levels where Objective-C still has an edge over Swift. 
In particular reflection, property behaviors, KVC, etc.   
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 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.

This is my objection to this idea. It does not encourage reuse. 

I would not be able to assign to a variable:

let selectedOperation = .fill

In order to then do this later in the program:

scaleAndCropImage(image: myImage, toSize: size, operation: selectedOperation)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 1, 2016, at 5:02 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> > in other words, we could consider allowing this:
> >func foo(bar: (.fit | .fill)) {
> >  baz(bar: bar)
> >}
> >func baz(bar: (.fit | .fill | .florp) { ... }
> >
> > In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
> > expected if T ⊆ U.
> 
> Can't agree with this. Just because the same analogue with tuples : 
> differently defined tuples are different types. Tuples with different order 
> of types in declaration - are different types. So I expect here instance of 
> (.fit | .fill) `bar` is not of the same type as (.fit | .fill | .florp)

They are not the same type but there is a structural subtype relationship 
between them.  All values of type (.fit | .fill) are also values of type (.fit 
| .fill | .florp).

> 
> But +1 to be able to 'convert' instance of (.fit | .fill) to instance of 
> (.fit | .fill | .florp). For example(if we'll have init(caseName) and 
> .caseName for enums):
> 
> func foo(bar: (.fit | .fill)) {
>let bazbar = (.fit | .fill | .florp).init(caseName: bar.caseName)
>baz(bar: bazbar)
> }
> func baz(bar: (.fit | .fill | .florp) { ... }
> 
> 
> 
>> On 02.06.2016 0:38, Tony Allevato wrote:
>> I find myself agreeing with the idea that ad hoc enums are to enums as
>> structs are to tuples. Based on that analogy, why should an ad hoc enum
>> *need* a name (autogenerated or otherwise) any more than a tuple needs a
>> name? Would those who dislike ad hoc enums argue that this also shouldn't
>> be allowed:
>> 
>>func foo(bar: (x: Int, y: Int)) {}
>>let t: (x: Int, y: Int) = (x: 5, y: 5)
>> 
>> If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax
>> might be), that should just *be* the type the same way that `(x: Int, y:
>> Int)` is a type without a name, and that type can be used in argument
>> lists, variables, or whatever. There shouldn't be any worry about
>> declarations across multiple functions colliding or being incompatible any
>> more than we would worry about two functions declaring arguments of type
>> `(x: Int, y: Int)` would collide or be incompatible.
>> 
>> One side of ad hoc enums that I'd like to see explored is that, by being
>> unnamed, they're basically anonymous finite sets and we could apply
>> well-defined subset relationships to them: in other words, we could
>> consider allowing this:
>> 
>>func foo(bar: (.fit | .fill)) {
>>  baz(bar: bar)
>>}
>>func baz(bar: (.fit | .fill | .florp) { ... }
>> 
>> In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
>> expected if T ⊆ U.
>> 
>> 
>> On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution
>> > wrote:
>> 
>> 
>> 
>>> On Jun 1, 2016, at 6:51 PM, Vladimir.S >> wrote:
>>>
>>> Yes, I also can support the idea of autogenerated type name (like
>>Enum_fit_OR_fill) as long as it allows to do all the things we are
>>discussing here: declare (.fit|.fill) in function, use .fit on calling
>>side, use (.fit|.fill) to declare temporary variable of type compatible
>>with such function parameter etc.
>>>
>> 
>>It all works because the compiler is just being a thoughless scribe
>>that just writes the standard enum we don't bother to write ourselves.
>>Because the heuristic is simple and straightforward then it is
>>predictible. The enum can be used with its long name be ause it is a
>>real enum. And writing the short form of it also works because the
>>compiler knowns uniquely what the long name is everytime it runs into
>>the short name.
>> 
>> 
>>> But how do you suggest to define a type of such function in
>>`typealias` for example? i.e. for func my(option: (.fit|.fill) {..}
>>>
>>> typealias MyFunc = ((.fit|.fill)) -> ()
>>> or as
>>>
>>> typealias MyFunc = (Enum_fit_OR_fill) -> ()
>>>
>> 
>>Ideally there is no difference whatsoever, there is a single enum, it
>>is produced at the module level, and it has the long form name.
>> 
>>There can be rules that would prevent us from doing that with
>>externally visible APIs, if the core team fuges that we should take the
>>time to write our enums manually and cleanly to make them visible to
>>the world, but it is not a necessary rule.
>> 
>> 
>>>
>>> But I still can't support the idea of limiting the usage of such
>>enums - i.e. "To deal with milti site definition, the compiler would
>>simply flag a error/warning, or be silent in the presence of a new
>>annotation:". I really think we need then introduce the same rule for
>>tuples - so no one can use the same tuple declaration in function -
>>they then should declare separate struct type or use @something for
>>such functions. Nobody wants such 

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 1, 2016, at 4:38 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> I find myself agreeing with the idea that ad hoc enums are to enums as 
> structs are to tuples. Based on that analogy, why should an ad hoc enum 
> *need* a name (autogenerated or otherwise) any more than a tuple needs a 
> name? Would those who dislike ad hoc enums argue that this also shouldn't be 
> allowed:
> 
> func foo(bar: (x: Int, y: Int)) {}
> let t: (x: Int, y: Int) = (x: 5, y: 5)
> 
> If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax might 
> be), that should just *be* the type the same way that `(x: Int, y: Int)` is a 
> type without a name, and that type can be used in argument lists, variables, 
> or whatever. There shouldn't be any worry about declarations across multiple 
> functions colliding or being incompatible any more than we would worry about 
> two functions declaring arguments of type `(x: Int, y: Int)` would collide or 
> be incompatible.
> 
> One side of ad hoc enums that I'd like to see explored is that, by being 
> unnamed, they're basically anonymous finite sets and we could apply 
> well-defined subset relationships to them: in other words, we could consider 
> allowing this:
> 
> func foo(bar: (.fit | .fill)) {
>   baz(bar: bar)
> }
> func baz(bar: (.fit | .fill | .florp) { ... }
> 
> In other words, an ad hoc enum T can be used wherever an ad hoc enum U is 
> expected if T ⊆ U.

When I said I am very opposed to this feature *unless* these ad-hoc enums have 
structural subtyping this is what I was talking about.  IMO this is absolutely 
essential if we introduce ad-hoc enums (as well as the ability to use the types 
for variables, not just parameters).

> 
> 
>> On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution 
>>  wrote:
>> 
>> 
>> > On Jun 1, 2016, at 6:51 PM, Vladimir.S  wrote:
>> >
>> > Yes, I also can support the idea of autogenerated type name (like 
>> > Enum_fit_OR_fill) as long as it allows to do all the things we are 
>> > discussing here: declare (.fit|.fill) in function, use .fit on calling 
>> > side, use (.fit|.fill) to declare temporary variable of type compatible 
>> > with such function parameter etc.
>> >
>> 
>> It all works because the compiler is just being a thoughless scribe that 
>> just writes the standard enum we don't bother to write ourselves. Because 
>> the heuristic is simple and straightforward then it is predictible. The enum 
>> can be used with its long name be ause it is a real enum. And writing the 
>> short form of it also works because the compiler knowns uniquely what the 
>> long name is everytime it runs into the short name.
>> 
>> 
>> > But how do you suggest to define a type of such function in `typealias` 
>> > for example? i.e. for func my(option: (.fit|.fill) {..}
>> >
>> > typealias MyFunc = ((.fit|.fill)) -> ()
>> > or as
>> >
>> > typealias MyFunc = (Enum_fit_OR_fill) -> ()
>> >
>> 
>> Ideally there is no difference whatsoever, there is a single enum, it is 
>> produced at the module level, and it has the long form name.
>> 
>> There can be rules that would prevent us from doing that with externally 
>> visible APIs, if the core team fuges that we should take the time to write 
>> our enums manually and cleanly to make them visible to the world, but it is 
>> not a necessary rule.
>> 
>> 
>> >
>> > But I still can't support the idea of limiting the usage of such enums - 
>> > i.e. "To deal with milti site definition, the compiler would simply flag a 
>> > error/warning, or be silent in the presence of a new annotation:". I 
>> > really think we need then introduce the same rule for tuples - so no one 
>> > can use the same tuple declaration in function - they then should declare 
>> > separate struct type or use @something for such functions. Nobody wants 
>> > such rule for tuples.
>> >
>> 
>> Multi site thing is not a limitation... Is is a proposed rule to say that we 
>> are able to be lazy twice without being penalized. Yhe compiler does not 
>> like when we define the same thing twice, and thse short form amount to 
>> doing what he does not let us do. But because this is about concise and 
>> lazy, then the compiler can let us get away with it if we use an annotation 
>> that lets it know that "it is not a mistake.. I really dont want to write 
>> that enum myself, even though I am using the same abbreviation twice". 
>> Otherwise, the compiler would let us know that the second time could be a 
>> mistake because there is already something with the same name...
>> 
>> But again this is a separate idea from the core notion of a syntax sugaring 
>> for writing real enums the lazy (clever) way
>> 
>> >> On 01.06.2016 19:04, L. Mihalkovic wrote:
>> >> The only problem with this proposal is to consider them ad-hoc enums... 
>> >> If we view them as having nothing ad-hoc about them and the 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 1, 2016, at 4:18 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> After thinking about this topic for the past few days, I'd like to throw in 
> my support for "Any<>" as well. It's one magic construct to learn, looks like 
> a type, has the visual delineation, and shares continuity with both 
> protocol<> and Any today.
> 
> I'd also like to express my support for the proposal to delineate generic and 
> existential syntax: all existentials must be written with Any<...>; generic 
> type constraints cannot use it. I hope this will make it clear to people 
> learning and using the language that, despite their superficial similarities, 
> they are actually two different concepts.

I'm neutral on the syntax.  But I strongly believe removing the ability to use 
protocol / Any in generic constraints *must* be accompanied by the introduction 
of a new (hopefully more robust) mechanism for factoring out common generic 
constraints.

> 
> Austin
> 
> 
>> On Wed, Jun 1, 2016 at 1:59 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> > [Proposal: 
>> > https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>> >  ]
>> >
>> > I’m late again to this one, but the discussion’s certainly still going. 
>> > I’m pretty strongly against the bare ‘A & B’ syntax, for a few reasons:
>> >
>> > - Swift doesn’t use ‘&’ for anything except bitwise AND. In particular, it 
>> > didn’t get picked for set intersection.
>> 
>> I very, *very* much agree with this point. Thus far, Swift has been very 
>> conservative about overloading. It seems bizarre that we would violate that 
>> policy for these type combinators when much closer matches have been passed 
>> over.
>> 
>> I also think that using `&` absolutely *begs* to have an `|` as well, and as 
>> much as the Ceylon people clamor for them, I don't think union types make 
>> sense in Swift. Unlike Ceylon, Swift uses an algebraic data type for 
>> Optional, doesn't use type-erased generics, and supports overloading. As far 
>> as I can tell, *none* of the reasons cited in the Ceylon language design FAQ 
>>  apply to 
>> Swift.
>> 
>> (P.S. That language design FAQ is a *fantastic* document.)
>> 
>> > - In theory people are allowed to overload ‘&’ to operate on types. That 
>> > doesn’t make sense for all types, but you could probably come up with a 
>> > particular type hierarchy or use of generics where it does make sense.
>> >
>> > - I don’t like types with spaces in them when the spaces aren’t bracketed 
>> > in some way. This is entirely an aesthetic objection, of the form “I don’t 
>> > naturally read that as a type, or even as a single unit, when looking at 
>> > code.” This isn’t a great objection because someone could have said it 
>> > about `[Int]` or `Int?` as well. (It would be a more realistic objection 
>> > if some of our brackets weren’t “<" and “>”.)
>> 
>> To augment this: I think that if we're going to see a lot of little `where` 
>> clauses attached to types, you kind of have to have a bracketing syntax to 
>> put them in. And no, `(Collection where .Element == String)` doesn't count. 
>> `()` is about precedence, and this isn't a question of precedence; it's a 
>> question of making the type read as a single unit.
>> 
>> > And I still support the ‘Any’ syntax, despite the “order doesn’t matter” 
>> > problem:
>> >
>> > - It’s consistent with the existing unconstrained ‘Any’ and with the 
>> > current dedicated wrapper types. If we didn’t think it was a good name for 
>> > those, we wouldn’t use it there either.
>> 
>> One of my concerns with the `&` syntax is that it leaves no good way to 
>> define `Any`. I don't like having a magic `&` operator *and* a magic `Any` 
>> keyword, neither of which derives from anything more general.
>> 
>> > - It’s easily learnable. It’s rare enough that someone wouldn’t be exposed 
>> > to it right away, like Optional, Array, and Dictionary sugar, but when 
>> > they do see it it’ll be obvious that it’s a type, and probably obvious 
>> > that it’s special because of the “Any”.
>> >
>> > - It’s a type; types always start with uppercase letters. (This has been 
>> > said plenty by others.)
>> >
>> > None of these are particularly strong arguments, I know, and I don’t have 
>> > a good alternate suggestion. But I did want to go on record as being in 
>> > favor of ‘Any’ and against a binary operator, even though that seems to 
>> > put me in the minority.
>> 
>> I suspect that at least part of this is simply greater enthusiasm. I know I 
>> checked out of this thread for a few days while the `&` guys ran rampant.
>> 
>> (P.S. A thought I had just now: If `Any` is our top type, then `All` would 
>> be a good name for our bottom type. And `All` would be a good "All 
>> common supertypes of these types" operation. Both of these came up 

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

[Chris Lattner via swift-evolution]

On Jun 1, 2016, at 3:56 AM, Jeremy Pereira via swift-evolution 
 wrote:
>> One may argue that the comment-based markings can be handled by the IDE, but 
>> IMO transferring language features onto IDE is wrong. These comments do not 
>> appear anywhere within the log when the code is compiled.
> 
> 
> Something that is inside a comment is not a language feature by definition. 

You realize that both Clang and Swift parses structured doc comments?  Comments 
are an important part of the language, just like any other syntax.

-Chris

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

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

[Charles Constant via swift-evolution]

A single member version of this could be useful, too. Has anyone else here
ever found themself trying to think of an argument label for an init
method, just to ensure it has a unique signature? This would be handy:

*extension Foo {*
*convenience init( _ kind:(.DiskBased) ){*
*// *
*}*
*}*


*let diskFoo = Foo( .DiskBased )*

The thread does have some convincing arguments against it. It's not very
attractive if you think of it as a standard type like the existing enum. I
guess I think of it more as a preprocessor type of thing, as a replacement
for a function name or placeholder.



On Wed, Jun 1, 2016 at 3:02 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> > in other words, we could consider allowing this:
> >func foo(bar: (.fit | .fill)) {
> >  baz(bar: bar)
> >}
> >func baz(bar: (.fit | .fill | .florp) { ... }
> >
> > In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
> > expected if T ⊆ U.
>
> Can't agree with this. Just because the same analogue with tuples :
> differently defined tuples are different types. Tuples with different order
> of types in declaration - are different types. So I expect here instance of
> (.fit | .fill) `bar` is not of the same type as (.fit | .fill | .florp)
>
> But +1 to be able to 'convert' instance of (.fit | .fill) to instance of
> (.fit | .fill | .florp). For example(if we'll have init(caseName) and
> .caseName for enums):
>
> func foo(bar: (.fit | .fill)) {
> let bazbar = (.fit | .fill | .florp).init(caseName: bar.caseName)
> baz(bar: bazbar)
> }
> func baz(bar: (.fit | .fill | .florp) { ... }
>
>
>
> On 02.06.2016 0:38, Tony Allevato wrote:
>
>> I find myself agreeing with the idea that ad hoc enums are to enums as
>> structs are to tuples. Based on that analogy, why should an ad hoc enum
>> *need* a name (autogenerated or otherwise) any more than a tuple needs a
>> name? Would those who dislike ad hoc enums argue that this also shouldn't
>> be allowed:
>>
>> func foo(bar: (x: Int, y: Int)) {}
>> let t: (x: Int, y: Int) = (x: 5, y: 5)
>>
>> If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax
>> might be), that should just *be* the type the same way that `(x: Int, y:
>> Int)` is a type without a name, and that type can be used in argument
>> lists, variables, or whatever. There shouldn't be any worry about
>> declarations across multiple functions colliding or being incompatible any
>> more than we would worry about two functions declaring arguments of type
>> `(x: Int, y: Int)` would collide or be incompatible.
>>
>> One side of ad hoc enums that I'd like to see explored is that, by being
>> unnamed, they're basically anonymous finite sets and we could apply
>> well-defined subset relationships to them: in other words, we could
>> consider allowing this:
>>
>> func foo(bar: (.fit | .fill)) {
>>   baz(bar: bar)
>> }
>> func baz(bar: (.fit | .fill | .florp) { ... }
>>
>> In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
>> expected if T ⊆ U.
>>
>>
>> On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution
>> > wrote:
>>
>>
>>
>> > On Jun 1, 2016, at 6:51 PM, Vladimir.S > > wrote:
>> >
>> > Yes, I also can support the idea of autogenerated type name (like
>> Enum_fit_OR_fill) as long as it allows to do all the things we are
>> discussing here: declare (.fit|.fill) in function, use .fit on calling
>> side, use (.fit|.fill) to declare temporary variable of type
>> compatible
>> with such function parameter etc.
>> >
>>
>> It all works because the compiler is just being a thoughless scribe
>> that just writes the standard enum we don't bother to write ourselves.
>> Because the heuristic is simple and straightforward then it is
>> predictible. The enum can be used with its long name be ause it is a
>> real enum. And writing the short form of it also works because the
>> compiler knowns uniquely what the long name is everytime it runs into
>> the short name.
>>
>>
>> > But how do you suggest to define a type of such function in
>> `typealias` for example? i.e. for func my(option: (.fit|.fill) {..}
>> >
>> > typealias MyFunc = ((.fit|.fill)) -> ()
>> > or as
>> >
>> > typealias MyFunc = (Enum_fit_OR_fill) -> ()
>> >
>>
>> Ideally there is no difference whatsoever, there is a single enum, it
>> is produced at the module level, and it has the long form name.
>>
>> There can be rules that would prevent us from doing that with
>> externally visible APIs, if the core team fuges that we should take
>> the
>> time to write our enums manually and cleanly to make them visible to
>> the world, but it is not a necessary rule.
>>
>>
>> >
>> > But I still can't support the 

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

[Tony Allevato via swift-evolution]

On Wed, Jun 1, 2016 at 3:02 PM Vladimir.S  wrote:

>  > in other words, we could consider allowing this:
>  >func foo(bar: (.fit | .fill)) {
>  >  baz(bar: bar)
>  >}
>  >func baz(bar: (.fit | .fill | .florp) { ... }
>  >
>  > In other words, an ad hoc enum T can be used wherever an ad hoc enum U
> is
>  > expected if T ⊆ U.
>
> Can't agree with this. Just because the same analogue with tuples :
> differently defined tuples are different types. Tuples with different order
> of types in declaration - are different types. So I expect here instance of
> (.fit | .fill) `bar` is not of the same type as (.fit | .fill | .florp)
>

I would argue that the analogy to tuples doesn't apply in this case. For
tuples, order of the arguments matters, and part of the structural
definition of a tuple is the number of its elements. Neither of those
applies for an ad hoc enum—it is defined solely as a set of named cases.

After writing that, however, that *does* seem like the kind of implicit
conversion that Swift tends to avoid. So maybe an explicit conversion would
better fit the language design.


>
> But +1 to be able to 'convert' instance of (.fit | .fill) to instance of
> (.fit | .fill | .florp). For example(if we'll have init(caseName) and
> .caseName for enums):
>
> func foo(bar: (.fit | .fill)) {
>  let bazbar = (.fit | .fill | .florp).init(caseName: bar.caseName)
>  baz(bar: bazbar)
> }
> func baz(bar: (.fit | .fill | .florp) { ... }
>

I'm not crazy about this because I would expect a conversion that requires
a round-trip transformation of the string case name to be negative for
performance. Why not just:

let bazbar = (.fit | .fill | .florp)(bar)

which the compiler ought to be able to optimize much better?


>
>
> On 02.06.2016 0:38, Tony Allevato wrote:
> > I find myself agreeing with the idea that ad hoc enums are to enums as
> > structs are to tuples. Based on that analogy, why should an ad hoc enum
> > *need* a name (autogenerated or otherwise) any more than a tuple needs a
> > name? Would those who dislike ad hoc enums argue that this also shouldn't
> > be allowed:
> >
> > func foo(bar: (x: Int, y: Int)) {}
> > let t: (x: Int, y: Int) = (x: 5, y: 5)
> >
> > If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax
> > might be), that should just *be* the type the same way that `(x: Int, y:
> > Int)` is a type without a name, and that type can be used in argument
> > lists, variables, or whatever. There shouldn't be any worry about
> > declarations across multiple functions colliding or being incompatible
> any
> > more than we would worry about two functions declaring arguments of type
> > `(x: Int, y: Int)` would collide or be incompatible.
> >
> > One side of ad hoc enums that I'd like to see explored is that, by being
> > unnamed, they're basically anonymous finite sets and we could apply
> > well-defined subset relationships to them: in other words, we could
> > consider allowing this:
> >
> > func foo(bar: (.fit | .fill)) {
> >   baz(bar: bar)
> > }
> > func baz(bar: (.fit | .fill | .florp) { ... }
> >
> > In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
> > expected if T ⊆ U.
> >
> >
> > On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution
> > > wrote:
> >
> >
> >
> > > On Jun 1, 2016, at 6:51 PM, Vladimir.S  > > wrote:
> > >
> > > Yes, I also can support the idea of autogenerated type name (like
> > Enum_fit_OR_fill) as long as it allows to do all the things we are
> > discussing here: declare (.fit|.fill) in function, use .fit on
> calling
> > side, use (.fit|.fill) to declare temporary variable of type
> compatible
> > with such function parameter etc.
> > >
> >
> > It all works because the compiler is just being a thoughless scribe
> > that just writes the standard enum we don't bother to write
> ourselves.
> > Because the heuristic is simple and straightforward then it is
> > predictible. The enum can be used with its long name be ause it is a
> > real enum. And writing the short form of it also works because the
> > compiler knowns uniquely what the long name is everytime it runs into
> > the short name.
> >
> >
> > > But how do you suggest to define a type of such function in
> > `typealias` for example? i.e. for func my(option: (.fit|.fill) {..}
> > >
> > > typealias MyFunc = ((.fit|.fill)) -> ()
> > > or as
> > >
> > > typealias MyFunc = (Enum_fit_OR_fill) -> ()
> > >
> >
> > Ideally there is no difference whatsoever, there is a single enum, it
> > is produced at the module level, and it has the long form name.
> >
> > There can be rules that would prevent us from doing that with
> > externally visible APIs, if the core team fuges that we should take
> the
> >  

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

[Leonardo Pessoa via swift-evolution]

Brent, for needing "both Int and Double values" there is a proposal to add 
tuples instead of the current raw values or allowing assessor properties per 
case, you should check those out. Perhaps this could also be used to 
cryptoghaphically sign a raw value but I'm not sure.

As for working with enum values by name a few examples have already been posted 
in today but I've done a lot more research in the subject along the day and 
found there is a correlation between enums and nominal level values in 
statistics; we cannot test them for a particular order (this could also be 
interesting for statistic apps but it's another case) and no math with them is 
valid. So, e.g., the result of the following operation on the planets enum is 
nonsense:

|   let planet = Planet(rawValue: Planet.Mars.rawValue - 
Planet.Mercury.rawValue)

The result will be different if the enum values are zero based than if not. 
Also any change in list order or the base index or add a new element to the 
middle of the list will break your intended code if you're storing the raw 
value in a database. And we know these changes happen. Actually, given this 
characteristic of nominal types (statistic), we should vow to removing 
init(rawValue:) completely from the language.

The real value you're working with in enums is the enum case name not any 
associated values. By working with the name you're safe should any associated 
value change, should their order change, you'll only break your app if the case 
is removed/renamed (with the raw value, you risk having the wrong treatment 
being given should another enum case takes the value of a removed one).

I agree there are lots of important and more difficult things to review in the 
language but I wouldn't be wasting my time here if I didn't think this was 
equally important.

L

-Original Message-
From: "Brent Royal-Gordon" 
Sent: ‎01/‎06/‎2016 06:10 PM
To: "Leonardo Pessoa" 
Cc: "Vladimir.S" ; "swift-evolution" 

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

> This should work but feels like an ugly hack to me. What if I needed
> the enum like this?
> 
> |   enum Size : Double {
> |   case Fit = 0.5
> |   case Fill = 3.0
> |   }

What if you needed both Int and Double rawValues? What if you needed rawValues 
that were cryptographically signed? We have to decide which use cases are 
common enough to support directly in the language, and I'm not convinced that 
"I need to look cases up by name, but I have no choice but to use rawValue for 
something else" is one of them—that is, that it's *so* common that we need to 
direct our scarce engineering resources towards designing and implementing a 
separate feature merely to accommodate it. There are a whole lot of things that 
are *way* higher on our to-do list than this, arguably including 
metaprogramming features which would let you write this yourself instead of 
sticking it in the core language.

-- 
Brent Royal-Gordon
Architechies

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

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

[Vladimir.S via swift-evolution]

> in other words, we could consider allowing this:
>func foo(bar: (.fit | .fill)) {
>  baz(bar: bar)
>}
>func baz(bar: (.fit | .fill | .florp) { ... }
>
> In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
> expected if T ⊆ U.

Can't agree with this. Just because the same analogue with tuples : 
differently defined tuples are different types. Tuples with different order 
of types in declaration - are different types. So I expect here instance of 
(.fit | .fill) `bar` is not of the same type as (.fit | .fill | .florp)


But +1 to be able to 'convert' instance of (.fit | .fill) to instance of 
(.fit | .fill | .florp). For example(if we'll have init(caseName) and 
.caseName for enums):


func foo(bar: (.fit | .fill)) {
let bazbar = (.fit | .fill | .florp).init(caseName: bar.caseName)
baz(bar: bazbar)
}
func baz(bar: (.fit | .fill | .florp) { ... }



On 02.06.2016 0:38, Tony Allevato wrote:

I find myself agreeing with the idea that ad hoc enums are to enums as
structs are to tuples. Based on that analogy, why should an ad hoc enum
*need* a name (autogenerated or otherwise) any more than a tuple needs a
name? Would those who dislike ad hoc enums argue that this also shouldn't
be allowed:

func foo(bar: (x: Int, y: Int)) {}
let t: (x: Int, y: Int) = (x: 5, y: 5)

If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax
might be), that should just *be* the type the same way that `(x: Int, y:
Int)` is a type without a name, and that type can be used in argument
lists, variables, or whatever. There shouldn't be any worry about
declarations across multiple functions colliding or being incompatible any
more than we would worry about two functions declaring arguments of type
`(x: Int, y: Int)` would collide or be incompatible.

One side of ad hoc enums that I'd like to see explored is that, by being
unnamed, they're basically anonymous finite sets and we could apply
well-defined subset relationships to them: in other words, we could
consider allowing this:

func foo(bar: (.fit | .fill)) {
  baz(bar: bar)
}
func baz(bar: (.fit | .fill | .florp) { ... }

In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
expected if T ⊆ U.


On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution
> wrote:



> On Jun 1, 2016, at 6:51 PM, Vladimir.S > wrote:
>
> Yes, I also can support the idea of autogenerated type name (like
Enum_fit_OR_fill) as long as it allows to do all the things we are
discussing here: declare (.fit|.fill) in function, use .fit on calling
side, use (.fit|.fill) to declare temporary variable of type compatible
with such function parameter etc.
>

It all works because the compiler is just being a thoughless scribe
that just writes the standard enum we don't bother to write ourselves.
Because the heuristic is simple and straightforward then it is
predictible. The enum can be used with its long name be ause it is a
real enum. And writing the short form of it also works because the
compiler knowns uniquely what the long name is everytime it runs into
the short name.


> But how do you suggest to define a type of such function in
`typealias` for example? i.e. for func my(option: (.fit|.fill) {..}
>
> typealias MyFunc = ((.fit|.fill)) -> ()
> or as
>
> typealias MyFunc = (Enum_fit_OR_fill) -> ()
>

Ideally there is no difference whatsoever, there is a single enum, it
is produced at the module level, and it has the long form name.

There can be rules that would prevent us from doing that with
externally visible APIs, if the core team fuges that we should take the
time to write our enums manually and cleanly to make them visible to
the world, but it is not a necessary rule.


>
> But I still can't support the idea of limiting the usage of such
enums - i.e. "To deal with milti site definition, the compiler would
simply flag a error/warning, or be silent in the presence of a new
annotation:". I really think we need then introduce the same rule for
tuples - so no one can use the same tuple declaration in function -
they then should declare separate struct type or use @something for
such functions. Nobody wants such rule for tuples.
>

Multi site thing is not a limitation... Is is a proposed rule to say
that we are able to be lazy twice without being penalized. Yhe compiler
does not like when we define the same thing twice, and thse short form
amount to doing what he does not let us do. But because this is about
concise and lazy, then the compiler can let us get away with it if we
use an annotation that lets it know that "it is not a mistake.. I
really dont want to write that enum myself, even though I am using the
same 

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

[Callionica (Swift) via swift-evolution]

I support the original proposal. My assumption is that (.fit|.fill) is the
name of a type that can be used anywhere types can be named.

I think the concern about duplicates is misplaced. If the same developer
creates the scaleAndCrop function and the rect function, they may decide to
extract the enum type to a named enum when they see the second use. If they
don't, it's because they're in the flow - no harm results from naming this
type in two places. They have the opportunity to reconsider their decision
if they add cases later.

Ad hoc enums are to named enums as closures are to funcs: closures and ad
hoc enums both increase developer flow at the risk that the developer needs
to refactor later to maximize reuse and minimize duplication. Allowing
developers to make these trade-offs according to their own preference is a
good thing.

-- Callionica

On Tue, May 31, 2016 at 2:20 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> 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 this problem starts occurring *very* quickly. I mean, you've left
> `scaleAndCropImage`'s implementation out. Imagine implementing it with a
> couple helper functions, and you start to see this problem occurring:
>
> func scaleAndCrop(image: UIImage, to size: CGSize, operation:
> (.fit | .fill) = .fit) -> UIImage {
> let drawingRect = rect(of: size, for: operation)
> return drawnImage(image, in: drawingRect)
> }
>
> private func rect(of size: CGSize, for operation: (.fit | .fill))
> -> CGRect {
>
> Already we have one duplication; if we add .fillWidth and .fillHeight
> modes, we'll need to change signatures in two places.
>
> In short, when you dig into this proposal and start thinking of use cases
> that are even slightly less than completely trivial, I think the case for
> it falls apart.
>
> (It's also worth noting that this isn't suitable for options, because it
> creates an anonymous enum, not an anonymous option set.)
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 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] Working with enums by name

[Vladimir.S via swift-evolution]

Can't agree with Brent's opinion. For me the proposed init(caseName:String) 
and .caseName property for enum case - seems like  base feature that enum 
type must to have.


As for string as raw value for enum, please find this example:

enum E: String {
case one = "One"
case two = "Two"
}

print(E.one.rawValue)  // One
print(E(rawValue: "one")) // nil
print(E(rawValue: "One")) // Optional(main.E.one)

How do you suggest to transform the case name("one") to enum case variable? 
`init(rawValue:)` will accept assigned rawValue, not case name. Even worse, 
conforming to CustomStringConvertable can prevent you from have "one" as 
result String(E.one).


On 02.06.2016 0:10, Brent Royal-Gordon wrote:

This should work but feels like an ugly hack to me. What if I needed
the enum like this?

|   enum Size : Double {
|   case Fit = 0.5
|   case Fill = 3.0
|   }


What if you needed both Int and Double rawValues? What if you needed rawValues that were 
cryptographically signed? We have to decide which use cases are common enough to support 
directly in the language, and I'm not convinced that "I need to look cases up by 
name, but I have no choice but to use rawValue for something else" is one of 
them—that is, that it's *so* common that we need to direct our scarce engineering 
resources towards designing and implementing a separate feature merely to accommodate it. 
There are a whole lot of things that are *way* higher on our to-do list than this, 
arguably including metaprogramming features which would let you write this yourself 
instead of sticking it in the core language.


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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Andrew Bennett via swift-evolution]

I imagine you can use a combination of:

*Deferred for Future Discussion*:
https://github.com/apple/swift-evolution#deferred-for-future-discussion

*Accepted proposals which do not have a complete implementation:*

https://github.com/apple/swift-evolution#accepted-proposals-which-do-not-have-a-complete-implementation
*Pull requests:*
https://github.com/apple/swift-evolution/pulls



On Thu, Jun 2, 2016 at 3:25 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Feel free to convince the core team to add such a list. ;)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 1. Juni 2016 um 19:17:25, Vladimir.S (sva...@gmail.com) schrieb:
>
> Do we have any 'feature' to not just throw away of proposals(and then scan
> mail list and remember), but put them in queue of proposals that should be
> reviewed after Swift 3 is released?
>
> Probably some list of such proposals on site, don't know. So I believe any
> proposal that would be raised now and got support from community - should
> be added to that queue on some page somewhere on swift.org
>
> On 01.06.2016 20:03, Adrian Zubarev via swift-evolution wrote:
> > Given that Swift 3 is winding down, we are in a mode of declining PRs
> > for proposals that don’t align with its goals. Please bring this back
> > up for discussion this fall, thanks for understanding.
> >
> > Closed by Chris. Sad but we’ll have to wait a little longer for this
> change.
> >
> >
> >
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >
> > Am 1. Juni 2016 um 06:58:27, Thorsten Seitz (tseit...@icloud.com
> > ) schrieb:
> >
> >> +1
> >>
> >> `return` in guards should stay, because there one has to use either
> >> `return`, `continue` or `break`. It would be ugly and inconsistent if
> one
> >> of these could be left out.
> >>
> >> -Thorsten
> >>
> >> > Am 31.05.2016 um 20:16 schrieb Vladimir.S via swift-evolution <
> swift-evolution@swift.org>:
> >> >
> >> > I really like the proposal in case of properties and functions, but I
> really don't want to have
> >> > guard boolean else { "false" }
> >> >
> >> > I feel like `return` is very important part of `guard` statement.
> >> > I understand the requirement for consistency with
> properties/closures/functions, but I'll prefer to have some inconsistency
> in language in this case and require `return` for `guard`. And in case I'll
> have to choose all-or-nothig, I'll give -1 for the proposal.
> >> >
> >> > I.e. IMO current `return` in properties and functions is less evil
> than absent of `return` in `guard`.
> >> >
> >> >> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:
> >> >> Here is the draft proposal:
> >> >>
> https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md
> >> >>
> >> >> Did I covered everything case? If you find some mistakes feel free
> to
> >> >> provide feedback so I can fix the proposal before I submit a PR.
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Adrian Zubarev
> >> >> Sent with Airmail
> >> >>
> >> >> Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution
> >> >> (swift-evolution@swift.org )
> schrieb:
> >> >>
> >> >>> +1
> >> >>>
> >> >>> L
> >> >>>
> >> >>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution
> >> >>>  wrote:
> >> >>> >
> >> >>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
> >> >>> >>
> >> >>> >> It isn’t a special case because all other single-statement
> closures in the language work that way. It’s actually inconsistent now.
> >> >>> >
> >> >>> > Computed properties aren’t closures so it’s not inconsistent in
> that sense. But it is inconsistent in that closures are the *only*
> value-returning code blocks that are able to use this sugar. It would be
> nice to see this sugar consistently allowed everywhere in the language.
> >> >>> >
> >> >>> >>
> >> >>> >>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution
>  wrote:
> >> >>> >>>
> >> >>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
> >> >>> >>>
> >> >>>  The idea is simple:
> >> >>> 
> >> >>>  • Can we make return keyword optional in cases like this?
> >> >>>  • Shouldn’t this behave like @autoclosure or @noescape?
> >> >>>  type A {
> >> >>>  var characters: [Character] = …
> >> >>>  var string: String { String(self.characters) }
> >> >>>  var count: Int { 42 }
> >> >>>  }
> >> >>> 
> >> >>>  Is this worth a proposal or Swifty enough, what do you think?
> >> >>> 
> >> >>>  Sure I could write return, but why do we allow this behavior
> for @noescape functions like map!?
> >> >>> >>>
> >> >>> >>> While I am not necessarily against this idea, I do wonder if
> it’s worth making what’s going on here less 

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

[Tony Allevato via swift-evolution]

I find myself agreeing with the idea that ad hoc enums are to enums as
structs are to tuples. Based on that analogy, why should an ad hoc enum
*need* a name (autogenerated or otherwise) any more than a tuple needs a
name? Would those who dislike ad hoc enums argue that this also shouldn't
be allowed:

func foo(bar: (x: Int, y: Int)) {}
let t: (x: Int, y: Int) = (x: 5, y: 5)

If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax
might be), that should just *be* the type the same way that `(x: Int, y:
Int)` is a type without a name, and that type can be used in argument
lists, variables, or whatever. There shouldn't be any worry about
declarations across multiple functions colliding or being incompatible any
more than we would worry about two functions declaring arguments of type
`(x: Int, y: Int)` would collide or be incompatible.

One side of ad hoc enums that I'd like to see explored is that, by being
unnamed, they're basically anonymous finite sets and we could apply
well-defined subset relationships to them: in other words, we could
consider allowing this:

func foo(bar: (.fit | .fill)) {
  baz(bar: bar)
}
func baz(bar: (.fit | .fill | .florp) { ... }

In other words, an ad hoc enum T can be used wherever an ad hoc enum U is
expected if T ⊆ U.


On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> > On Jun 1, 2016, at 6:51 PM, Vladimir.S  wrote:
> >
> > Yes, I also can support the idea of autogenerated type name (like
> Enum_fit_OR_fill) as long as it allows to do all the things we are
> discussing here: declare (.fit|.fill) in function, use .fit on calling
> side, use (.fit|.fill) to declare temporary variable of type compatible
> with such function parameter etc.
> >
>
> It all works because the compiler is just being a thoughless scribe that
> just writes the standard enum we don't bother to write ourselves. Because
> the heuristic is simple and straightforward then it is predictible. The
> enum can be used with its long name be ause it is a real enum. And writing
> the short form of it also works because the compiler knowns uniquely what
> the long name is everytime it runs into the short name.
>
>
> > But how do you suggest to define a type of such function in `typealias`
> for example? i.e. for func my(option: (.fit|.fill) {..}
> >
> > typealias MyFunc = ((.fit|.fill)) -> ()
> > or as
> >
> > typealias MyFunc = (Enum_fit_OR_fill) -> ()
> >
>
> Ideally there is no difference whatsoever, there is a single enum, it is
> produced at the module level, and it has the long form name.
>
> There can be rules that would prevent us from doing that with externally
> visible APIs, if the core team fuges that we should take the time to write
> our enums manually and cleanly to make them visible to the world, but it is
> not a necessary rule.
>
>
> >
> > But I still can't support the idea of limiting the usage of such enums -
> i.e. "To deal with milti site definition, the compiler would simply flag a
> error/warning, or be silent in the presence of a new annotation:". I really
> think we need then introduce the same rule for tuples - so no one can use
> the same tuple declaration in function - they then should declare separate
> struct type or use @something for such functions. Nobody wants such rule
> for tuples.
> >
>
> Multi site thing is not a limitation... Is is a proposed rule to say that
> we are able to be lazy twice without being penalized. Yhe compiler does not
> like when we define the same thing twice, and thse short form amount to
> doing what he does not let us do. But because this is about concise and
> lazy, then the compiler can let us get away with it if we use an annotation
> that lets it know that "it is not a mistake.. I really dont want to write
> that enum myself, even though I am using the same abbreviation twice".
> Otherwise, the compiler would let us know that the second time could be a
> mistake because there is already something with the same name...
>
> But again this is a separate idea from the core notion of a syntax
> sugaring for writing real enums the lazy (clever) way
>
> >> On 01.06.2016 19:04, L. Mihalkovic wrote:
> >> The only problem with this proposal is to consider them ad-hoc enums...
> If we view them as having nothing ad-hoc about them and the thing to be a
> simple sugaring exercise, then I think all the opositions on grounds of
> breaking the language disapear. It still does not mean it should be done if
> the core team does not like the idea of encouraging laziness, or simply do
> not like what it makes them look like. No matter what, this type of
> sugaring exercise has been clearly stated as out of scope for 3.0
> >>
>  On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  On 01.06.2016 11:00, Austin Zheng wrote:
>  Tuples are a structural type, they are described entirely by the fact

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

[Christopher Kornher via swift-evolution]

Oops. I have wanted this feature and I have created `name` methods for 
non-String enums numerous times (whether I had to or not, I guess). If there is 
a formal proposal for this, I could not find it. I am obviously not familiar 
with the entire proposal but this is a feature that I have wanted almost from 
the first day I started using Swift.

I would prefer a `name`method for enums and not overload `description`.

A standard way of accessing the unique names of enum values would be compatible 
with a future variant of `enum` that would allow non-unique rawValue should 
Swift ever support that feature of C/C++ enums. (hint) It would become 
requirement for these enums, I think.

Accessing the names of enum values is extremely useful for diagnostics and 
quick and dirty UI e.g. playgrounds. 

> On Jun 1, 2016, at 3:07 PM, Paul Cantrell  wrote:
> 
> 
>> On Jun 1, 2016, at 2:20 PM, Christopher Kornher via swift-evolution 
>> > wrote:
>> 
>>> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution 
>>> > wrote:
>>> 
>>> This is the case I was thinking of where the module name comes into play. 
>>> Drop those enums into a framework, and you’ll get 
>>> "landed(MyFramework.CoinSide.heads)". Ugh!
>> 
>> This seems to be more of namespace “import” issue than a problem with enums 
>> specifically. Declaring enums within another entity is a useful. I take 
>> advantage of qualified naming to make short, possibly non-unique enum names.
> 
> Yes, in _code_ fully qualified names are useful.
> 
> This thread is the need for unqualified names in _strings_ — for passing to 
> external systems, logging, etc.
> 
> The problematic behavior I was pointing out is that enums get converted to a 
> name-only string when they are at the _top_ level of a data structure, but a 
> fully qualified Module.EnumType.caseName when they're _nested_ inside a 
> collection or another enum. AFAIK, there's no way to override this behavior 
> without manually coding a case statement to map enum values to strings. This 
> proposal would solve that.
> 
> Cheers, P
> 
> 

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

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

[Vladimir.S via swift-evolution]

OK, I understand most of your points and feel the same regarding the 
proposed feature... but:


> .. the compiler does not like when we define the same thing twice, and 
thse short form amount to doing what he does not let us do. ..

> .. if we use an annotation that lets it know that "it is not a mistake..
> I really dont want to write that enum myself, even though I am using the
> same abbreviation twice". Otherwise, the compiler would let us know that
> the second time could be a mistake because there is already something
> with the same name...

I just wanted to understand how such enums are different than tuples in 
meaning of "I don't want to write the struct myself", "Yes, I'm using the 
same tuple twice", "Compiler will let us know that we used the same tuple 
again and probably mistake as has already the same". (Not about differences 
in implementation/representation on compiler level, but on level of one who 
is writting the code)


Should we use the same arguments to propose the special annotation when we 
have the same tuple more than once? No. So I believe there should be no 
such limitation and special annotation for proposed enums.


On 01.06.2016 23:43, L. Mihalkovic wrote:




On Jun 1, 2016, at 6:51 PM, Vladimir.S  wrote:

Yes, I also can support the idea of autogenerated type name (like 
Enum_fit_OR_fill) as long as it allows to do all the things we are discussing 
here: declare (.fit|.fill) in function, use .fit on calling side, use 
(.fit|.fill) to declare temporary variable of type compatible with such 
function parameter etc.



It all works because the compiler is just being a thoughless scribe that just 
writes the standard enum we don't bother to write ourselves. Because the 
heuristic is simple and straightforward then it is predictible. The enum can be 
used with its long name be ause it is a real enum. And writing the short form 
of it also works because the compiler knowns uniquely what the long name is 
everytime it runs into the short name.



But how do you suggest to define a type of such function in `typealias` for 
example? i.e. for func my(option: (.fit|.fill) {..}

typealias MyFunc = ((.fit|.fill)) -> ()
or as

typealias MyFunc = (Enum_fit_OR_fill) -> ()



Ideally there is no difference whatsoever, there is a single enum, it is 
produced at the module level, and it has the long form name.

There can be rules that would prevent us from doing that with externally 
visible APIs, if the core team fuges that we should take the time to write our 
enums manually and cleanly to make them visible to the world, but it is not a 
necessary rule.




But I still can't support the idea of limiting the usage of such enums - i.e. "To 
deal with milti site definition, the compiler would simply flag a error/warning, or be 
silent in the presence of a new annotation:". I really think we need then introduce 
the same rule for tuples - so no one can use the same tuple declaration in function - 
they then should declare separate struct type or use @something for such functions. 
Nobody wants such rule for tuples.



Multi site thing is not a limitation... Is is a proposed rule to say that we are able to 
be lazy twice without being penalized. Yhe compiler does not like when we define the same 
thing twice, and thse short form amount to doing what he does not let us do. But because 
this is about concise and lazy, then the compiler can let us get away with it if we use 
an annotation that lets it know that "it is not a mistake.. I really dont want to 
write that enum myself, even though I am using the same abbreviation twice". 
Otherwise, the compiler would let us know that the second time could be a mistake because 
there is already something with the same name...

But again this is a separate idea from the core notion of a syntax sugaring for 
writing real enums the lazy (clever) way


On 01.06.2016 19:04, L. Mihalkovic wrote:
The only problem with this proposal is to consider them ad-hoc enums... If we 
view them as having nothing ad-hoc about them and the thing to be a simple 
sugaring exercise, then I think all the opositions on grounds of breaking the 
language disapear. It still does not mean it should be done if the core team 
does not like the idea of encouraging laziness, or simply do not like what it 
makes them look like. No matter what, this type of sugaring exercise has been 
clearly stated as out of scope for 3.0


On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution 
 wrote:

On 01.06.2016 11:00, Austin Zheng wrote:
Tuples are a structural type, they are described entirely by the fact
that they are a tuple, plus their contained types.

Enum cases are not individual types; that precedent exists nowhere in
Swift. You can't (yet) build a structural type out of something that
isn't a type. The fact that you had to propose something like
"AdhocEnumFitFill_2383748" as an autogenerated name for the type
demonstrates the 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Austin Zheng via swift-evolution]

After thinking about this topic for the past few days, I'd like to throw in
my support for "Any<>" as well. It's one magic construct to learn, looks
like a type, has the visual delineation, and shares continuity with both
protocol<> and Any today.

I'd also like to express my support for the proposal to delineate generic
and existential syntax: all existentials must be written with Any<...>;
generic type constraints cannot use it. I hope this will make it clear to
people learning and using the language that, despite their superficial
similarities, they are actually two different concepts.

Austin


On Wed, Jun 1, 2016 at 1:59 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > [Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
> ]
> >
> > I’m late again to this one, but the discussion’s certainly still going.
> I’m pretty strongly against the bare ‘A & B’ syntax, for a few reasons:
> >
> > - Swift doesn’t use ‘&’ for anything except bitwise AND. In particular,
> it didn’t get picked for set intersection.
>
> I very, *very* much agree with this point. Thus far, Swift has been very
> conservative about overloading. It seems bizarre that we would violate that
> policy for these type combinators when much closer matches have been passed
> over.
>
> I also think that using `&` absolutely *begs* to have an `|` as well, and
> as much as the Ceylon people clamor for them, I don't think union types
> make sense in Swift. Unlike Ceylon, Swift uses an algebraic data type for
> Optional, doesn't use type-erased generics, and supports overloading. As
> far as I can tell, *none* of the reasons cited in the Ceylon language
> design FAQ 
> apply to Swift.
>
> (P.S. That language design FAQ is a *fantastic* document.)
>
> > - In theory people are allowed to overload ‘&’ to operate on types. That
> doesn’t make sense for all types, but you could probably come up with a
> particular type hierarchy or use of generics where it does make sense.
> >
> > - I don’t like types with spaces in them when the spaces aren’t
> bracketed in some way. This is entirely an aesthetic objection, of the form
> “I don’t naturally read that as a type, or even as a single unit, when
> looking at code.” This isn’t a great objection because someone could have
> said it about `[Int]` or `Int?` as well. (It would be a more realistic
> objection if some of our brackets weren’t “<" and “>”.)
>
> To augment this: I think that if we're going to see a lot of little
> `where` clauses attached to types, you kind of have to have a bracketing
> syntax to put them in. And no, `(Collection where .Element == String)`
> doesn't count. `()` is about precedence, and this isn't a question of
> precedence; it's a question of making the type read as a single unit.
>
> > And I still support the ‘Any’ syntax, despite the “order doesn’t matter”
> problem:
> >
> > - It’s consistent with the existing unconstrained ‘Any’ and with the
> current dedicated wrapper types. If we didn’t think it was a good name for
> those, we wouldn’t use it there either.
>
> One of my concerns with the `&` syntax is that it leaves no good way to
> define `Any`. I don't like having a magic `&` operator *and* a magic `Any`
> keyword, neither of which derives from anything more general.
>
> > - It’s easily learnable. It’s rare enough that someone wouldn’t be
> exposed to it right away, like Optional, Array, and Dictionary sugar, but
> when they do see it it’ll be obvious that it’s a type, and probably obvious
> that it’s special because of the “Any”.
> >
> > - It’s a type; types always start with uppercase letters. (This has been
> said plenty by others.)
> >
> > None of these are particularly strong arguments, I know, and I don’t
> have a good alternate suggestion. But I did want to go on record as being
> in favor of ‘Any’ and against a binary operator, even though that seems to
> put me in the minority.
>
> I suspect that at least part of this is simply greater enthusiasm. I know
> I checked out of this thread for a few days while the `&` guys ran rampant.
>
> (P.S. A thought I had just now: If `Any` is our top type, then `All` would
> be a good name for our bottom type. And `All` would be a good
> "All common supertypes of these types" operation. Both of these came up in
> the variadic generics thread, where we were talking about how to create a
> type representing any member of a tuple you were trying to splat in.)
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 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] Enums with static stored properties for each case

[Brent Royal-Gordon via swift-evolution]

> UIBezierPath is shared for all instances of the enum case. So stored
> properties are stored per case, not per instance (you have associated
> values for per instance values).
> 
>> that isn't really what this syntax suggests is happening
> 
> Please explain what makes you think that way.

Because you wrote `let bezierPath = UIBezierPath()` in the middle of a type 
definition, and in all other types, you would get a new bezier path for each 
instance.

struct Struct {
let bezierPath = UIBezierPath() // per instance
}
class Class {
let bezierPath = UIBezierPath() // per instance
}
func function() {
let bezierPath = UIBezierPath() // per call
}
enum Enum {
case aCase {
let bezierPath = UIBezierPath() // shared?!?!
}
}

-- 
Brent Royal-Gordon
Architechies

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

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

[Brent Royal-Gordon via swift-evolution]

> This should work but feels like an ugly hack to me. What if I needed
> the enum like this?
> 
> |   enum Size : Double {
> |   case Fit = 0.5
> |   case Fill = 3.0
> |   }

What if you needed both Int and Double rawValues? What if you needed rawValues 
that were cryptographically signed? We have to decide which use cases are 
common enough to support directly in the language, and I'm not convinced that 
"I need to look cases up by name, but I have no choice but to use rawValue for 
something else" is one of them—that is, that it's *so* common that we need to 
direct our scarce engineering resources towards designing and implementing a 
separate feature merely to accommodate it. There are a whole lot of things that 
are *way* higher on our to-do list than this, arguably including 
metaprogramming features which would let you write this yourself instead of 
sticking it in the core language.

-- 
Brent Royal-Gordon
Architechies

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

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

[Paul Cantrell via swift-evolution]

> On Jun 1, 2016, at 2:20 PM, Christopher Kornher via swift-evolution 
> > wrote:
> 
>> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution 
>> > wrote:
>> 
>> This is the case I was thinking of where the module name comes into play. 
>> Drop those enums into a framework, and you’ll get 
>> "landed(MyFramework.CoinSide.heads)". Ugh!
> 
> This seems to be more of namespace “import” issue than a problem with enums 
> specifically. Declaring enums within another entity is a useful. I take 
> advantage of qualified naming to make short, possibly non-unique enum names.

Yes, in _code_ fully qualified names are useful.

This thread is the need for unqualified names in _strings_ — for passing to 
external systems, logging, etc.

The problematic behavior I was pointing out is that enums get converted to a 
name-only string when they are at the _top_ level of a data structure, but a 
fully qualified Module.EnumType.caseName when they're _nested_ inside a 
collection or another enum. AFAIK, there's no way to override this behavior 
without manually coding a case statement to map enum values to strings. This 
proposal would solve that.

Cheers, P


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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Brent Royal-Gordon via swift-evolution]

> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>  ]
> 
> I’m late again to this one, but the discussion’s certainly still going. I’m 
> pretty strongly against the bare ‘A & B’ syntax, for a few reasons:
> 
> - Swift doesn’t use ‘&’ for anything except bitwise AND. In particular, it 
> didn’t get picked for set intersection.

I very, *very* much agree with this point. Thus far, Swift has been very 
conservative about overloading. It seems bizarre that we would violate that 
policy for these type combinators when much closer matches have been passed 
over.

I also think that using `&` absolutely *begs* to have an `|` as well, and as 
much as the Ceylon people clamor for them, I don't think union types make sense 
in Swift. Unlike Ceylon, Swift uses an algebraic data type for Optional, 
doesn't use type-erased generics, and supports overloading. As far as I can 
tell, *none* of the reasons cited in the Ceylon language design FAQ 
 apply to Swift.

(P.S. That language design FAQ is a *fantastic* document.)

> - In theory people are allowed to overload ‘&’ to operate on types. That 
> doesn’t make sense for all types, but you could probably come up with a 
> particular type hierarchy or use of generics where it does make sense.
> 
> - I don’t like types with spaces in them when the spaces aren’t bracketed in 
> some way. This is entirely an aesthetic objection, of the form “I don’t 
> naturally read that as a type, or even as a single unit, when looking at 
> code.” This isn’t a great objection because someone could have said it about 
> `[Int]` or `Int?` as well. (It would be a more realistic objection if some of 
> our brackets weren’t “<" and “>”.)

To augment this: I think that if we're going to see a lot of little `where` 
clauses attached to types, you kind of have to have a bracketing syntax to put 
them in. And no, `(Collection where .Element == String)` doesn't count. `()` is 
about precedence, and this isn't a question of precedence; it's a question of 
making the type read as a single unit.

> And I still support the ‘Any’ syntax, despite the “order doesn’t matter” 
> problem:
> 
> - It’s consistent with the existing unconstrained ‘Any’ and with the current 
> dedicated wrapper types. If we didn’t think it was a good name for those, we 
> wouldn’t use it there either.

One of my concerns with the `&` syntax is that it leaves no good way to define 
`Any`. I don't like having a magic `&` operator *and* a magic `Any` keyword, 
neither of which derives from anything more general.

> - It’s easily learnable. It’s rare enough that someone wouldn’t be exposed to 
> it right away, like Optional, Array, and Dictionary sugar, but when they do 
> see it it’ll be obvious that it’s a type, and probably obvious that it’s 
> special because of the “Any”.
> 
> - It’s a type; types always start with uppercase letters. (This has been said 
> plenty by others.)
> 
> None of these are particularly strong arguments, I know, and I don’t have a 
> good alternate suggestion. But I did want to go on record as being in favor 
> of ‘Any’ and against a binary operator, even though that seems to put me in 
> the minority.

I suspect that at least part of this is simply greater enthusiasm. I know I 
checked out of this thread for a few days while the `&` guys ran rampant.

(P.S. A thought I had just now: If `Any` is our top type, then `All` would be a 
good name for our bottom type. And `All` would be a good "All common 
supertypes of these types" operation. Both of these came up in the variadic 
generics thread, where we were talking about how to create a type representing 
any member of a tuple you were trying to splat in.)

-- 
Brent Royal-Gordon
Architechies

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

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

[L. Mihalkovic via swift-evolution]

> On Jun 1, 2016, at 6:51 PM, Vladimir.S  wrote:
> 
> Yes, I also can support the idea of autogenerated type name (like 
> Enum_fit_OR_fill) as long as it allows to do all the things we are discussing 
> here: declare (.fit|.fill) in function, use .fit on calling side, use 
> (.fit|.fill) to declare temporary variable of type compatible with such 
> function parameter etc.
> 

It all works because the compiler is just being a thoughless scribe that just 
writes the standard enum we don't bother to write ourselves. Because the 
heuristic is simple and straightforward then it is predictible. The enum can be 
used with its long name be ause it is a real enum. And writing the short form 
of it also works because the compiler knowns uniquely what the long name is 
everytime it runs into the short name.


> But how do you suggest to define a type of such function in `typealias` for 
> example? i.e. for func my(option: (.fit|.fill) {..}
> 
> typealias MyFunc = ((.fit|.fill)) -> ()
> or as
> 
> typealias MyFunc = (Enum_fit_OR_fill) -> ()
> 

Ideally there is no difference whatsoever, there is a single enum, it is 
produced at the module level, and it has the long form name.

There can be rules that would prevent us from doing that with externally 
visible APIs, if the core team fuges that we should take the time to write our 
enums manually and cleanly to make them visible to the world, but it is not a 
necessary rule.


> 
> But I still can't support the idea of limiting the usage of such enums - i.e. 
> "To deal with milti site definition, the compiler would simply flag a 
> error/warning, or be silent in the presence of a new annotation:". I really 
> think we need then introduce the same rule for tuples - so no one can use the 
> same tuple declaration in function - they then should declare separate struct 
> type or use @something for such functions. Nobody wants such rule for tuples.
> 

Multi site thing is not a limitation... Is is a proposed rule to say that we 
are able to be lazy twice without being penalized. Yhe compiler does not like 
when we define the same thing twice, and thse short form amount to doing what 
he does not let us do. But because this is about concise and lazy, then the 
compiler can let us get away with it if we use an annotation that lets it know 
that "it is not a mistake.. I really dont want to write that enum myself, even 
though I am using the same abbreviation twice". Otherwise, the compiler would 
let us know that the second time could be a mistake because there is already 
something with the same name...

But again this is a separate idea from the core notion of a syntax sugaring for 
writing real enums the lazy (clever) way

>> On 01.06.2016 19:04, L. Mihalkovic wrote:
>> The only problem with this proposal is to consider them ad-hoc enums... If 
>> we view them as having nothing ad-hoc about them and the thing to be a 
>> simple sugaring exercise, then I think all the opositions on grounds of 
>> breaking the language disapear. It still does not mean it should be done if 
>> the core team does not like the idea of encouraging laziness, or simply do 
>> not like what it makes them look like. No matter what, this type of sugaring 
>> exercise has been clearly stated as out of scope for 3.0
>> 
 On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution 
  wrote:
 
 On 01.06.2016 11:00, Austin Zheng wrote:
 Tuples are a structural type, they are described entirely by the fact
 that they are a tuple, plus their contained types.
 
 Enum cases are not individual types; that precedent exists nowhere in
 Swift. You can't (yet) build a structural type out of something that
 isn't a type. The fact that you had to propose something like
 "AdhocEnumFitFill_2383748" as an autogenerated name for the type
 demonstrates the proposal's weaknesses: a tuple is an ad-hoc type that
 describes itself, while an anonymous enum isn't.
>>> 
>>> Yes, I understand the point about the type of such adhoc enum.
>>> The only workaround I can see in this case(if we'd really want to have it 
>>> in language) if adhoc enum type will be `(.Fit|.Fill)` i.e. textual 
>>> representation if the declared type. As I understand this also could not be 
>>> a solution.. I.e. for example `(Int,String,(.Fit|.Fill))->String`
>>> 
>>> From other point of view, adding such type to typesystem will add some 
>>> consistence : you can create a function that don't need definition of 
>>> separate structure type(tuple will be used) and don't need separate enum 
>>> type(ad-hoc enum will be used). I.e. all data the function needs to process 
>>> could be described in function definition. Today we need to use ugly Bool 
>>> flags in case we want to achieve the same target.
>>> 
 
 Now if enum cases were equivalent if they had the same name (like how
 "Int" means the same thing no matter what tuple or generic type it is

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

[Leonardo Pessoa via swift-evolution]

Enums outside frameworks will still rely on you as the programmer to
know to which enum the string representation belongs to (it does so
for the raw values) so I see no reason why the .caseName result should
have the name of any underlying type the case belongs to.

L

On 1 June 2016 at 16:20, Christopher Kornher via swift-evolution
 wrote:
>
> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution
>  wrote:
>
> Indeed, you’re quite right: verified that I get “Mars” even when the enum is
> in a framework.
>
> It took a little digging to get back what I was thinking of: it’s when the
> enum value is inside some other data structure that you get an annoyingly
> fully qualified name:
>
> enum CoinSide {
> case heads
> case tails
> }
>
> enum CoinState {
> case inAir
> case landed(showing: CoinSide)
> }
>
> print(CoinState.inAir)  // → "inAir"
>
> // …but…
>
> print(CoinState.landed(showing: .heads))  // → "landed(CoinSide.heads)"
>
> print([CoinSide.heads: 1])  // → "[CoinSide.heads: 1]"
>
> This is the case I was thinking of where the module name comes into play.
> Drop those enums into a framework, and you’ll get
> "landed(MyFramework.CoinSide.heads)". Ugh!
>
>
> This seems to be more of namespace “import” issue than a problem with enums
> specifically. Declaring enums within another entity is a useful. I take
> advantage of qualified naming to make short, possibly non-unique enum names.
>
>
> So what if you want those second two to print out as "landed(heads)" and
> "[heads: 1]”? This does not work:
>
> enum CoinSide: CustomStringConvertible {
> case heads
> case tails
>
> var description: String {
> return String(self) // infinite recursion
> }
> }
>
> There’s no automatically implemented description (or debugDescription)
> property we can delegate to. The conversion of .heads →  "heads" is
> apparently runtime magic that we lose access to as soon as we implement
> CustomStringConvertible or CustomDebugStringConvertible, and therefore AFAIK
> there's no way to do this other than switching on all the cases:
>
> enum CoinSide: CustomStringConvertible {
> case heads
> case tails
>
> var description: String {
> switch(self) {
> case heads: return "heads"
> case tails: return "tails"
> }
> }
> }
>
> Is is true that there’s no better way? Is there some
> CustomVerboseDebugStringConvertible protocol we can override to change only
> the "MyFramework.CoinSide.heads" form?
>
> If indeed there is no better way, it seems like a really good case for
> having the synthesized .caseName property. Even if there is a
> CustomVerboseDebugStringConvertible to override in the particular case
> above, being able to customize an enum’s description but still use the enum
> case name in that description seems like a compelling use case as well.
>
> Cheers, P
>
> On Jun 1, 2016, at 10:47 AM, Leonardo Pessoa  wrote:
>
> Paul, in all my tests for this thread printing the enum value only
> produced the enum value's name ("Mars" in your example). The proposal
> of having a .caseName (or should it better be .caseValue to cover
> enums with associated values? any other suggestions?) will prevent
> that changes to this behaviour crash apps in the future as this should
> always produce the same result even if the string representation
> changes.
>
> L
>
> On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution
>  wrote:
>
> IIRC, string interpolation prepends the module name if the enum belongs to a
> module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of
> compiler crashes, at least in the past.
>
> Those two factors forced me into this ugliness:
> https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115
>
> A clean, documented, supported way of exposing the enum case name that the
> runtime clearly already has available seems sensible — and should be
> independent of the raw type.
>
> Cheers, P
>
> On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution
>  wrote:
>
> This is, however, kind of a hack IMHO that relies on the compiler behavior
> that isn't well documented.
>
> For example, this:
>
> enum Planet {
>  case Earth
>  case Mars
> }
>
> "\(Planet.Mars)" // This is "Mars"
>
>
> Works as well. You don't need to have the represented value to be String.
>
> Note that this:
>
> - works both when you have a plain enum, or enum Planet: Int, or whatever
> raw value kind
> - does not work (!) when declared as @objc - then the result is "Planet".
>
> On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution
>  wrote:
>
> I had no idea you could do this!!
>
> On 1 Jun 2016, at 12:32 PM, Brent 

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

[Christopher Kornher via swift-evolution]

> On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> Indeed, you’re quite right: verified that I get “Mars” even when the enum is 
> in a framework.
> 
> It took a little digging to get back what I was thinking of: it’s when the 
> enum value is inside some other data structure that you get an annoyingly 
> fully qualified name:
> 
> enum CoinSide {
> case heads
> case tails
> }
> 
> enum CoinState {
> case inAir
> case landed(showing: CoinSide)
> }
> 
> print(CoinState.inAir)  // → "inAir"
> 
> // …but…
> 
> print(CoinState.landed(showing: .heads))  // → "landed(CoinSide.heads)"
> 
> print([CoinSide.heads: 1])  // → "[CoinSide.heads: 1]"
> 
> This is the case I was thinking of where the module name comes into play. 
> Drop those enums into a framework, and you’ll get 
> "landed(MyFramework.CoinSide.heads)". Ugh!

This seems to be more of namespace “import” issue than a problem with enums 
specifically. Declaring enums within another entity is a useful. I take 
advantage of qualified naming to make short, possibly non-unique enum names.

> 
> So what if you want those second two to print out as "landed(heads)" and 
> "[heads: 1]”? This does not work:
> 
> enum CoinSide: CustomStringConvertible {
> case heads
> case tails
> 
> var description: String {
> return String(self) // infinite recursion
> }
> }
> 
> There’s no automatically implemented description (or debugDescription) 
> property we can delegate to. The conversion of .heads →  "heads" is 
> apparently runtime magic that we lose access to as soon as we implement 
> CustomStringConvertible or CustomDebugStringConvertible, and therefore AFAIK 
> there's no way to do this other than switching on all the cases:
> 
> enum CoinSide: CustomStringConvertible {
> case heads
> case tails
> 
> var description: String {
> switch(self) {
> case heads: return "heads"
> case tails: return "tails"
> }
> }
> }
> 
> Is is true that there’s no better way? Is there some 
> CustomVerboseDebugStringConvertible protocol we can override to change only 
> the "MyFramework.CoinSide.heads" form?
> 
> If indeed there is no better way, it seems like a really good case for having 
> the synthesized .caseName property. Even if there is a 
> CustomVerboseDebugStringConvertible to override in the particular case above, 
> being able to customize an enum’s description but still use the enum case 
> name in that description seems like a compelling use case as well.
> 
> Cheers, P
> 
>> On Jun 1, 2016, at 10:47 AM, Leonardo Pessoa > > wrote:
>> 
>> Paul, in all my tests for this thread printing the enum value only
>> produced the enum value's name ("Mars" in your example). The proposal
>> of having a .caseName (or should it better be .caseValue to cover
>> enums with associated values? any other suggestions?) will prevent
>> that changes to this behaviour crash apps in the future as this should
>> always produce the same result even if the string representation
>> changes.
>> 
>> L
>> 
>> On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution
>> > wrote:
>>> IIRC, string interpolation prepends the module name if the enum belongs to 
>>> a module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of 
>>> compiler crashes, at least in the past.
>>> 
>>> Those two factors forced me into this ugliness: 
>>> https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115
>>>  
>>> 
>>> 
>>> A clean, documented, supported way of exposing the enum case name that the 
>>> runtime clearly already has available seems sensible — and should be 
>>> independent of the raw type.
>>> 
>>> Cheers, P
>>> 
 On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution 
  wrote:
 
 This is, however, kind of a hack IMHO that relies on the compiler behavior 
 that isn't well documented.
 
 For example, this:
 
 enum Planet {
  case Earth
  case Mars
 }
 
 "\(Planet.Mars)" // This is "Mars"
 
 
 Works as well. You don't need to have the represented value to be String.
 
 Note that this:
 
 - works both when you have a plain enum, or enum Planet: Int, or whatever 
 raw value kind
 - does not work (!) when declared as @objc - then the result is "Planet".
 
> On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution 
>  wrote:
> 
> I had no idea you could do this!!
> 
>> On 1 Jun 2016, at 12:32 PM, 

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

[Paul Cantrell via swift-evolution]

Indeed, you’re quite right: verified that I get “Mars” even when the enum is in 
a framework.

It took a little digging to get back what I was thinking of: it’s when the enum 
value is inside some other data structure that you get an annoyingly fully 
qualified name:

enum CoinSide {
case heads
case tails
}

enum CoinState {
case inAir
case landed(showing: CoinSide)
}

print(CoinState.inAir)  // → "inAir"

// …but…

print(CoinState.landed(showing: .heads))  // → "landed(CoinSide.heads)"

print([CoinSide.heads: 1])  // → "[CoinSide.heads: 1]"

This is the case I was thinking of where the module name comes into play. Drop 
those enums into a framework, and you’ll get 
"landed(MyFramework.CoinSide.heads)". Ugh!

So what if you want those second two to print out as "landed(heads)" and 
"[heads: 1]”? This does not work:

enum CoinSide: CustomStringConvertible {
case heads
case tails

var description: String {
return String(self) // infinite recursion
}
}

There’s no automatically implemented description (or debugDescription) property 
we can delegate to. The conversion of .heads →  "heads" is apparently runtime 
magic that we lose access to as soon as we implement CustomStringConvertible or 
CustomDebugStringConvertible, and therefore AFAIK there's no way to do this 
other than switching on all the cases:

enum CoinSide: CustomStringConvertible {
case heads
case tails

var description: String {
switch(self) {
case heads: return "heads"
case tails: return "tails"
}
}
}

Is is true that there’s no better way? Is there some 
CustomVerboseDebugStringConvertible protocol we can override to change only the 
"MyFramework.CoinSide.heads" form?

If indeed there is no better way, it seems like a really good case for having 
the synthesized .caseName property. Even if there is a 
CustomVerboseDebugStringConvertible to override in the particular case above, 
being able to customize an enum’s description but still use the enum case name 
in that description seems like a compelling use case as well.

Cheers, P

> On Jun 1, 2016, at 10:47 AM, Leonardo Pessoa  wrote:
> 
> Paul, in all my tests for this thread printing the enum value only
> produced the enum value's name ("Mars" in your example). The proposal
> of having a .caseName (or should it better be .caseValue to cover
> enums with associated values? any other suggestions?) will prevent
> that changes to this behaviour crash apps in the future as this should
> always produce the same result even if the string representation
> changes.
> 
> L
> 
> On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution
>  wrote:
>> IIRC, string interpolation prepends the module name if the enum belongs to a 
>> module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of 
>> compiler crashes, at least in the past.
>> 
>> Those two factors forced me into this ugliness: 
>> https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115
>> 
>> A clean, documented, supported way of exposing the enum case name that the 
>> runtime clearly already has available seems sensible — and should be 
>> independent of the raw type.
>> 
>> Cheers, P
>> 
>>> On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution 
>>>  wrote:
>>> 
>>> This is, however, kind of a hack IMHO that relies on the compiler behavior 
>>> that isn't well documented.
>>> 
>>> For example, this:
>>> 
>>> enum Planet {
>>>  case Earth
>>>  case Mars
>>> }
>>> 
>>> "\(Planet.Mars)" // This is "Mars"
>>> 
>>> 
>>> Works as well. You don't need to have the represented value to be String.
>>> 
>>> Note that this:
>>> 
>>> - works both when you have a plain enum, or enum Planet: Int, or whatever 
>>> raw value kind
>>> - does not work (!) when declared as @objc - then the result is "Planet".
>>> 
 On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution 
  wrote:
 
 I had no idea you could do this!!
 
> On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Who said anything about repeating the name?
> 
> Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). 
> Type :help for assistance.
> 1> enum Planet: String { case mercury, venus, earth, mars, jupiter, 
> saturn, uranus, neptune }
> 2> Planet.mercury.rawValue
> $R0: String = "mercury"
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> 

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

[Jordan Rose via swift-evolution]

> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On May 29, 2016, at 12:58 PM, Erica Sadun  wrote:
>> 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. 
> 
> Right: it isn’t a bad thing at all, but it is certainly the case that people 
> often request adding features to Swift that they see in other languages.  Our 
> task is to look at whether the problem is real and significant enough to 
> solve, and if the proposal solves it in the best possible way consistent with 
> the rest of Swift.
> 
> An similar example is "#pragma mark”.  Instead of introducing language 
> support for it, we codified a comment marker (since it is semantically 
> identical to a comment).  Xcode picks it up and does the right thing, and I 
> think it has worked out well.
> 
> As to #warning, Swift’s use of warnings are significant different than the 
> use in C.  In C compilers, many of the warnings produced *should* be errors, 
> but can’t be because that effects language conformance and could break a 
> large body of code.  Swift doesn’t have this problem, so it treats warnings 
> as “things that should be addressed before you commit your patch, but 
> shouldn’t block a build if (e.g.) you’re in the middle of a big refactoring”. 
>  For example, an unused variables is a warning in Swift.

This sounds exactly like what I’d use #warning for. “I’m in the middle of a big 
refactoring, and I haven’t gotten to this part yet; let me put a warning in so 
I can test the other part but won’t forget to come back to it.” It might also 
make sense for doing a series of commits on a branch when you need to fix 
something before merging back to trunk.

I think it is important for such diagnostics to show up in compilation, not 
just in IDEs, especially with people using the Swift Package Manager. We could 
have the compiler parse every comment looking for TODOs and FIXMEs by default, 
and emit those as warnings, but I’d want to find out if that creates a 
noticeable difference in parsing time. (It also seems odd that comments would 
be controlled by #if, but maybe that’s silly.)

+1 to the proposal from me, though I agree with Brent that the parentheses 
don’t feel right. This is closer to #if and #setline than #available and 
#selector.

Jordan

P.S. #error is also interesting, but more for “things that should never happen” 
(like the else branch of a platform check), which makes it a bit less 
important. #info/#message can be useful but I’d like to see a concrete case 
before designing it.


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

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Goffredo Marocchi via swift-evolution]

Hello David,

Could you elaborate on this more? Seeing the possibilities of FSM's in
Swift using its powerful enum and case pattern matching was one of the
moments in which Swift started increasing its allure factor ;).

Part 1 (background and theory):
http://www.figure.ink/blog/2015/1/31/swift-state-machines-part-1

Part 2 (start of the implementation):
http://www.figure.ink/blog/2015/2/1/swift-state-machines-part-2

Part 3:
http://www.figure.ink/blog/2015/2/8/swift-state-machines-part-3-follow-up

Part 4:
http://www.figure.ink/blog/2015/2/9/swift-state-machines-part-4-redirect



Final gist: https://gist.github.com/jemmons/f30f1de292751da0f1b7


On Wed, Jun 1, 2016 at 3:48 PM, David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> One thing I did often in Java (and miss in Swift) is using their enums to
> build state machines or implement command patterns for common commands.
>
> Java enums are a sealed set of subclasses of the enum base type with
> (hopefully) immutable, singleton instances. So you can do fun things like:
> - Define the base class constructor to be called to instantiate the
> subclasses, and declare the cases with the constructor arguments
> - Declare a method on the base type and refine it on 1-2 particular cases
> - Declare the enum implements an interface, and implement that interface
> separately for each case.
> - Define data accessors specific to the type (such as the planets example
> above)
>
> I like the SuitInfo approach below - with extensions, I think I can get
> close to what I have done in the past with Java. Maybe one day there is
> syntax to do this in the language directly
>
> -DW
>
> > On May 31, 2016, at 11:44 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I'm not sure about my opinion on this proposal, but I believe you should
> add this as alternatives of how we can have the similar features today
> without injecting stored properties into enums  :
> >
> > enum Suit {
> >case spades
> >case hearts
> >case diamonds
> >case clubs
> >
> >struct SuitInfo {
> >let simpleDescription: String
> >let color: UIColor
> >let symbol: String
> >let bezierPath: UIBezierPath
> >}
> >
> >var info : SuitInfo {
> >switch self {
> >case .spades:
> >let path = UIBezierPath()
> >// omitted lines ...
> >
> >return SuitInfo(
> >simpleDescription: "spades",
> >color: .blackColor(),
> >symbol: "♠",
> >bezierPath: path)
> >
> >case .hearts:
> >let path = UIBezierPath()
> >// omitted lines ...
> >
> >return SuitInfo(
> >simpleDescription: "hearts",
> >color: .redColor(),
> >symbol: "♥",
> >bezierPath: path)
> >
> >case .diamonds:
> >let path = UIBezierPath()
> >// omitted lines ...
> >
> >return SuitInfo(
> >simpleDescription: "diamonds",
> >color: .redColor(),
> >symbol: "♦",
> >bezierPath: path)
> >
> >case .clubs:
> >let path = UIBezierPath()
> >// omitted lines ...
> >
> >return SuitInfo(
> >simpleDescription: "clubs",
> >color: .blackColor(),
> >symbol: "♣",
> >bezierPath: path)
> >
> >}
> >}
> > }
> >
> > and this:
> >
> > enum Suit  {
> >case spades
> >case hearts
> >case diamonds
> >case clubs
> >
> >struct SuitInfo  {
> >let simpleDescription: String
> >let color: UIColor
> >let symbol: String
> >let bezierPath: UIBezierPath
> >}
> >
> >static let spadesInfo : SuitInfo = {
> >let path = UIBezierPath()
> >// omitted lines ...
> >
> >return SuitInfo(
> >simpleDescription: "spades",
> >color: .blackColor(),
> >symbol: "♠",
> >bezierPath: path)
> >}()
> >
> >static let heartsInfo : SuitInfo = {
> >let path = UIBezierPath()
> >// omitted lines ...
> >
> >return SuitInfo(
> >simpleDescription: "hearts",
> >color: .redColor(),
> >symbol: "♥",
> >bezierPath: path)
> >}()
> >
> >static let diamondsInfo : SuitInfo = {
> >let path = UIBezierPath()
> >// omitted lines ...
> >
> >return SuitInfo(
> >simpleDescription: "diamonds",
> >color: .redColor(),
> >symbol: "♦",
> >bezierPath: path)
> >}()
> >
> >static let clubsInfo : SuitInfo = {
> >let path = UIBezierPath()
> >// omitted lines ...
> >
> >return SuitInfo(
> >simpleDescription: "clubs",
> >color: .blackColor(),
> >symbol: "♣",
> >  

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

[Xiaodi Wu via swift-evolution]

It is of course true that all parts of a conditional statement have
something in common with each other, namely that they are part of the same
conditional statement.

A problem definitely exists with the current syntax, which is that the de
minimis semantic relationship you are showing is not the relationship
implied by the meaning of the word "where."

It is acceptable to say, "I will buy all the apples that are on sale, where
the sale is 5% off or better." It is not acceptable to say, "I will buy all
the apples that are on sale, where my bike is large," even if it is true
that you would only buy all the apples if you had a large bike to transport
them home.

On Wed, Jun 1, 2016 at 11:50 Thorsten Seitz  wrote:

>
>
> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>:
>
> Revisiting this conversation, it seems that most of the design space has
> been thoroughly explored. I think all suggestions presented so far boil
> down to these:
>
> Q: How is an arbitrary boolean assertion introduced after `if let`?
>
> Option 1 (present scenario)--using `where`
> Advantages: expressive when it means exactly the right thing
> Drawbacks: makes obligatory the suggestion of a semantic relationship
> between what comes before and after even when there is no such relationship
>
>
> Haravikk already demonstrated that a semantic relationship always exists
> in the sense of "bind this variable for all caes where the following
> condition holds".
>
> So, the perceived problem with the `where` clause does not exist.
>
> -Thorsten
>
>
>
> Option 2--using a symbol sometimes encountered in conditional statements
> (e.g. `&&` or comma)
> Advantages: doesn't look out of place
> Drawbacks: needs to be disambiguated from existing uses, necessitating
> other changes in syntax
>
> Option 3--using a symbol never encountered in conditional statements (e.g.
> semicolon)
> Advantages: doesn't need to be disambiguated from any existing uses
> Drawbacks: looks out of place
>
> For me, options 1 and 2 have permanent and objective drawbacks. By
> contrast, familiarity increases with time, and beauty is in the eye of the
> beholder.
>
> * * *
>
> It does occur to me that there is one more option. I don't know that I
> like it, but it's an option no one has put forward before: recite the
> opening keyword when beginning a new boolean expression:
>
> `if let x = x where x < 3 { ... }` becomes
> `if let x = x if x < 3 { ... }`
>
> `while let item = sequence.next() where item > 0 { ... }` becomes
> `while let item = sequence.next() while item > 0 { ... }`
>
> etc.
>
>
> On Tue, May 31, 2016 at 2:00 PM, Erica Sadun  wrote:
>
>>
>> > 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

Feel free to convince the core team to add such a list. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 19:17:25, Vladimir.S (sva...@gmail.com) schrieb:

Do we have any 'feature' to not just throw away of proposals(and then scan  
mail list and remember), but put them in queue of proposals that should be  
reviewed after Swift 3 is released?  

Probably some list of such proposals on site, don't know. So I believe any  
proposal that would be raised now and got support from community - should  
be added to that queue on some page somewhere on swift.org  

On 01.06.2016 20:03, Adrian Zubarev via swift-evolution wrote:  
> Given that Swift 3 is winding down, we are in a mode of declining PRs  
> for proposals that don’t align with its goals. Please bring this back  
> up for discussion this fall, thanks for understanding.  
>  
> Closed by Chris. Sad but we’ll have to wait a little longer for this change.  
>  
>  
>  
> --  
> Adrian Zubarev  
> Sent with Airmail  
>  
> Am 1. Juni 2016 um 06:58:27, Thorsten Seitz (tseit...@icloud.com  
> ) schrieb:  
>  
>> +1  
>>  
>> `return` in guards should stay, because there one has to use either  
>> `return`, `continue` or `break`. It would be ugly and inconsistent if one  
>> of these could be left out.  
>>  
>> -Thorsten  
>>  
>> > Am 31.05.2016 um 20:16 schrieb Vladimir.S via swift-evolution 
>> > :  
>> >  
>> > I really like the proposal in case of properties and functions, but I 
>> > really don't want to have  
>> > guard boolean else { "false" }  
>> >  
>> > I feel like `return` is very important part of `guard` statement.  
>> > I understand the requirement for consistency with 
>> > properties/closures/functions, but I'll prefer to have some inconsistency 
>> > in language in this case and require `return` for `guard`. And in case 
>> > I'll have to choose all-or-nothig, I'll give -1 for the proposal.  
>> >  
>> > I.e. IMO current `return` in properties and functions is less evil than 
>> > absent of `return` in `guard`.  
>> >  
>> >> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:  
>> >> Here is the draft proposal:  
>> >> https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md
>> >>   
>> >>  
>> >> Did I covered everything case? If you find some mistakes feel free to  
>> >> provide feedback so I can fix the proposal before I submit a PR.  
>> >>  
>> >>  
>> >>  
>> >> --  
>> >> Adrian Zubarev  
>> >> Sent with Airmail  
>> >>  
>> >> Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution  
>> >> (swift-evolution@swift.org ) schrieb:  
>> >>  
>> >>> +1  
>> >>>  
>> >>> L  
>> >>>  
>> >>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution  
>> >>>  wrote:  
>> >>> >  
>> >>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution 
>> >>> >>  wrote:  
>> >>> >>  
>> >>> >> It isn’t a special case because all other single-statement closures 
>> >>> >> in the language work that way. It’s actually inconsistent now.  
>> >>> >  
>> >>> > Computed properties aren’t closures so it’s not inconsistent in that 
>> >>> > sense. But it is inconsistent in that closures are the *only* 
>> >>> > value-returning code blocks that are able to use this sugar. It would 
>> >>> > be nice to see this sugar consistently allowed everywhere in the 
>> >>> > language.  
>> >>> >  
>> >>> >>  
>> >>> >>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution 
>> >>> >>>  wrote:  
>> >>> >>>  
>> >>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution 
>> >>> >>>  wrote:  
>> >>> >>>  
>> >>>  The idea is simple:  
>> >>>   
>> >>>  • Can we make return keyword optional in cases like this?  
>> >>>  • Shouldn’t this behave like @autoclosure or @noescape?  
>> >>>  type A {  
>> >>>  var characters: [Character] = …  
>> >>>  var string: String { String(self.characters) }  
>> >>>  var count: Int { 42 }  
>> >>>  }  
>> >>>   
>> >>>  Is this worth a proposal or Swifty enough, what do you think?  
>> >>>   
>> >>>  Sure I could write return, but why do we allow this behavior for 
>> >>>  @noescape functions like map!?  
>> >>> >>>  
>> >>> >>> While I am not necessarily against this idea, I do wonder if it’s 
>> >>> >>> worth making what’s going on here less obvious simply for the sake 
>> >>> >>> of being able to omit a six character keyword. As I understand it, 
>> >>> >>> one of the reasons ++/-- were removed was due to the increased 
>> >>> >>> "burden to learn Swift as a first programming language.” This is the 
>> >>> >>> sort of thing that becomes another one of those special cases that 
>> >>> >>> has to be explained to someone new to Swift.  
>> >>> >>> 

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Vladimir.S via swift-evolution]

Do we have any 'feature' to not just throw away of proposals(and then scan 
mail list and remember), but put them in queue of proposals that should be 
reviewed after Swift 3 is released?


Probably some list of such proposals on site, don't know. So I believe any 
proposal that would be raised now and got support from community - should 
be added to that queue on some page somewhere on swift.org


On 01.06.2016 20:03, Adrian Zubarev via swift-evolution wrote:

Given that Swift 3 is winding down, we are in a mode of declining PRs
for proposals that don’t align with its goals. Please bring this back
up for discussion this fall, thanks for understanding.

Closed by Chris. Sad but we’ll have to wait a little longer for this change.



--
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 06:58:27, Thorsten Seitz (tseit...@icloud.com
) schrieb:


+1

`return` in guards should stay, because there one has to use either
`return`, `continue` or `break`. It would be ugly and inconsistent if one
of these could be left out.

-Thorsten

> Am 31.05.2016 um 20:16 schrieb Vladimir.S via swift-evolution 
:
>
> I really like the proposal in case of properties and functions, but I really 
don't want to have
> guard boolean else { "false" }
>
> I feel like `return` is very important part of `guard` statement.
> I understand the requirement for consistency with 
properties/closures/functions, but I'll prefer to have some inconsistency in 
language in this case and require `return` for `guard`. And in case I'll have to 
choose all-or-nothig, I'll give -1 for the proposal.
>
> I.e. IMO current `return` in properties and functions is less evil than 
absent of `return` in `guard`.
>
>> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:
>> Here is the draft proposal:
>> 
https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md
>>
>> Did I covered everything case? If you find some mistakes feel free to
>> provide feedback so I can fix the proposal before I submit a PR.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution
>> (swift-evolution@swift.org ) schrieb:
>>
>>> +1
>>>
>>> L
>>>
>>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution
>>>  wrote:
>>> >
>>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution 
 wrote:
>>> >>
>>> >> It isn’t a special case because all other single-statement closures in 
the language work that way. It’s actually inconsistent now.
>>> >
>>> > Computed properties aren’t closures so it’s not inconsistent in that 
sense.  But it is inconsistent in that closures are the *only* value-returning code blocks 
that are able to use this sugar.  It would be nice to see this sugar consistently allowed 
everywhere in the language.
>>> >
>>> >>
>>> >>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution 
 wrote:
>>> >>>
>>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution 
 wrote:
>>> >>>
>>>  The idea is simple:
>>> 
>>>  • Can we make return keyword optional in cases like this?
>>>  • Shouldn’t this behave like @autoclosure or @noescape?
>>>  type A {
>>>    var characters: [Character] = …
>>>    var string: String { String(self.characters) }
>>>    var count: Int { 42 }
>>>  }
>>> 
>>>  Is this worth a proposal or Swifty enough, what do you think?
>>> 
>>>  Sure I could write return, but why do we allow this behavior for 
@noescape functions like map!?
>>> >>>
>>> >>> While I am not necessarily against this idea, I do wonder if it’s worth 
making what’s going on here less obvious simply for the sake of being able to omit a six character 
keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased 
"burden to learn Swift as a first programming language.” This is the sort of thing that becomes 
another one of those special cases that has to be explained to someone new to Swift.
>>> >>>
>>> >>> /brian
>>> >>>
>>> >>> ___
>>> >>> 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
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> 

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

[Vladimir.S via swift-evolution]

> To fix any confusion between these I'd rather change the syntax of the
> conditional let binding to something like `let x ?= x` or similar (which
> has been proposed quite a few times on this list already).

FWIW, I also think `if let one = two` is not descriptive enough about what 
is going here.. `if let one ?= two` or even `if let one = two!` will be 
more clear for me : we are trying to unwrap and assign.


On 01.06.2016 19:46, Thorsten Seitz via swift-evolution wrote:



Am 01.06.2016 um 00:26 schrieb Paul Cantrell via swift-evolution
>:


I certainly am warm to that myself, although I’m also sympathetic to what
Chris wrote about the inconsistency it introduces:

let x = optionalX!, y = optionalY!  // Works!
doStuff(x, y)

if let x = optionalX, y = optionalY {  // Doesn’t work. Confusion!
doStuff(x, y)
}


I don't think that is so confusing. Much more confusing is that the let
binding within the `if` statement is conditional!
So, in essence we are already looking at very different clauses and I'd
actually prefer if the conditional let binding would require explicit `let`
for each binding just to emphasize that a conditional let binding is happening!
To fix any confusion between these I'd rather change the syntax of the
conditional let binding to something like `let x ?= x` or similar (which
has been proposed quite a few times on this list already).
Worsening the syntax of conditionals instead is no option IMHO.

-Thorsten





Also, eliminating the repeated “let” in a big list of conditional
bindings is a common practice:

if let firstName = json["first_name"],
   lastName = json["last_name"],
   street = json["street"],
   state = json["state"],
   zip = json["zip_code"] {
...
}

…and some style guides even go out of their way to recommend this over
the repeated “let.” Popular feature, so I’d be hesitant to nix it.

P


On May 31, 2016, at 5:04 PM, Hooman Mehr > wrote:

Exactly what I feel about this.

I am prepared to go as far as disallowing:

let x = optionalX, y = optionalY

syntax to free up comma for use instead of semicolon. Then the above
becomes:

let x = optionalX, *let* y = optionalY

In this case we will keep the comma at the end of the line as well.



On May 31, 2016, at 2:25 PM, Paul Cantrell via swift-evolution
> wrote:

Returning to the list after a brutally busy spring, a demi-review:

I vote…

+1 on addressing this problem,
+1 on the proposal’s structural approach (list of items which may be
either boolean tests or bindings, in any order), and
+1 on eliminating “where” in the presence of a better approach,

…but am ambivalent about the semicolon. Hereafter follows a slushy
reflection on my deepest inner thoughts and feelings about syntax.

The logic behind the semicolon makes perfect sense, but my initial gut
reaction agrees with others who say it just isn’t pleasant to read. I
spent some time fiddling with places in my code where I’ve used “if …
where” and tried the proposed syntax instead. It feels … off.

Commas in the same spots feel better somehow. I spent some time
reflecting on why this might be, and I think it’s just that my brain is
so strongly trained to parse the semicolon as a statement separator.
IOW, my mental hierarchy is this:

expression
comma
statement
semicolon ←

…(and this is intuitively true for me despite the C-style for loop),
but the proposal asks us to read this way instead:

expression
comma
semicolon ←
statement

In particular, my years of C trained me to spot this mistake:

if(foo < bar);
   oopsThisAlwaysExecutes();

…and seeing that semicolon on the same line as the “if” in Swift
triggers that deeply conditioned alarm bell. Then again, “if let” and
“if case” have always felt weirdly wrong to me as well, and I
eventually got used to them. I’d probably get used to this proposed
syntax as well.

The line breaks look better than semicolons, but suffer a bit from the
same “statement boundary” brain retraining problem.

Somebody proposed && (Brent maybe?). I tried it out too. It’s
surprisingly pleasant to read, but makes it look like I should be able
to arbitrarily embed bindings deep in expressions in ways that would
open hideous cans of worms:

   if let foo = bar && barTest(foo) || let foo = baz && bazTest(foo) {
   // Is foo defined here? What is its type? Yikes!
   }

Communicating that the top-level separator in a condition clause is not
just another boolean operator does seem important.

Bottom line: the proposal addresses a real problem, and the proposed
solution is an improvement. If the choice is either current syntax or
SE-0099, I vote for SE-0099. I have a nagging feeling there’s a better
third choice out there somewhere. If there isn’t, then I’ll take SE-0099.

Cheers,

Paul

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

Given that Swift 3 is winding down, we are in a mode of declining PRs for 
proposals that don’t align with its goals. Please bring this back up for 
discussion this fall, thanks for understanding.
Closed by Chris. Sad but we’ll have to wait a little longer for this change.



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 06:58:27, Thorsten Seitz (tseit...@icloud.com) schrieb:

+1  

`return` in guards should stay, because there one has to use either `return`, 
`continue` or `break`. It would be ugly and inconsistent if one of these could 
be left out.  

-Thorsten  

> Am 31.05.2016 um 20:16 schrieb Vladimir.S via swift-evolution 
> :  
>  
> I really like the proposal in case of properties and functions, but I really 
> don't want to have  
> guard boolean else { "false" }  
>  
> I feel like `return` is very important part of `guard` statement.  
> I understand the requirement for consistency with 
> properties/closures/functions, but I'll prefer to have some inconsistency in 
> language in this case and require `return` for `guard`. And in case I'll have 
> to choose all-or-nothig, I'll give -1 for the proposal.  
>  
> I.e. IMO current `return` in properties and functions is less evil than 
> absent of `return` in `guard`.  
>  
>> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:  
>> Here is the draft proposal:  
>> https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md
>>   
>>  
>> Did I covered everything case? If you find some mistakes feel free to  
>> provide feedback so I can fix the proposal before I submit a PR.  
>>  
>>  
>>  
>> --  
>> Adrian Zubarev  
>> Sent with Airmail  
>>  
>> Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution  
>> (swift-evolution@swift.org ) schrieb:  
>>  
>>> +1  
>>>  
>>> L  
>>>  
>>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution  
>>>  wrote:  
>>> >  
>>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution 
>>> >>  wrote:  
>>> >>  
>>> >> It isn’t a special case because all other single-statement closures in 
>>> >> the language work that way. It’s actually inconsistent now.  
>>> >  
>>> > Computed properties aren’t closures so it’s not inconsistent in that 
>>> > sense. But it is inconsistent in that closures are the *only* 
>>> > value-returning code blocks that are able to use this sugar. It would be 
>>> > nice to see this sugar consistently allowed everywhere in the language.  
>>> >  
>>> >>  
>>> >>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution 
>>> >>>  wrote:  
>>> >>>  
>>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution 
>>> >>>  wrote:  
>>> >>>  
>>>  The idea is simple:  
>>>   
>>>  • Can we make return keyword optional in cases like this?  
>>>  • Shouldn’t this behave like @autoclosure or @noescape?  
>>>  type A {  
>>>  var characters: [Character] = …  
>>>  var string: String { String(self.characters) }  
>>>  var count: Int { 42 }  
>>>  }  
>>>   
>>>  Is this worth a proposal or Swifty enough, what do you think?  
>>>   
>>>  Sure I could write return, but why do we allow this behavior for 
>>>  @noescape functions like map!?  
>>> >>>  
>>> >>> While I am not necessarily against this idea, I do wonder if it’s worth 
>>> >>> making what’s going on here less obvious simply for the sake of being 
>>> >>> able to omit a six character keyword. As I understand it, one of the 
>>> >>> reasons ++/-- were removed was due to the increased "burden to learn 
>>> >>> Swift as a first programming language.” This is the sort of thing that 
>>> >>> becomes another one of those special cases that has to be explained to 
>>> >>> someone new to Swift.  
>>> >>>  
>>> >>> /brian  
>>> >>>  
>>> >>> ___  
>>> >>> 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  
>>> ___  
>>> swift-evolution mailing list  
>>> swift-evolution@swift.org  
>>> https://lists.swift.org/mailman/listinfo/swift-evolution  
>>  
>>  
>>  
>> ___  
>> swift-evolution mailing list  
>> swift-evolution@swift.org  
>> 

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

[Vladimir.S via swift-evolution]

Yes, I also can support the idea of autogenerated type name (like 
Enum_fit_OR_fill) as long as it allows to do all the things we are 
discussing here: declare (.fit|.fill) in function, use .fit on calling 
side, use (.fit|.fill) to declare temporary variable of type compatible 
with such function parameter etc.


But how do you suggest to define a type of such function in `typealias` for 
example? i.e. for func my(option: (.fit|.fill) {..}


typealias MyFunc = ((.fit|.fill)) -> ()

or as

typealias MyFunc = (Enum_fit_OR_fill) -> ()

?

But I still can't support the idea of limiting the usage of such enums - 
i.e. "To deal with milti site definition, the compiler would simply flag a 
error/warning, or be silent in the presence of a new annotation:". I really 
think we need then introduce the same rule for tuples - so no one can use 
the same tuple declaration in function - they then should declare separate 
struct type or use @something for such functions. Nobody wants such rule 
for tuples.


On 01.06.2016 19:04, L. Mihalkovic wrote:

The only problem with this proposal is to consider them ad-hoc enums... If we 
view them as having nothing ad-hoc about them and the thing to be a simple 
sugaring exercise, then I think all the opositions on grounds of breaking the 
language disapear. It still does not mean it should be done if the core team 
does not like the idea of encouraging laziness, or simply do not like what it 
makes them look like. No matter what, this type of sugaring exercise has been 
clearly stated as out of scope for 3.0


On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution 
 wrote:


On 01.06.2016 11:00, Austin Zheng wrote:
Tuples are a structural type, they are described entirely by the fact
that they are a tuple, plus their contained types.

Enum cases are not individual types; that precedent exists nowhere in
Swift. You can't (yet) build a structural type out of something that
isn't a type. The fact that you had to propose something like
"AdhocEnumFitFill_2383748" as an autogenerated name for the type
demonstrates the proposal's weaknesses: a tuple is an ad-hoc type that
describes itself, while an anonymous enum isn't.


Yes, I understand the point about the type of such adhoc enum.
The only workaround I can see in this case(if we'd really want to have it in 
language) if adhoc enum type will be `(.Fit|.Fill)` i.e. textual representation if 
the declared type. As I understand this also could not be a solution.. I.e. for 
example `(Int,String,(.Fit|.Fill))->String`

From other point of view, adding such type to typesystem will add some 
consistence : you can create a function that don't need definition of separate 
structure type(tuple will be used) and don't need separate enum type(ad-hoc 
enum will be used). I.e. all data the function needs to process could be 
described in function definition. Today we need to use ugly Bool flags in case 
we want to achieve the same target.



Now if enum cases were equivalent if they had the same name (like how
"Int" means the same thing no matter what tuple or generic type it is
used in), we'd have a good foundation for a self-describing structural
type. But this isn't how the existing named enum types work. Why would
it be a good idea to make anonymous enum cases interchangeable by name?
Properties on different types aren't interchangeable, even if they have
the same type. In fact, no type member that I am aware of is
interchangeable solely on the basis of name. An "ArtistAction.Draw" and
"CowboyAction.Draw" might have the same name, but they mean completely
different things.


I don't think they should be 'interchangeable by name', but just like tuples if 
you defined adhoc enum with exactly the same cases as ad-hoc enum in function 
parameters - then they are of the same type.

I.e. :

func foo(option: (.fit|.fill)) {..}

foo(.fit) // .fit is of type  (.fit|.fill) from definition

let e : (.fit|.fill) = .fit
foo(e) // e is of (.fit|.fill) type, equal to definition

but

func foo2(option: (.fit|.fill|.other)) {..}

foo2(.fit) // ok, here .fit is of (.fit|.fill|.other) type
foo2(e) --> Error, e is not of type (.fit|.fill|.other)



Finally, I have to ask: if you are updating your anonymous enum in
multiple places, how much effort have you actually saved over a one-line
enum definition? In fact, tuples are a great example of this: best
practices usually state that they are good for ad-hoc destructuring,
such as retrieving multiple return values from a function or pattern
matching across several values at once, but structs are better used for
almost everything else, since they carry semantic meaning that tuples
don't.



Just the same pros and cons for ad-hoc enums vs enum declaration as for tuples 
vs struct declaration. Yes can use it with care and you can use it in wrong way.

Btw, I feel like this could be very handy to return adhoc enum:

func something() -> (.one|.two|.three) {...}


I hope that clarifies my 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
 

 ]

I’m late again to this one, but the discussion’s certainly still going. I’m 
pretty strongly against the bare ‘A & B’ syntax, for a few reasons:

- Swift doesn’t use ‘&’ for anything except bitwise AND. In particular, it 
didn’t get picked for set intersection.

- In theory people are allowed to overload ‘&’ to operate on types. That 
doesn’t make sense for all types, but you could probably come up with a 
particular type hierarchy or use of generics where it does make sense.

- I don’t like types with spaces in them when the spaces aren’t bracketed in 
some way. This is entirely an aesthetic objection, of the form “I don’t 
naturally read that as a type, or even as a single unit, when looking at code.” 
This isn’t a great objection because someone could have said it about `[Int]` 
or `Int?` as well. (It would be a more realistic objection if some of our 
brackets weren’t “<" and “>”.)

And I still support the ‘Any’ syntax, despite the “order doesn’t matter” 
problem:

- It’s consistent with the existing unconstrained ‘Any’ and with the current 
dedicated wrapper types. If we didn’t think it was a good name for those, we 
wouldn’t use it there either.

- It’s easily learnable. It’s rare enough that someone wouldn’t be exposed to 
it right away, like Optional, Array, and Dictionary sugar, but when they do see 
it it’ll be obvious that it’s a type, and probably obvious that it’s special 
because of the “Any”.

- It’s a type; types always start with uppercase letters. (This has been said 
plenty by others.)

None of these are particularly strong arguments, I know, and I don’t have a 
good alternate suggestion. But I did want to go on record as being in favor of 
‘Any’ and against a binary operator, even though that seems to put me in the 
minority.

Jordan



> On May 24, 2016, at 11:06, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0089: Replace protocol syntax with Any" 
> begins now and runs through May 30. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

___
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

[Thorsten Seitz via swift-evolution]

> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution 
> :
> 
> Revisiting this conversation, it seems that most of the design space has been 
> thoroughly explored. I think all suggestions presented so far boil down to 
> these:
> 
> Q: How is an arbitrary boolean assertion introduced after `if let`?
> 
> Option 1 (present scenario)--using `where`
> Advantages: expressive when it means exactly the right thing
> Drawbacks: makes obligatory the suggestion of a semantic relationship between 
> what comes before and after even when there is no such relationship

Haravikk already demonstrated that a semantic relationship always exists in the 
sense of "bind this variable for all caes where the following condition holds".

So, the perceived problem with the `where` clause does not exist.

-Thorsten 


> 
> Option 2--using a symbol sometimes encountered in conditional statements 
> (e.g. `&&` or comma)
> Advantages: doesn't look out of place
> Drawbacks: needs to be disambiguated from existing uses, necessitating other 
> changes in syntax
> 
> Option 3--using a symbol never encountered in conditional statements (e.g. 
> semicolon)
> Advantages: doesn't need to be disambiguated from any existing uses
> Drawbacks: looks out of place
> 
> For me, options 1 and 2 have permanent and objective drawbacks. By contrast, 
> familiarity increases with time, and beauty is in the eye of the beholder.
> 
> * * *
> 
> It does occur to me that there is one more option. I don't know that I like 
> it, but it's an option no one has put forward before: recite the opening 
> keyword when beginning a new boolean expression:
> 
> `if let x = x where x < 3 { ... }` becomes
> `if let x = x if x < 3 { ... }`
> 
> `while let item = sequence.next() where item > 0 { ... }` becomes
> `while let item = sequence.next() while item > 0 { ... }`
> 
> etc.
> 
> 
> On Tue, May 31, 2016 at 2:00 PM, Erica Sadun  wrote:
>> 
>> > 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
___
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

[Thorsten Seitz via swift-evolution]

> Am 01.06.2016 um 00:26 schrieb Paul Cantrell via swift-evolution 
> :
> 
> I certainly am warm to that myself, although I’m also sympathetic to what 
> Chris wrote about the inconsistency it introduces:
> 
> let x = optionalX!, y = optionalY!  // Works!
> doStuff(x, y)
> 
> if let x = optionalX, y = optionalY {  // Doesn’t work. Confusion!
> doStuff(x, y)
> }

I don't think that is so confusing. Much more confusing is that the let binding 
within the `if` statement is conditional!
So, in essence we are already looking at very different clauses and I'd 
actually prefer if the conditional let binding would require explicit `let` for 
each binding just to emphasize that a conditional let binding is happening!
To fix any confusion between these I'd rather change the syntax of the 
conditional let binding to something like `let x ?= x` or similar (which has 
been proposed quite a few times on this list already).
Worsening the syntax of conditionals instead is no option IMHO.

-Thorsten 



> 
> Also, eliminating the repeated “let” in a big list of conditional bindings is 
> a common practice:
> 
> if let firstName = json["first_name"],
>lastName = json["last_name"],
>street = json["street"],
>state = json["state"],
>zip = json["zip_code"] {
> ...   
> }
> 
> …and some style guides even go out of their way to recommend this over the 
> repeated “let.” Popular feature, so I’d be hesitant to nix it.
> 
> P
> 
>> On May 31, 2016, at 5:04 PM, Hooman Mehr  wrote:
>> 
>> Exactly what I feel about this. 
>> 
>> I am prepared to go as far as disallowing:
>> 
>> let x = optionalX, y = optionalY 
>> 
>> syntax to free up comma for use instead of semicolon. Then the above becomes:
>> 
>> let x = optionalX, let y = optionalY
>> 
>> In this case we will keep the comma at the end of the line as well.
>> 
>> 
>>> On May 31, 2016, at 2:25 PM, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>>> Returning to the list after a brutally busy spring, a demi-review:
>>> 
>>> I vote…
>>> 
>>> +1 on addressing this problem,
>>> +1 on the proposal’s structural approach (list of items which may be either 
>>> boolean tests or bindings, in any order), and
>>> +1 on eliminating “where” in the presence of a better approach,
>>> 
>>> …but am ambivalent about the semicolon. Hereafter follows a slushy 
>>> reflection on my deepest inner thoughts and feelings about syntax.
>>> 
>>> The logic behind the semicolon makes perfect sense, but my initial gut 
>>> reaction agrees with others who say it just isn’t pleasant to read. I spent 
>>> some time fiddling with places in my code where I’ve used “if … where” and 
>>> tried the proposed syntax instead. It feels … off.
>>> 
>>> Commas in the same spots feel better somehow. I spent some time reflecting 
>>> on why this might be, and I think it’s just that my brain is so strongly 
>>> trained to parse the semicolon as a statement separator. IOW, my mental 
>>> hierarchy is this:
>>> 
>>> expression
>>> comma
>>> statement
>>> semicolon ←
>>> 
>>> …(and this is intuitively true for me despite the C-style for loop), but 
>>> the proposal asks us to read this way instead:
>>> 
>>> expression
>>> comma
>>> semicolon ←
>>> statement
>>> 
>>> In particular, my years of C trained me to spot this mistake:
>>> 
>>> if(foo < bar);
>>> oopsThisAlwaysExecutes();
>>> 
>>> …and seeing that semicolon on the same line as the “if” in Swift triggers 
>>> that deeply conditioned alarm bell. Then again, “if let” and “if case” have 
>>> always felt weirdly wrong to me as well, and I eventually got used to them. 
>>> I’d probably get used to this proposed syntax as well.
>>> 
>>> The line breaks look better than semicolons, but suffer a bit from the same 
>>> “statement boundary” brain retraining problem.
>>> 
>>> Somebody proposed && (Brent maybe?). I tried it out too. It’s surprisingly 
>>> pleasant to read, but makes it look like I should be able to arbitrarily 
>>> embed bindings deep in expressions in ways that would open hideous cans of 
>>> worms:
>>> 
>>>if let foo = bar && barTest(foo) || let foo = baz && bazTest(foo) {
>>>// Is foo defined here? What is its type? Yikes!
>>>}
>>> 
>>> Communicating that the top-level separator in a condition clause is not 
>>> just another boolean operator does seem important.
>>> 
>>> Bottom line: the proposal addresses a real problem, and the proposed 
>>> solution is an improvement. If the choice is either current syntax or 
>>> SE-0099, I vote for SE-0099. I have a nagging feeling there’s a better 
>>> third choice out there somewhere. If there isn’t, then I’ll take SE-0099.
>>> 
>>> Cheers,
>>> 
>>> Paul
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> 

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

[Thorsten Seitz via swift-evolution]

> Am 31.05.2016 um 23:01 schrieb Haravikk via swift-evolution 
> :
> 
> 
>> On 31 May 2016, at 18:57, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> * 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?
> 
> Personally I’m not sure that where should need to be constrained, in fact one 
> of the examples given as “incorrect” is arguably not so:
> 
>   if let foo = x where y < z { … }
> 
> In this case y < z doesn’t appear strictly related to the optional binding, 
> but it may still be a condition of it, in essence it’s saying “bind foo if 
> this is true”.

This is a very good point!! I totally agree with that!

-Thorsten 



> This is interesting because the compiler is actually free to evaluate y < z 
> first, and only perform the binding afterwards. Actually this is also true in 
> the following case:
> 
>   if let foo = x where foo > 5 { … }
> 
> To evaluate foo > 5 the compiler doesn’t actually need to unwrap x, it just 
> needs to know if x is .Some, in which case it can compare the value and only 
> if the comparison succeeds actually copy it into a variable and continue.
> 
> Of course statements separated by semi-colons can be reordered behind the 
> scenes if the compiler wants to do-so, so long as the logic doesn’t change, 
> but I find that where reads better with that implication in mind. It reads 
> visually like “bind this if this test is true” rather than “bind this, then 
> test this”.
> 
> Plus it just looks nicer (to me); sometimes aesthetics are important, and the 
> majority of cases don’t need the complexity of lots of conditionals that need 
> separating, sometimes a pattern and a condition, or a binding and a condition 
> is enough, and the where clause has this covered, and keeps these forms of 
> conditional visually distinct. Much more complex cases will benefit from 
> semi-colons, which in turn will make them visually distinct too, even if a 
> lot of the building blocks are the same.
> 
> Put another way, I tend to think of pattern matching, conditional binding and 
> regular logic as three completely different forms of conditional (I suppose 
> they are in fact at present), the separators as proposed will let you mix and 
> match these cleanly, which has the potential for some overlap sure, but I 
> think developers can be left to resolve that for themselves by choosing 
> whether to group a conditional with where, or separate it.
> 
> 
> Anyway, it doesn’t really matter overall, as the addition of 
> semi-colons/new-lines as separators isn’t dependent upon the removal of where 
> clauses, so they can be removed later if it’s deemed useful. In fact, doing 
> it this way would be a better way to do it as it gives us a period in which 
> both features will be available, and we can just wait and see what people 
> actually use. If where clauses are ignored in favour of 
> semi-colons/new-lines, then at this point it will be trivial to replace them, 
> as you can non-destructively remove the feature by simply swapping the where 
> keyword from these types of conditionals for a semi-colon, or provide a fixit 
> to do this, as functionally they will be identical.
> ___
> 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] Variadic generics discussion

[Austin Zheng via swift-evolution]

This is good to know, thanks for the clarification!

Austin

> On Jun 1, 2016, at 9:38 AM, Joe Groff  wrote:
> 
> A regular value is a 1-tuple of itself. In the type system, we know what 
> abstraction level a value expects to work at. It shouldn't be a problem for a 
> variadic type parameter to be bound to 0, 1, or more types.
> 
> -Joe

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

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

[Austin Zheng via swift-evolution]

> On Jun 1, 2016, at 8:58 AM, L. Mihalkovic  
> wrote:
> 
> 
> 
>> On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>>> On 01.06.2016 11:00, Austin Zheng wrote:
>>> Tuples are a structural type, they are described entirely by the fact
>>> that they are a tuple, plus their contained types.
>>> 
>>> Enum cases are not individual types; that precedent exists nowhere in
>>> Swift. You can't (yet) build a structural type out of something that
>>> isn't a type. The fact that you had to propose something like
>>> "AdhocEnumFitFill_2383748" as an autogenerated name for the type
>>> demonstrates the proposal's weaknesses:
> 
> Vehemently disagree! The problem is only to think that the name must be 
> random: It CAN ABSOLUTELY NOT be random in order to respect the semantic of a 
> nominal type. Once you accept that, then this is just a very simple and 
> clever syntax sugaring for enum declarations.

My point isn't that the name is random, it's that you need an autogenerated 
name to begin with, and that it shouldn't be compared to a tuple because (like 
you said) it's a nominal type (albeit one that you don't directly name).

That being said, I completely agree with you that this is just language sugar 
around some types that the compiler synthesizes for you. It's sugar I consider 
a largely useless addition to the language, but there is nothing technical 
stopping it from being implemented.

> 
> See my other response for more details
> 

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

Re: [swift-evolution] Variadic generics discussion

[Joe Groff via swift-evolution]

> On Jun 1, 2016, at 9:35 AM, Austin Zheng  wrote:
> 
> 
>> On Jun 1, 2016, at 6:18 AM, Joe Groff  wrote:
>> 
>> 
>>> On May 31, 2016, at 6:49 PM, Austin Zheng  wrote:
>>> 
>>> I agree that this is a better design for Swift than the monstrosity I 
>>> started out with.
>>> 
>>> The "biggest" technical challenge I see is being able to type a reduction 
>>> sort of operator on a heterogenous tuple based on on whatever protocols and 
>>> constraints are common to its constituent members. For example:
>>> 
>>> // Every Tn in T... is Fooable and Barrable
>>> let x : (T...)
>>> reduce(x, reducer, startingValue)
>>> 
>>> func reducer(startingValue: U, eachMemberOfT: X) -> U { ... }
>>> 
>>> How do we bound ??? such that 'reducer' is useful while still being 
>>> statically type sound? Honestly, that's the most interesting question to 
>>> me. Generalized existentials might help with that.
>> 
>> If every T is Fooable and Barrable, couldn't `eachMemberOfT` be (inout U, 
>> protocol) -> ()?
> 
> I feel like I might be overthinking this. The tightest sound bound is 
> protocol (or , and the 
> loosest bound is Any (or ), but it would be good to have a notion of 
> ordering other bounds so that functions with more lenient bounds for which 
> all the requirements are satisfied by the tuple members (e.g. 
> protocol, not protocol) are admitted. This would 
> become more complex with associated types and constraints thereof, where 
> ordering doesn't just mean "at least some of the protocols the variadic 
> parameter type bounds are required to conform to, but not any new ones".
> 
>> 
>>> Other questions (inherent to any proposal) would be:
>>> 
>>> - How do we resolve the impedance mismatch between tuples and function 
>>> argument lists? Is it even worth trying to resolve this mismatch, given 
>>> that argument lists are intentionally not intended to mirror tuples?
>> 
>> The impedance mismatch between function arguments and tuples is superficial. 
>> You ought to be able to splat and bind tuples into function arguments, e.g.:
>> 
>>  let args = (1, 2)
>>  foo(bar:bas:)(args...)
>> 
>>  func variadicFn(_ args: T...) { ... }
> 
> I agree, I was thinking more of things like inout and default parameters. But 
> that splat/bind notation should be enough for the majority of use cases.
> 
>> 
>>> - As you said, how do variadic generics work in the 0- and 1-member cases?
>> 
>> What problem are you referring to?
>> 
> 
> How does a type with zero type parameters work? I guess all the variadic 
> tuples in question could just be the empty tuple.
> 
> Would there be tuple operations that work on variadic tuples which would 
> break down in the 1-ple case (where the item isn't a tuple anymore, but a 
> regular value)?

A regular value is a 1-tuple of itself. In the type system, we know what 
abstraction level a value expects to work at. It shouldn't be a problem for a 
variadic type parameter to be bound to 0, 1, or more types.

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

Re: [swift-evolution] Variadic generics discussion

[Austin Zheng via swift-evolution]

> On Jun 1, 2016, at 6:18 AM, Joe Groff  wrote:
> 
> 
>> On May 31, 2016, at 6:49 PM, Austin Zheng  wrote:
>> 
>> I agree that this is a better design for Swift than the monstrosity I 
>> started out with.
>> 
>> The "biggest" technical challenge I see is being able to type a reduction 
>> sort of operator on a heterogenous tuple based on on whatever protocols and 
>> constraints are common to its constituent members. For example:
>> 
>> // Every Tn in T... is Fooable and Barrable
>> let x : (T...)
>> reduce(x, reducer, startingValue)
>> 
>> func reducer(startingValue: U, eachMemberOfT: X) -> U { ... }
>> 
>> How do we bound ??? such that 'reducer' is useful while still being 
>> statically type sound? Honestly, that's the most interesting question to me. 
>> Generalized existentials might help with that.
> 
> If every T is Fooable and Barrable, couldn't `eachMemberOfT` be (inout U, 
> protocol) -> ()?

I feel like I might be overthinking this. The tightest sound bound is 
protocol (or , and the 
loosest bound is Any (or ), but it would be good to have a notion of 
ordering other bounds so that functions with more lenient bounds for which all 
the requirements are satisfied by the tuple members (e.g. protocol, 
not protocol) are admitted. This would become more complex with 
associated types and constraints thereof, where ordering doesn't just mean "at 
least some of the protocols the variadic parameter type bounds are required to 
conform to, but not any new ones".

> 
>> Other questions (inherent to any proposal) would be:
>> 
>> - How do we resolve the impedance mismatch between tuples and function 
>> argument lists? Is it even worth trying to resolve this mismatch, given that 
>> argument lists are intentionally not intended to mirror tuples?
> 
> The impedance mismatch between function arguments and tuples is superficial. 
> You ought to be able to splat and bind tuples into function arguments, e.g.:
> 
>   let args = (1, 2)
>   foo(bar:bas:)(args...)
> 
>   func variadicFn(_ args: T...) { ... }

I agree, I was thinking more of things like inout and default parameters. But 
that splat/bind notation should be enough for the majority of use cases.

> 
>> - As you said, how do variadic generics work in the 0- and 1-member cases?
> 
> What problem are you referring to?
> 

How does a type with zero type parameters work? I guess all the variadic tuples 
in question could just be the empty tuple.

Would there be tuple operations that work on variadic tuples which would break 
down in the 1-ple case (where the item isn't a tuple anymore, but a regular 
value)?

As Brent mentioned, having base cases for the 0 and 1-arity cases defines this 
problem away. so it's not really a big deal.

> -Joe
> 

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

Re: [swift-evolution] [swift-users] UnsafeMutablePointer vs. UnsafeMutablePointer

[Adrian Zubarev via swift-evolution]

So basically if my application terminates without errors or crashes I can be 
sure that the OS will free any memory it used.

Now I feel safe using UnsafeMutablePointers in swift :)



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 18:19:01, Austin Zheng (austinzh...@gmail.com) schrieb:

This shouldn't be something you need to worry about. The mechanism the OS uses 
to handle memory per process is different from the mechanism your process uses 
to allocate memory, and the OS should reclaim all the memory that your app used 
(whether it was 'leaked' or not).

More info: 
http://stackoverflow.com/questions/2975831/is-leaked-memory-freed-up-when-the-program-exits

Best,
Austin

On Jun 1, 2016, at 9:13 AM, Adrian Zubarev via swift-users 
 wrote:

I’ve got one more question that bothers me.

Lets say I’ve got a class that might look something like this:

class Reference {
  
var pointer: UnsafeMutablePointer
  
init(integer: Int) {
self.pointer = UnsafeMutablePointer.alloc(1)
self.pointer.initialize(integer)
}
  
deinit {
self.pointer.destroy(1)
self.pointer.dealloc(1)
}
}
Let talk about ARC here. If I use optionals here and release manually the 
reference deinit will be called and we’re happy here:

var reference: Reference? = Reference(integer: 123456789)
reference = nil
If I don’t use optionals because I want my value to exist while the application 
is running, deinit will never be called but my application terminates just fine 
(SIGKILL?):

let reference = Reference(integer: 123456789)
Doesn’t this create a memory leak?

How do I solve this problem, especially if don’t know whats inside the 
Reference type (assume I’m a different developer who only has access to the 
framework but not its implementation)?




-- 
Adrian Zubarev
Sent with Airmail

Am 23. Mai 2016 um 18:31:43, Jordan Rose (jordan_r...@apple.com) schrieb:


On May 21, 2016, at 01:48, Adrian Zubarev via swift-users 
 wrote:

I played around with UnsafeMutablePointer and realized one behavior:

let pString = UnsafeMutablePointer.alloc(1)
pString.initialize("test")
pString.predecessor().memory // will crash ax expected
pString.predecessor() == pString.advancedBy(-1) // true
pString.destroy()
pString.dealloc(1)

where

let iInt = UnsafeMutablePointer.alloc(1)
iInt.initialize("test")
iInt.predecessor().memory // will not crash
iInt.predecessor() == iInt.advancedBy(-1) // true
iInt.predecessor().memory = 42 // did I just modified some memory I don't own?
iInt.destroy()
iInt.dealloc(1)

Is this intended? This is really the case where its unsafe.


Dmitri’s answers are all better for this specific discussion, but in general, 
“unsafe” in Swift means “if you don’t follow the rules, this may crash, may 
silently corrupt memory or do other bad things, may cause other code to be 
optimized out or miscompiled, may be harmless”. In this particular case, it’d 
be hard to check for the validity of the pointer while also being fast and 
binary-compatible with C.

Jordan


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

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

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

[Vladimir.S via swift-evolution]

This will not print the name of case :

enum E: CustomStringConvertible {
case one, two

var description: String {return "haha"}
}

print(E.one)

So, for me, it seems like the good idea to have a standard(and built-in) 
way to convert string<->case i.e. to have


let e = E(caseName: "one")!
and
let s = e.caseName // always the same as defined in enum type


On 01.06.2016 18:47, Leonardo Pessoa via swift-evolution wrote:

Paul, in all my tests for this thread printing the enum value only
produced the enum value's name ("Mars" in your example). The proposal
of having a .caseName (or should it better be .caseValue to cover
enums with associated values? any other suggestions?) will prevent
that changes to this behaviour crash apps in the future as this should
always produce the same result even if the string representation
changes.

L

On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution
 wrote:

IIRC, string interpolation prepends the module name if the enum belongs to a 
module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of 
compiler crashes, at least in the past.

Those two factors forced me into this ugliness: 
https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115

A clean, documented, supported way of exposing the enum case name that the 
runtime clearly already has available seems sensible — and should be 
independent of the raw type.

Cheers, P


On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution 
 wrote:

This is, however, kind of a hack IMHO that relies on the compiler behavior that 
isn't well documented.

For example, this:

enum Planet {
  case Earth
  case Mars
}

"\(Planet.Mars)" // This is "Mars"


Works as well. You don't need to have the represented value to be String.

Note that this:

- works both when you have a plain enum, or enum Planet: Int, or whatever raw 
value kind
- does not work (!) when declared as @objc - then the result is "Planet".


On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution 
 wrote:

I had no idea you could do this!!


On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type 
:help for assistance.
1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, 
uranus, neptune }
2> Planet.mercury.rawValue
$R0: String = "mercury"


___
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

___
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] Ad hoc enums / options

[L. Mihalkovic via swift-evolution]

The only problem with this proposal is to consider them ad-hoc enums... If we 
view them as having nothing ad-hoc about them and the thing to be a simple 
sugaring exercise, then I think all the opositions on grounds of breaking the 
language disapear. It still does not mean it should be done if the core team 
does not like the idea of encouraging laziness, or simply do not like what it 
makes them look like. No matter what, this type of sugaring exercise has been 
clearly stated as out of scope for 3.0

> On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
>> On 01.06.2016 11:00, Austin Zheng wrote:
>> Tuples are a structural type, they are described entirely by the fact
>> that they are a tuple, plus their contained types.
>> 
>> Enum cases are not individual types; that precedent exists nowhere in
>> Swift. You can't (yet) build a structural type out of something that
>> isn't a type. The fact that you had to propose something like
>> "AdhocEnumFitFill_2383748" as an autogenerated name for the type
>> demonstrates the proposal's weaknesses: a tuple is an ad-hoc type that
>> describes itself, while an anonymous enum isn't.
> 
> Yes, I understand the point about the type of such adhoc enum.
> The only workaround I can see in this case(if we'd really want to have it in 
> language) if adhoc enum type will be `(.Fit|.Fill)` i.e. textual 
> representation if the declared type. As I understand this also could not be a 
> solution.. I.e. for example `(Int,String,(.Fit|.Fill))->String`
> 
> From other point of view, adding such type to typesystem will add some 
> consistence : you can create a function that don't need definition of 
> separate structure type(tuple will be used) and don't need separate enum 
> type(ad-hoc enum will be used). I.e. all data the function needs to process 
> could be described in function definition. Today we need to use ugly Bool 
> flags in case we want to achieve the same target.
> 
>> 
>> Now if enum cases were equivalent if they had the same name (like how
>> "Int" means the same thing no matter what tuple or generic type it is
>> used in), we'd have a good foundation for a self-describing structural
>> type. But this isn't how the existing named enum types work. Why would
>> it be a good idea to make anonymous enum cases interchangeable by name?
>> Properties on different types aren't interchangeable, even if they have
>> the same type. In fact, no type member that I am aware of is
>> interchangeable solely on the basis of name. An "ArtistAction.Draw" and
>> "CowboyAction.Draw" might have the same name, but they mean completely
>> different things.
> 
> I don't think they should be 'interchangeable by name', but just like tuples 
> if you defined adhoc enum with exactly the same cases as ad-hoc enum in 
> function parameters - then they are of the same type.
> 
> I.e. :
> 
> func foo(option: (.fit|.fill)) {..}
> 
> foo(.fit) // .fit is of type  (.fit|.fill) from definition
> 
> let e : (.fit|.fill) = .fit
> foo(e) // e is of (.fit|.fill) type, equal to definition
> 
> but
> 
> func foo2(option: (.fit|.fill|.other)) {..}
> 
> foo2(.fit) // ok, here .fit is of (.fit|.fill|.other) type
> foo2(e) --> Error, e is not of type (.fit|.fill|.other)
> 
>> 
>> Finally, I have to ask: if you are updating your anonymous enum in
>> multiple places, how much effort have you actually saved over a one-line
>> enum definition? In fact, tuples are a great example of this: best
>> practices usually state that they are good for ad-hoc destructuring,
>> such as retrieving multiple return values from a function or pattern
>> matching across several values at once, but structs are better used for
>> almost everything else, since they carry semantic meaning that tuples
>> don't.
>> 
> 
> Just the same pros and cons for ad-hoc enums vs enum declaration as for 
> tuples vs struct declaration. Yes can use it with care and you can use it in 
> wrong way.
> 
> Btw, I feel like this could be very handy to return adhoc enum:
> 
> func something() -> (.one|.two|.three) {...}
> 
>> I hope that clarifies my thoughts on the matter.
>> 
>> Best, Austin
>> 
>> 
>>> On Jun 1, 2016, at 12:36 AM, Vladimir.S  wrote:
>>> 
>>> On 01.06.2016 9:55, Austin Zheng via swift-evolution wrote:
 Maybe it's overkill. My personal opinion is that breaking the
 symmetry of the language like this (are there any other types of
 function arguments that cannot be passed as either variable values
 or literals?) is too much a price to pay. Your library thinks it's
 being clever and vends its functions as taking anonymous enum flags,
 and now there are a bunch of things I can't do with those functions
 anymore.
 
 A regular enum can be declared in one line anyways:
 
 enum ScaleCropMode { case Fit, Fill }
>>> 
>>> Why do we have tuples? Struct could be defined by one line `struct
>>> SomeValue { var x = 0, y = 0 }` ;-) I.e. from 

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

[L. Mihalkovic via swift-evolution]

> On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
>> On 01.06.2016 11:00, Austin Zheng wrote:
>> Tuples are a structural type, they are described entirely by the fact
>> that they are a tuple, plus their contained types.
>> 
>> Enum cases are not individual types; that precedent exists nowhere in
>> Swift. You can't (yet) build a structural type out of something that
>> isn't a type. The fact that you had to propose something like
>> "AdhocEnumFitFill_2383748" as an autogenerated name for the type
>> demonstrates the proposal's weaknesses:

Vehemently disagree! The problem is only to think that the name must be random: 
It CAN ABSOLUTELY NOT be random in order to respect the semantic of a nominal 
type. Once you accept that, then this is just a very simple and clever syntax 
sugaring for enum declarations.

See my other response for more details

>> a tuple is an ad-hoc type that
>> describes itself, while an anonymous enum isn't.
> 
> Yes, I understand the point about the type of such adhoc enum.
> The only workaround I can see in this case(if we'd really want to have it in 
> language) if adhoc enum type will be `(.Fit|.Fill)` i.e. textual 
> representation if the declared type. As I understand this also could not be a 
> solution.. I.e. for example `(Int,String,(.Fit|.Fill))->String`
> 
> From other point of view, adding such type to typesystem will add some 
> consistence : you can create a function that don't need definition of 
> separate structure type(tuple will be used) and don't need separate enum 
> type(ad-hoc enum will be used). I.e. all data the function needs to process 
> could be described in function definition. Today we need to use ugly Bool 
> flags in case we want to achieve the same target.
> 
>> 
>> Now if enum cases were equivalent if they had the same name (like how
>> "Int" means the same thing no matter what tuple or generic type it is
>> used in), we'd have a good foundation for a self-describing structural
>> type. But this isn't how the existing named enum types work. Why would
>> it be a good idea to make anonymous enum cases interchangeable by name?
>> Properties on different types aren't interchangeable, even if they have
>> the same type. In fact, no type member that I am aware of is
>> interchangeable solely on the basis of name. An "ArtistAction.Draw" and
>> "CowboyAction.Draw" might have the same name, but they mean completely
>> different things.
> 
> I don't think they should be 'interchangeable by name', but just like tuples 
> if you defined adhoc enum with exactly the same cases as ad-hoc enum in 
> function parameters - then they are of the same type.
> 
> I.e. :
> 
> func foo(option: (.fit|.fill)) {..}
> 
> foo(.fit) // .fit is of type  (.fit|.fill) from definition
> 
> let e : (.fit|.fill) = .fit
> foo(e) // e is of (.fit|.fill) type, equal to definition
> 
> but
> 
> func foo2(option: (.fit|.fill|.other)) {..}
> 
> foo2(.fit) // ok, here .fit is of (.fit|.fill|.other) type
> foo2(e) --> Error, e is not of type (.fit|.fill|.other)
> 
>> 
>> Finally, I have to ask: if you are updating your anonymous enum in
>> multiple places, how much effort have you actually saved over a one-line
>> enum definition? In fact, tuples are a great example of this: best
>> practices usually state that they are good for ad-hoc destructuring,
>> such as retrieving multiple return values from a function or pattern
>> matching across several values at once, but structs are better used for
>> almost everything else, since they carry semantic meaning that tuples
>> don't.
>> 
> 
> Just the same pros and cons for ad-hoc enums vs enum declaration as for 
> tuples vs struct declaration. Yes can use it with care and you can use it in 
> wrong way.
> 
> Btw, I feel like this could be very handy to return adhoc enum:
> 
> func something() -> (.one|.two|.three) {...}
> 
>> I hope that clarifies my thoughts on the matter.
>> 
>> Best, Austin
>> 
>> 
>>> On Jun 1, 2016, at 12:36 AM, Vladimir.S  wrote:
>>> 
>>> On 01.06.2016 9:55, Austin Zheng via swift-evolution wrote:
 Maybe it's overkill. My personal opinion is that breaking the
 symmetry of the language like this (are there any other types of
 function arguments that cannot be passed as either variable values
 or literals?) is too much a price to pay. Your library thinks it's
 being clever and vends its functions as taking anonymous enum flags,
 and now there are a bunch of things I can't do with those functions
 anymore.
 
 A regular enum can be declared in one line anyways:
 
 enum ScaleCropMode { case Fit, Fill }
>>> 
>>> Why do we have tuples? Struct could be defined by one line `struct
>>> SomeValue { var x = 0, y = 0 }` ;-) I.e. from my point of view
>>> developer should decide what he/she wants to use: ad-hoc enum or
>>> defined enum type *exactly* as now he/she can decide to use the same
>>> tuples in multiply functions 

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

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Leonardo Pessoa via swift-evolution]

I'm not much fond of Java enums but then Java also doesn't have
structs so I think enums there were created to be a mix of structs and
enums and that's why you can do all the things you mention on your
list. That said:
- The tuple typed enum approach is the closest thing we discussed to
constructors like the ones in Java enums;
- I never knew one could do that in Java but I think tuples can hold
function types;
- I also never heard one can do that in Java but I begin to think what
you really want are structs here;
- Both approaches here provide that, but accessors would allow for
dynamic content to be generated, not static.

Also Swift already allow for functions to be declared in enums and I
think this would be a better place than accessor properties to place
code that will generate dynamic results.

L

On 1 June 2016 at 11:59, Matthew Johnson via swift-evolution
 wrote:
>
>
> Sent from my iPad
>
>> On Jun 1, 2016, at 9:48 AM, David Waite via swift-evolution 
>>  wrote:
>>
>> One thing I did often in Java (and miss in Swift) is using their enums to 
>> build state machines or implement command patterns for common commands.
>>
>> Java enums are a sealed set of subclasses of the enum base type with 
>> (hopefully) immutable, singleton instances. So you can do fun things like:
>> - Define the base class constructor to be called to instantiate the 
>> subclasses, and declare the cases with the constructor arguments
>> - Declare a method on the base type and refine it on 1-2 particular cases
>> - Declare the enum implements an interface, and implement that interface 
>> separately for each case.
>> - Define data accessors specific to the type (such as the planets example 
>> above)
>>
>> I like the SuitInfo approach below - with extensions, I think I can get 
>> close to what I have done in the past with Java. Maybe one day there is 
>> syntax to do this in the language directly
>
> This is pretty similar to what we were discussing last week in this thread: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018799.html
>
> I'm planning to write up a proposal when I have time (hopefully in the next 
> week or so).
>
>>
>> -DW
>>
>>> On May 31, 2016, at 11:44 AM, Vladimir.S via swift-evolution 
>>>  wrote:
>>>
>>> I'm not sure about my opinion on this proposal, but I believe you should 
>>> add this as alternatives of how we can have the similar features today 
>>> without injecting stored properties into enums  :
>>>
>>> enum Suit {
>>>   case spades
>>>   case hearts
>>>   case diamonds
>>>   case clubs
>>>
>>>   struct SuitInfo {
>>>   let simpleDescription: String
>>>   let color: UIColor
>>>   let symbol: String
>>>   let bezierPath: UIBezierPath
>>>   }
>>>
>>>   var info : SuitInfo {
>>>   switch self {
>>>   case .spades:
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "spades",
>>>   color: .blackColor(),
>>>   symbol: "♠",
>>>   bezierPath: path)
>>>
>>>   case .hearts:
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "hearts",
>>>   color: .redColor(),
>>>   symbol: "♥",
>>>   bezierPath: path)
>>>
>>>   case .diamonds:
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "diamonds",
>>>   color: .redColor(),
>>>   symbol: "♦",
>>>   bezierPath: path)
>>>
>>>   case .clubs:
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "clubs",
>>>   color: .blackColor(),
>>>   symbol: "♣",
>>>   bezierPath: path)
>>>
>>>   }
>>>   }
>>> }
>>>
>>> and this:
>>>
>>> enum Suit  {
>>>   case spades
>>>   case hearts
>>>   case diamonds
>>>   case clubs
>>>
>>>   struct SuitInfo  {
>>>   let simpleDescription: String
>>>   let color: UIColor
>>>   let symbol: String
>>>   let bezierPath: UIBezierPath
>>>   }
>>>
>>>   static let spadesInfo : SuitInfo = {
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "spades",
>>>   color: .blackColor(),
>>>   symbol: "♠",
>>>   bezierPath: path)
>>>   }()
>>>
>>>   static let heartsInfo : SuitInfo = {
>>>   let path = UIBezierPath()
>>>   // omitted lines ...
>>>
>>>   return SuitInfo(
>>>   simpleDescription: "hearts",
>>>   color: .redColor(),
>>>   symbol: "♥",
>>>   bezierPath: path)
>>>   }()
>>>
>>>   static let diamondsInfo : SuitInfo = {
>>>   

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Paul Cantrell via swift-evolution]

> On Jun 1, 2016, at 9:48 AM, David Waite via swift-evolution 
>  wrote:
> 
> One thing I did often in Java (and miss in Swift) is using their enums to 
> build state machines or implement command patterns for common commands.
> 
> Java enums are a sealed set of subclasses of the enum base type with 
> (hopefully) immutable, singleton instances. So you can do fun things like:
> - Define the base class constructor to be called to instantiate the 
> subclasses, and declare the cases with the constructor arguments
> - Declare a method on the base type and refine it on 1-2 particular cases
> - Declare the enum implements an interface, and implement that interface 
> separately for each case.
> - Define data accessors specific to the type (such as the planets example 
> above)

+1 to this behavior — one of the increasingly rare places where Java is nicer 
than Swift. This is the natural generalization / next step of the stored 
properties of this thread, and I can confirm what David said: it’s useful in 
practice.

P

___
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] Working with enums by name

[Paul Cantrell via swift-evolution]

IIRC, string interpolation prepends the module name if the enum belongs to a 
module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of 
compiler crashes, at least in the past.

Those two factors forced me into this ugliness: 
https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115

A clean, documented, supported way of exposing the enum case name that the 
runtime clearly already has available seems sensible — and should be 
independent of the raw type.

Cheers, P

> On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> This is, however, kind of a hack IMHO that relies on the compiler behavior 
> that isn't well documented.
> 
> For example, this:
> 
> enum Planet {
>   case Earth
>   case Mars
> }
> 
> "\(Planet.Mars)" // This is "Mars"
> 
> 
> Works as well. You don't need to have the represented value to be String.
> 
> Note that this:
> 
> - works both when you have a plain enum, or enum Planet: Int, or whatever raw 
> value kind
> - does not work (!) when declared as @objc - then the result is "Planet".
> 
>> On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution 
>>  wrote:
>> 
>> I had no idea you could do this!!
>> 
>>> On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> Who said anything about repeating the name?
>>> 
>>> Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). 
>>> Type :help for assistance.
>>> 1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, 
>>> uranus, neptune }
>>> 2> Planet.mercury.rawValue
>>> $R0: String = "mercury"
>> 
>> ___
>> 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] [Proposal] Enums with static stored properties for each case

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 1, 2016, at 9:48 AM, David Waite via swift-evolution 
>  wrote:
> 
> One thing I did often in Java (and miss in Swift) is using their enums to 
> build state machines or implement command patterns for common commands.
> 
> Java enums are a sealed set of subclasses of the enum base type with 
> (hopefully) immutable, singleton instances. So you can do fun things like:
> - Define the base class constructor to be called to instantiate the 
> subclasses, and declare the cases with the constructor arguments
> - Declare a method on the base type and refine it on 1-2 particular cases
> - Declare the enum implements an interface, and implement that interface 
> separately for each case.
> - Define data accessors specific to the type (such as the planets example 
> above)
> 
> I like the SuitInfo approach below - with extensions, I think I can get close 
> to what I have done in the past with Java. Maybe one day there is syntax to 
> do this in the language directly

This is pretty similar to what we were discussing last week in this thread: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018799.html

I'm planning to write up a proposal when I have time (hopefully in the next 
week or so).

> 
> -DW
> 
>> On May 31, 2016, at 11:44 AM, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>> I'm not sure about my opinion on this proposal, but I believe you should add 
>> this as alternatives of how we can have the similar features today without 
>> injecting stored properties into enums  :
>> 
>> enum Suit {
>>   case spades
>>   case hearts
>>   case diamonds
>>   case clubs
>> 
>>   struct SuitInfo {
>>   let simpleDescription: String
>>   let color: UIColor
>>   let symbol: String
>>   let bezierPath: UIBezierPath
>>   }
>> 
>>   var info : SuitInfo {
>>   switch self {
>>   case .spades:
>>   let path = UIBezierPath()
>>   // omitted lines ...
>> 
>>   return SuitInfo(
>>   simpleDescription: "spades",
>>   color: .blackColor(),
>>   symbol: "♠",
>>   bezierPath: path)
>> 
>>   case .hearts:
>>   let path = UIBezierPath()
>>   // omitted lines ...
>> 
>>   return SuitInfo(
>>   simpleDescription: "hearts",
>>   color: .redColor(),
>>   symbol: "♥",
>>   bezierPath: path)
>> 
>>   case .diamonds:
>>   let path = UIBezierPath()
>>   // omitted lines ...
>> 
>>   return SuitInfo(
>>   simpleDescription: "diamonds",
>>   color: .redColor(),
>>   symbol: "♦",
>>   bezierPath: path)
>> 
>>   case .clubs:
>>   let path = UIBezierPath()
>>   // omitted lines ...
>> 
>>   return SuitInfo(
>>   simpleDescription: "clubs",
>>   color: .blackColor(),
>>   symbol: "♣",
>>   bezierPath: path)
>> 
>>   }
>>   }
>> }
>> 
>> and this:
>> 
>> enum Suit  {
>>   case spades
>>   case hearts
>>   case diamonds
>>   case clubs
>> 
>>   struct SuitInfo  {
>>   let simpleDescription: String
>>   let color: UIColor
>>   let symbol: String
>>   let bezierPath: UIBezierPath
>>   }
>> 
>>   static let spadesInfo : SuitInfo = {
>>   let path = UIBezierPath()
>>   // omitted lines ...
>> 
>>   return SuitInfo(
>>   simpleDescription: "spades",
>>   color: .blackColor(),
>>   symbol: "♠",
>>   bezierPath: path)
>>   }()
>> 
>>   static let heartsInfo : SuitInfo = {
>>   let path = UIBezierPath()
>>   // omitted lines ...
>> 
>>   return SuitInfo(
>>   simpleDescription: "hearts",
>>   color: .redColor(),
>>   symbol: "♥",
>>   bezierPath: path)
>>   }()
>> 
>>   static let diamondsInfo : SuitInfo = {
>>   let path = UIBezierPath()
>>   // omitted lines ...
>> 
>>   return SuitInfo(
>>   simpleDescription: "diamonds",
>>   color: .redColor(),
>>   symbol: "♦",
>>   bezierPath: path)
>>   }()
>> 
>>   static let clubsInfo : SuitInfo = {
>>   let path = UIBezierPath()
>>   // omitted lines ...
>> 
>>   return SuitInfo(
>>   simpleDescription: "clubs",
>>   color: .blackColor(),
>>   symbol: "♣",
>>   bezierPath: path)
>>   }()
>> 
>> 
>>   var info : SuitInfo {
>>   switch self {
>>   case .spades: return Suit.spadesInfo
>>   case .hearts: return Suit.heartsInfo
>>   case .diamonds: return Suit.diamondsInfo
>>   case .clubs: return Suit.clubsInfo
>>   }
>>   }
>> }
>> 
>> 
>>> On 31.05.2016 17:17, Jānis Kiršteins via swift-evolution wrote:
>>> I wrote a proposal draft:
>>> 
>>> # Enum case stored properties
>>> 
>>> * Proposal: TBD
>>> * Author: [Janis Kirsteins](https://github.com/kirsteins)
>>> 

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[David Waite via swift-evolution]

One thing I did often in Java (and miss in Swift) is using their enums to build 
state machines or implement command patterns for common commands.

Java enums are a sealed set of subclasses of the enum base type with 
(hopefully) immutable, singleton instances. So you can do fun things like:
- Define the base class constructor to be called to instantiate the subclasses, 
and declare the cases with the constructor arguments
- Declare a method on the base type and refine it on 1-2 particular cases
- Declare the enum implements an interface, and implement that interface 
separately for each case.
- Define data accessors specific to the type (such as the planets example above)

I like the SuitInfo approach below - with extensions, I think I can get close 
to what I have done in the past with Java. Maybe one day there is syntax to do 
this in the language directly

-DW

> On May 31, 2016, at 11:44 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> I'm not sure about my opinion on this proposal, but I believe you should add 
> this as alternatives of how we can have the similar features today without 
> injecting stored properties into enums  :
> 
> enum Suit {
>case spades
>case hearts
>case diamonds
>case clubs
> 
>struct SuitInfo {
>let simpleDescription: String
>let color: UIColor
>let symbol: String
>let bezierPath: UIBezierPath
>}
> 
>var info : SuitInfo {
>switch self {
>case .spades:
>let path = UIBezierPath()
>// omitted lines ...
> 
>return SuitInfo(
>simpleDescription: "spades",
>color: .blackColor(),
>symbol: "♠",
>bezierPath: path)
> 
>case .hearts:
>let path = UIBezierPath()
>// omitted lines ...
> 
>return SuitInfo(
>simpleDescription: "hearts",
>color: .redColor(),
>symbol: "♥",
>bezierPath: path)
> 
>case .diamonds:
>let path = UIBezierPath()
>// omitted lines ...
> 
>return SuitInfo(
>simpleDescription: "diamonds",
>color: .redColor(),
>symbol: "♦",
>bezierPath: path)
> 
>case .clubs:
>let path = UIBezierPath()
>// omitted lines ...
> 
>return SuitInfo(
>simpleDescription: "clubs",
>color: .blackColor(),
>symbol: "♣",
>bezierPath: path)
> 
>}
>}
> }
> 
> and this:
> 
> enum Suit  {
>case spades
>case hearts
>case diamonds
>case clubs
> 
>struct SuitInfo  {
>let simpleDescription: String
>let color: UIColor
>let symbol: String
>let bezierPath: UIBezierPath
>}
> 
>static let spadesInfo : SuitInfo = {
>let path = UIBezierPath()
>// omitted lines ...
> 
>return SuitInfo(
>simpleDescription: "spades",
>color: .blackColor(),
>symbol: "♠",
>bezierPath: path)
>}()
> 
>static let heartsInfo : SuitInfo = {
>let path = UIBezierPath()
>// omitted lines ...
> 
>return SuitInfo(
>simpleDescription: "hearts",
>color: .redColor(),
>symbol: "♥",
>bezierPath: path)
>}()
> 
>static let diamondsInfo : SuitInfo = {
>let path = UIBezierPath()
>// omitted lines ...
> 
>return SuitInfo(
>simpleDescription: "diamonds",
>color: .redColor(),
>symbol: "♦",
>bezierPath: path)
>}()
> 
>static let clubsInfo : SuitInfo = {
>let path = UIBezierPath()
>// omitted lines ...
> 
>return SuitInfo(
>simpleDescription: "clubs",
>color: .blackColor(),
>symbol: "♣",
>bezierPath: path)
>}()
> 
> 
>var info : SuitInfo {
>switch self {
>case .spades: return Suit.spadesInfo
>case .hearts: return Suit.heartsInfo
>case .diamonds: return Suit.diamondsInfo
>case .clubs: return Suit.clubsInfo
>}
>}
> }
> 
> 
> On 31.05.2016 17:17, Jānis Kiršteins via swift-evolution wrote:
>> I wrote a proposal draft:
>> 
>> # Enum case stored properties
>> 
>> * Proposal: TBD
>> * Author: [Janis Kirsteins](https://github.com/kirsteins)
>> * Status: TBD
>> * Review manager: TBD
>> 
>> ## Introduction
>> 
>> This proposal allows each enum case to have stored properties.
>> 
>> ## Motivation
>> 
>> Enums cases can have a lot of constant (or variable) static values
>> associated with it. For example, planets can have mass, radius, age,
>> closest star etc. Currently there is no way to set or get those values
>> easily.
>> 
>> Example below shows that is hard to read and manage static associated

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

[David Waite via swift-evolution]

Not for or against a change in shorthand/defaulted names in general, but 
leading-dot in particular.

Leading dot already means something (access a static property/method of the 
expected type, including enum types). This usage has nothing to do with that 
existing behavior of the syntax other than being terse. Reusing syntax for 
wildly different behavior is also a recipe for confusion.

In addition, the dot syntax may make people think they are acting on a member 
of a type or tuple, while that is not currently the underlying behavior.

-DW

> On May 30, 2016, at 12:44 PM, Frédéric Blondiau via swift-evolution 
>  wrote:
> 
> Hello,
> 
> I was thinking about this, and would like to get some feedback before making 
> my first proposal.
> 
> Best regards,
> 
> 
> Fred.
> ---
> 
> Shorthand Argument Renaming
> 
> 
> Introduction
> 
> Swift automatically provides shorthand argument names to inline closures 
> which cleverly allows us to write
> 
>reversed = names.sort( { $0 > $1 } )
> 
> I would suggest to use another syntax, using these new “names”
> 
>reversed = names.sort( { .0 > .1 } )
> 
> 
> Motivation
> 
> The $n notation is generally used with positional parameters using one-based 
> numbering, $1 referring to argument 1; $2, to argument 2... with a special 
> meaning for $0 (could be the name of the function, or the full list of 
> parameters).
> 
> This $n notation is often handy, but feels strange in Swift... like imported 
> from UNIX scripting (but here zero-based, anyway).
> 
> 
> Proposed solution
> 
> The .n notation is more Swift-like — as used to access Tuple members, for 
> example.
> 
> 
> Detailed design
> 
> Today, .0 or .1 (as any .n's) are refused by the compiler, as being not valid 
> floating point literals.
> 
> I’m not a compiler expert, but eventually fetching this error inside a 
> closure body could easily be translated into accepting this new syntax.
> 
> There can’t be conflict with other shorthands (like accessing static members 
> using dot notation) as members can’t consist of only digits characters.
> 
> 
> Impact on existing code
> 
> $n need to be rewritten .n
> 
> 
> Alternatives considered
> 
> Create a default argument named “arguments” (like “error” in catch, 
> “newValue” in setters or “oldValue” in a a didSet observer) accessed like a 
> Tuple
> 
>reversed = names.sort( { arguments.0 > arguments.1 } )
> 
> but this is (of course) much less convenient.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Patrick Smith via swift-evolution]

Lots of people have added their 2¢ now, you probably have about 10 dollars 
worth, but here goes.

While it looks nice and short, I think it has a range of drawbacks:
- It’s not a real type that can participate in protocols or extensions.
- Discourages DRY coding, because some people will think they are taking the 
easy way out, and even copy and paste this same declaration multiple times.
- Encourages adding subtypes to functions instead of types. Swift seems 
primarily type-focused more than function-focused. I remember seeing someone 
write their solution as an extension to UIImage, which was a nice way to do it. 
This subtype would be best conceptually as UIImage.FitOperation (use with 
multiple methods!) not scaleAndCropImage.Operation (use once!)

The beauty of Swift is that you can add methods to value types. This opens up 
interesting, more reusable solutions such as:


enum ContentFit {
  case fit
  case fill
  
  func adjust(size contentSize: CGSize, within bounds: CGRect) -> CGRect {
let (widthFactor, heightFactor) = (bounds.size.width / contentSize.width, 
bounds.size.height / contentSize.height)
let scaleFactor: CGFloat
switch self {
case .fit: scaleFactor = min(widthFactor, heightFactor)
case .fill: scaleFactor = max(widthFactor, heightFactor)
}

let adjustedSize = CGSize(width: contentSize.width * scaleFactor, height: 
contentSize.height * scaleFactor)
let adjustedOrigin = CGPoint(x: (bounds.size.width - adjustedSize.width) / 
2.0, y: (bounds.size.height - adjustedSize.height) / 2.0)
return CGRect(origin: adjustedOrigin, size: adjustedSize)
  }
}


That way you break functions up into smaller chunks, while also making the 
types more useful in themselves.

(For context, Erica’s original post is here: 
http://ericasadun.com/2016/05/31/swift-rewrite-challenge/ 
)

Patrick

> On 1 Jun 2016, at 2:16 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 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

___
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

[Patrick Smith via swift-evolution]

I’ve always had a funny feeling about the `where` keyword in `if` statements. 
It feels like it adds structure, but it’s not the most flexible of keywords. I 
sometimes find myself writing to match the structure it wants rather than the 
other way around. I rather like this proposal.

What if `where` could be used to constrain the unwrapping of the optional 
rather than being an independent boolean expression? You could possibly use it 
normally outside of `if` like so:

let a: Optional = "hello"

…

let b = a where a?.count > 4  // .some(“hello”)
let c = a where a?.count > 10  // .none


That way when used in an `if` statement, the `where` is actually part of the 
optional unwrap rather than a separate sibling.

if let x = x where x < 3 {
  …
}

So people keep their ability to group related things together, with the simple 
elegance of this proposal. Just an idea, and I’m sure it can be improved.


Another idea is a .filter() method added to Optional.

if let x = x.filter({ $0 < 3 }) {
  …
}


Patrick


> On 1 Jun 2016, at 8:38 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 1 Jun 2016, at 02:47, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> Q: How is an arbitrary boolean assertion introduced after `if let`?
>> 
>> Option 1 (present scenario)--using `where`
>> Advantages: expressive when it means exactly the right thing
>> Drawbacks: makes obligatory the suggestion of a semantic relationship 
>> between what comes before and after even when there is no such relationship
> 
> Like I said a little earlier, this drawback is not strictly true. No matter 
> how unrelated to the binding a where clause may seemingly be, the binding is 
> still dependent upon it; i.e- no value is bound if the condition fails, so 
> regardless of what the condition is actually testing for it is very much 
> related to the binding, like-so:
> 
>   if let value = foo where somethingUnrelatedIsTrue() { … }
> 
> The variable named “value” doesn’t exist outside of this condition if 
> somethingUnrelatedIsTrue() fails, so I’d say there is still very much a 
> relationship between these two things. A lot of the time you probably do want 
> to test the unwrapped value, but it’s not a requirement for the condition to 
> be related, because one cannot succeed without the other.
> 
>> Option 3--using a symbol never encountered in conditional statements (e.g. 
>> semicolon)
>> Advantages: doesn't need to be disambiguated from any existing uses
>> Drawbacks: looks out of place
> 
> How out of place does it really look? It’s no different from semi-colons for 
> separating statements in code, and if where remains supported you’ll only 
> need to use it in a handful of cases anyway (much like semi-colons for 
> statement separation).
> 
>> It does occur to me that there is one more option. I don't know that I like 
>> it, but it's an option no one has put forward before: recite the opening 
>> keyword when beginning a new boolean expression:
>> 
>> `if let x = x where x < 3 { ... }` becomes
>> `if let x = x if x < 3 { ... }`
>> 
>> `while let item = sequence.next() where item > 0 { ... }` becomes
>> `while let item = sequence.next() while item > 0 { ... }`
> 
> I’m not sure what the difference is here; it doesn’t seem to have any 
> capability that where doesn’t, surely it’s just changing the name of the 
> keyword or is the point to have the full range of capabilities on both sides 
> of the keyword? This could be done with where just as easily, no need for 
> renaming, like so:
> 
>   if let value = foo where case .Some(let value2) = bar { … }
> 
> Bad example I know, but I don’t use pattern matching much. This currently 
> doesn’t compile, but where could be extended to include all conditional 
> types, so you could chain it to do pattern matching, conditional binding and 
> a conditional all in one, is that the kind of thing you mean?
> ___
> 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] Variadic generics discussion

[Matthew Johnson via swift-evolution]

> On Jun 1, 2016, at 8:29 AM, Joe Groff  wrote:
> 
>> 
>> On Jun 1, 2016, at 6:26 AM, Matthew Johnson  wrote:
>> 
>>> 
>>> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
 
 On May 31, 2016, at 6:49 PM, Austin Zheng  wrote:
 
 I agree that this is a better design for Swift than the monstrosity I 
 started out with.
 
 The "biggest" technical challenge I see is being able to type a reduction 
 sort of operator on a heterogenous tuple based on on whatever protocols 
 and constraints are common to its constituent members. For example:
 
 // Every Tn in T... is Fooable and Barrable
 let x : (T...)
 reduce(x, reducer, startingValue)
 
 func reducer(startingValue: U, eachMemberOfT: X) -> U { ... }
 
 How do we bound ??? such that 'reducer' is useful while still being 
 statically type sound? Honestly, that's the most interesting question to 
 me. Generalized existentials might help with that.
>>> 
>>> If every T is Fooable and Barrable, couldn't `eachMemberOfT` be (inout U, 
>>> protocol) -> ()?
>>> 
 Other questions (inherent to any proposal) would be:
 
 - How do we resolve the impedance mismatch between tuples and function 
 argument lists? Is it even worth trying to resolve this mismatch, given 
 that argument lists are intentionally not intended to mirror tuples?
>>> 
>>> The impedance mismatch between function arguments and tuples is 
>>> superficial. You ought to be able to splat and bind tuples into function 
>>> arguments, e.g.:
>>> 
>>> let args = (1, 2)
>>> foo(bar:bas:)(args...)
>>> 
>>> func variadicFn(_ args: T...) { … }
>> 
>> Going this direction is relatively straightforward.  The impedance mismatch 
>> is trickier when you want to do more than that.  For example, it would be 
>> extremely useful to come up with some way to wrap a function that has 
>> parameters with default arguments without requiring callers of the wrapped 
>> function to supply arguments for the defaulted parameters.  Any ideas on how 
>> to solve that?
> 
> As Chris noted, that sounds like a great use case for a macro. Trying to do 
> that with the type system feels like it's on the wrong side of the complexity 
> threshold to me.

Makes sense.  Looking forward to having macros someday… :)

> 
> -Joe
> 
>>> 
 - As you said, how do variadic generics work in the 0- and 1-member cases?
>>> 
>>> What problem are you referring to?
>>> 
>>> -Joe
>>> 
>>> ___
>>> 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] Variadic generics discussion

[Brent Royal-Gordon via swift-evolution]

> Perhaps inout params of type T could be somehow passed as a pair (T, (T) -> 
> ()), where the first item is the input value and the second item is a 
> writeback function representing the 'out' part of inout.

The simplest solution, I think, is to require the entire splatted tuple to be 
`inout` if any of the parameters it's being splatted into are `inout`. This 
doesn't give you the same granularity as the original, but I don't see that as 
a serious problem.

> I've no ideas for default values.

Ignoring the defaults is not a terrible solution. Leaving that aside, we could 
match the tuple against the parameter list, figure out (from positions and 
types) which parameters are missing, and fill in their default values. Or we 
could punt this to the overload selection layer, and make it so that writing, 
say, `print(_:)` implicitly creates a closure which always uses the default 
values for the `separator` and `terminator` parameters.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Variadic generics discussion

[Joe Groff via swift-evolution]

> On Jun 1, 2016, at 6:26 AM, Matthew Johnson  wrote:
> 
>> 
>> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On May 31, 2016, at 6:49 PM, Austin Zheng  wrote:
>>> 
>>> I agree that this is a better design for Swift than the monstrosity I 
>>> started out with.
>>> 
>>> The "biggest" technical challenge I see is being able to type a reduction 
>>> sort of operator on a heterogenous tuple based on on whatever protocols and 
>>> constraints are common to its constituent members. For example:
>>> 
>>> // Every Tn in T... is Fooable and Barrable
>>> let x : (T...)
>>> reduce(x, reducer, startingValue)
>>> 
>>> func reducer(startingValue: U, eachMemberOfT: X) -> U { ... }
>>> 
>>> How do we bound ??? such that 'reducer' is useful while still being 
>>> statically type sound? Honestly, that's the most interesting question to 
>>> me. Generalized existentials might help with that.
>> 
>> If every T is Fooable and Barrable, couldn't `eachMemberOfT` be (inout U, 
>> protocol) -> ()?
>> 
>>> Other questions (inherent to any proposal) would be:
>>> 
>>> - How do we resolve the impedance mismatch between tuples and function 
>>> argument lists? Is it even worth trying to resolve this mismatch, given 
>>> that argument lists are intentionally not intended to mirror tuples?
>> 
>> The impedance mismatch between function arguments and tuples is superficial. 
>> You ought to be able to splat and bind tuples into function arguments, e.g.:
>> 
>>  let args = (1, 2)
>>  foo(bar:bas:)(args...)
>> 
>>  func variadicFn(_ args: T...) { … }
> 
> Going this direction is relatively straightforward.  The impedance mismatch 
> is trickier when you want to do more than that.  For example, it would be 
> extremely useful to come up with some way to wrap a function that has 
> parameters with default arguments without requiring callers of the wrapped 
> function to supply arguments for the defaulted parameters.  Any ideas on how 
> to solve that?

As Chris noted, that sounds like a great use case for a macro. Trying to do 
that with the type system feels like it's on the wrong side of the complexity 
threshold to me.

-Joe

>> 
>>> - As you said, how do variadic generics work in the 0- and 1-member cases?
>> 
>> What problem are you referring to?
>> 
>> -Joe
>> 
>> ___
>> 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] Variadic generics discussion

[Matthew Johnson via swift-evolution]

> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On May 31, 2016, at 6:49 PM, Austin Zheng  wrote:
>> 
>> I agree that this is a better design for Swift than the monstrosity I 
>> started out with.
>> 
>> The "biggest" technical challenge I see is being able to type a reduction 
>> sort of operator on a heterogenous tuple based on on whatever protocols and 
>> constraints are common to its constituent members. For example:
>> 
>> // Every Tn in T... is Fooable and Barrable
>> let x : (T...)
>> reduce(x, reducer, startingValue)
>> 
>> func reducer(startingValue: U, eachMemberOfT: X) -> U { ... }
>> 
>> How do we bound ??? such that 'reducer' is useful while still being 
>> statically type sound? Honestly, that's the most interesting question to me. 
>> Generalized existentials might help with that.
> 
> If every T is Fooable and Barrable, couldn't `eachMemberOfT` be (inout U, 
> protocol) -> ()?
> 
>> Other questions (inherent to any proposal) would be:
>> 
>> - How do we resolve the impedance mismatch between tuples and function 
>> argument lists? Is it even worth trying to resolve this mismatch, given that 
>> argument lists are intentionally not intended to mirror tuples?
> 
> The impedance mismatch between function arguments and tuples is superficial. 
> You ought to be able to splat and bind tuples into function arguments, e.g.:
> 
>   let args = (1, 2)
>   foo(bar:bas:)(args...)
> 
>   func variadicFn(_ args: T...) { … }

Going this direction is relatively straightforward.  The impedance mismatch is 
trickier when you want to do more than that.  For example, it would be 
extremely useful to come up with some way to wrap a function that has 
parameters with default arguments without requiring callers of the wrapped 
function to supply arguments for the defaulted parameters.  Any ideas on how to 
solve that?

> 
>> - As you said, how do variadic generics work in the 0- and 1-member cases?
> 
> What problem are you referring to?
> 
> -Joe
> 
> ___
> 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] Variadic generics discussion

[Joe Groff via swift-evolution]

> On May 31, 2016, at 6:49 PM, Austin Zheng  wrote:
> 
> I agree that this is a better design for Swift than the monstrosity I started 
> out with.
> 
> The "biggest" technical challenge I see is being able to type a reduction 
> sort of operator on a heterogenous tuple based on on whatever protocols and 
> constraints are common to its constituent members. For example:
> 
> // Every Tn in T... is Fooable and Barrable
> let x : (T...)
> reduce(x, reducer, startingValue)
> 
> func reducer(startingValue: U, eachMemberOfT: X) -> U { ... }
> 
> How do we bound ??? such that 'reducer' is useful while still being 
> statically type sound? Honestly, that's the most interesting question to me. 
> Generalized existentials might help with that.

If every T is Fooable and Barrable, couldn't `eachMemberOfT` be (inout U, 
protocol) -> ()?

> Other questions (inherent to any proposal) would be:
> 
> - How do we resolve the impedance mismatch between tuples and function 
> argument lists? Is it even worth trying to resolve this mismatch, given that 
> argument lists are intentionally not intended to mirror tuples?

The impedance mismatch between function arguments and tuples is superficial. 
You ought to be able to splat and bind tuples into function arguments, e.g.:

let args = (1, 2)
foo(bar:bas:)(args...)

func variadicFn(_ args: T...) { ... }

> - As you said, how do variadic generics work in the 0- and 1-member cases?

What problem are you referring to?

-Joe

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

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

[Dany St-Amant via swift-evolution]

> Le 1 juin 2016 à 02:55, Austin Zheng via swift-evolution 
>  a écrit :
> 
> Maybe it's overkill. My personal opinion is that breaking the symmetry of the 
> language like this (are there any other types of function arguments that 
> cannot be passed as either variable values or literals?) is too much a price 
> to pay. Your library thinks it's being clever and vends its functions as 
> taking anonymous enum flags, and now there are a bunch of things I can't do 
> with those functions anymore.

'inout' doesn't accept literal, function-like compiler directive cannot use 
variables. So both variables and literals are not always both accepted; not 
sure though if it can be used as a precedent for this ad-hoc enum.

Dany

> A regular enum can be declared in one line anyways:
> 
> enum ScaleCropMode { case Fit, Fill }
> 
> Austin 
> 
>> On May 31, 2016, at 11:44 PM, Charles Constant  
>> wrote:
>> 
>> >  It breaks the ability to pass in a variable containing the desired value, 
>> > rather than the literal value itself.
>> 
>> Maybe that's appropriate? If the caller is not passing in a hardcoded enum 
>> case, then that enum is probably general enough that it warrants a normal 
>> enum. But there are also situations where the same function is called from 
>> several files in the same code-base with different flags. Those are 
>> situations where it feels like overkill to clutter up my codebase with 
>> separate enums, only used by a single function. 
>> 
>> 
>> 
>> 
>> 
>>> On Tue, May 31, 2016 at 9:24 PM, Austin Zheng via swift-evolution 
>>>  wrote:
>>> I admire the desire of this proposal to increase the readability of code. 
>>> I'm -1 to the proposal itself, though:
>>> 
>>> - It breaks the ability to pass in a variable containing the desired value, 
>>> rather than the literal value itself. (Unless you actually want a 
>>> not-so-anonymous enum type whose definition happens to live in a function 
>>> signature rather than somewhere you'd usually expect a type definition to 
>>> live.)
>>> - It breaks the ability to store a reference to the function in a variable 
>>> of function type (ditto).
>>> - Almost every time I've wanted to use one of these "anonymous enums" in my 
>>> code, I've ended up needing to use that same enum elsewhere. In my 
>>> experience, 'lightweight enums' don't end up saving much time compared to a 
>>> full-fledged one.
>>> 
>>> Like Brent said, I have to say no to any proposal that tries to make enums 
>>> synonyms for numerical values. What happens if you rearrange your anonymous 
>>> enum cases between library versions? Do you somehow store an opaque 
>>> case-to-UInt8 table somewhere for every anonymous enum you define for 
>>> resilience? What happens when people start bringing back terrible C 
>>> patterns, like doing arithmetic or bitwise ops on the underlying case 
>>> values? At least you have to try pretty hard as it is to abuse Swift's 
>>> enums.
>>> 
>>> Austin
>>> 
 On Tue, May 31, 2016 at 8:25 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 > 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.
 
 If I wanted a language like that, I'd be writing C, not Swift.
 
 --
 Brent Royal-Gordon
 Architechies
 
 ___
 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
___
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

[Christopher Kornher via swift-evolution]

Apologies for going off that tangent earlier.

> On May 31, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Revisiting this conversation, it seems that most of the design space has been 
> thoroughly explored. I think all suggestions presented so far boil down to 
> these:
> 
> Q: How is an arbitrary boolean assertion introduced after `if let`?

Perhaps it is better to think in terms of starting  with the boolean expression 
and then figure out where the case conditions and let clauses should fit-in.

Starting with the simplest form: 

if  

add that it can be preceded by a single let clause:

if let  where  

where  the comma separated list of assignments following a let

finishing up adding cases:

if let  where  case 

In this final form,   '’,  'let  where’,  and 
case  are all optional. One has to exist, of course.

This standardizes the form in a sensible way, I think. So: a single ‘let’ and a 
single ‘case” are allowed, in the position shown.

An example:

'if let a=a, b=b, where (x==3 && y=x) || (x==2 && y!-=x) {…}'


> Option 1 (present scenario)--using `where`
> Advantages: expressive when it means exactly the right thing
> Drawbacks: makes obligatory the suggestion of a semantic relationship between 
> what comes before and after even when there is no such relationship
> 
> Option 2--using a symbol sometimes encountered in conditional statements 
> (e.g. `&&` or comma)
> Advantages: doesn't look out of place
> Drawbacks: needs to be disambiguated from existing uses, necessitating other 
> changes in syntax
> 
> Option 3--using a symbol never encountered in conditional statements (e.g. 
> semicolon)
> Advantages: doesn't need to be disambiguated from any existing uses
> Drawbacks: looks out of place

and it is equivalent to `&&` 

`if let a=a; x==3; y==4`

is equivalent to

`if let a=a; x==3 && y==4`


> 
> For me, options 1 and 2 have permanent and objective drawbacks. By contrast, 
> familiarity increases with time, and beauty is in the eye of the beholder.
> 
> * * *
> 
> It does occur to me that there is one more option. I don't know that I like 
> it, but it's an option no one has put forward before: recite the opening 
> keyword when beginning a new boolean expression:
> 
> `if let x = x where x < 3 { ... }` becomes
> `if let x = x if x < 3 { ... }`
> 
> `while let item = sequence.next() where item > 0 { ... }` becomes
> `while let item = sequence.next() while item > 0 { ... }`
> 
> etc.
> 
> 
> On Tue, May 31, 2016 at 2:00 PM, Erica Sadun  > wrote:
> 
> > 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

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

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

[Vladimir.S via swift-evolution]

On 01.06.2016 11:00, Austin Zheng wrote:

Tuples are a structural type, they are described entirely by the fact
that they are a tuple, plus their contained types.

Enum cases are not individual types; that precedent exists nowhere in
Swift. You can't (yet) build a structural type out of something that
isn't a type. The fact that you had to propose something like
"AdhocEnumFitFill_2383748" as an autogenerated name for the type
demonstrates the proposal's weaknesses: a tuple is an ad-hoc type that
describes itself, while an anonymous enum isn't.


Yes, I understand the point about the type of such adhoc enum.
The only workaround I can see in this case(if we'd really want to have it 
in language) if adhoc enum type will be `(.Fit|.Fill)` i.e. textual 
representation if the declared type. As I understand this also could not be 
a solution.. I.e. for example `(Int,String,(.Fit|.Fill))->String`


From other point of view, adding such type to typesystem will add some 
consistence : you can create a function that don't need definition of 
separate structure type(tuple will be used) and don't need separate enum 
type(ad-hoc enum will be used). I.e. all data the function needs to process 
could be described in function definition. Today we need to use ugly Bool 
flags in case we want to achieve the same target.




Now if enum cases were equivalent if they had the same name (like how
"Int" means the same thing no matter what tuple or generic type it is
used in), we'd have a good foundation for a self-describing structural
type. But this isn't how the existing named enum types work. Why would
it be a good idea to make anonymous enum cases interchangeable by name?
Properties on different types aren't interchangeable, even if they have
the same type. In fact, no type member that I am aware of is
interchangeable solely on the basis of name. An "ArtistAction.Draw" and
"CowboyAction.Draw" might have the same name, but they mean completely
different things.


I don't think they should be 'interchangeable by name', but just like 
tuples if you defined adhoc enum with exactly the same cases as ad-hoc enum 
in function parameters - then they are of the same type.


I.e. :

func foo(option: (.fit|.fill)) {..}

foo(.fit) // .fit is of type  (.fit|.fill) from definition

let e : (.fit|.fill) = .fit
foo(e) // e is of (.fit|.fill) type, equal to definition

but

func foo2(option: (.fit|.fill|.other)) {..}

foo2(.fit) // ok, here .fit is of (.fit|.fill|.other) type
foo2(e) --> Error, e is not of type (.fit|.fill|.other)



Finally, I have to ask: if you are updating your anonymous enum in
multiple places, how much effort have you actually saved over a one-line
enum definition? In fact, tuples are a great example of this: best
practices usually state that they are good for ad-hoc destructuring,
such as retrieving multiple return values from a function or pattern
matching across several values at once, but structs are better used for
almost everything else, since they carry semantic meaning that tuples
don't.



Just the same pros and cons for ad-hoc enums vs enum declaration as for 
tuples vs struct declaration. Yes can use it with care and you can use it 
in wrong way.


Btw, I feel like this could be very handy to return adhoc enum:

func something() -> (.one|.two|.three) {...}


I hope that clarifies my thoughts on the matter.

Best, Austin



On Jun 1, 2016, at 12:36 AM, Vladimir.S  wrote:

On 01.06.2016 9:55, Austin Zheng via swift-evolution wrote:

Maybe it's overkill. My personal opinion is that breaking the
symmetry of the language like this (are there any other types of
function arguments that cannot be passed as either variable values
or literals?) is too much a price to pay. Your library thinks it's
being clever and vends its functions as taking anonymous enum flags,
and now there are a bunch of things I can't do with those functions
anymore.

A regular enum can be declared in one line anyways:

enum ScaleCropMode { case Fit, Fill }


Why do we have tuples? Struct could be defined by one line `struct
SomeValue { var x = 0, y = 0 }` ;-) I.e. from my point of view
developer should decide what he/she wants to use: ad-hoc enum or
defined enum type *exactly* as now he/she can decide to use the same
tuples in multiply functions instead of one defined struct type.

I replied regarding the variable on other message. (In short: I think
of the same principle as for tuples: you can declare variable `let e:
(.fill | .fit) = .fill` and use it)



Austin


On May 31, 2016, at 11:44 PM, Charles Constant
> wrote:


It breaks the ability to pass in a variable containing the
desired

value, rather than the literal value itself.

Maybe that's appropriate? If the caller is not passing in a
hardcoded enum case, then that enum is probably general enough
that it warrants a normal enum. But there are also situations
where the same function is called from several files in 

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

[Haravikk via swift-evolution]

> On 1 Jun 2016, at 12:35, Leonardo Pessoa  wrote:
> 
> Unions have been discussed earlier in this group and I personally
> think this is an issue better solved using function overloading.

Sorry, my intention wasn’t to debate them, I was just using them as an example 
of a specialised ad-hoc enum where compatibility isn’t an issue (because a 
union of the same types means the same thing everywhere you use it, which isn’t 
the case for general ad-hoc enums).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution