Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Charles Constant via swift-evolution]

Oops. Kindly disregard my previous emails. Ben was kind enough to point out
to me that I was confusing dictionary literals with DictionaryLiteral

On Tue, Jan 9, 2018 at 8:56 PM, Ben Cohen <> wrote:

> Hi Charles,
>
> The naming issue strikes again :)
>
> Your code is making use of dictionary literals, not DictionaryLiteral. We
> are talking about the (clearly confusingly named!) DictionaryLiteral type,
> which is a type you can create from a dictionary literal. (See docs here:
> https://developer.apple.com/documentation/swift/dictionaryliteral)
>
> There’s no suggestion of getting rid of the ExpressibleByDictionaryLiteral
> capability.
>
> “Ceci n’est pas une literal”
>  - Magritte
>
> On Jan 9, 2018, at 8:26 PM, Charles Constant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Nevin (et al)
>
> Here's the relevant section of my code. It's from a protocol I use called
> "ParameterSet" to extend OptionSets to contain small numbers (like an Enum
> with an associated type, but all the data is stored in the UInt). Wouldn't
> be my first choice to share, as it breaks KISS. Anyhow, the "
> ExpressibleByDictionaryLiteral" lets me specify a "params" template
> tersely. I only found out how to use the -Literal initializers last year. I
> love them.
>
> struct DrumNote: ParameterSet {
> let rawValue: UInt
>
> static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
> "reverse" ]
>
> static let
> velocity = param(0),
> flam = param(1),
> roll = param(2),
> reverse = param(3),
>
> // ...
>
> }
>
> enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral
> {
> public init( dictionaryLiteral elements: (String,Any)... ) {
> if let pair = elements.first as? (String,ClosedRange) {
> self = .doub(pair.0,pair.1) }
> else if let pair = elements.first as? 
> (String,CountableClosedRange)
> { self = .int(pair.0, pair.1.lowerBound ... pair.1.upperBound ) }
> else { fatalError("Can only init from Double...Double or Int...Int") }
> }
>
> // ...
> }
>
>
> On Tue, Jan 9, 2018 at 6:10 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com <
>> charlesism@gmail.com> wrote:
>>
>>> I used a DictionaryLiteral only yesterday, and it turned what would have
>>> a typically unreadable array of Structs into something much more elegant.
>>> I'm pretty sure the only reason Literals (of all varieties) aren't used
>>> more often is because Swift programmers don't realize they are available
>>> and easy to implement.
>>>
>>
>> Could you provide an example of how you used DictionaryLiteral?
>>
>> Nevin
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
On Tue, Jan 9, 2018 at 8:26 PM, Charles Constant via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Nevin (et al)
>
> Here's the relevant section of my code. It's from a protocol I use called
> "ParameterSet" to extend OptionSets to contain small numbers (like an Enum
> with an associated type, but all the data is stored in the UInt). Wouldn't
> be my first choice to share, as it breaks KISS. Anyhow, the "
> ExpressibleByDictionaryLiteral" lets me specify a "params" template
> tersely. I only found out how to use the -Literal initializers last year. I
> love them.
>
> struct DrumNote: ParameterSet {
> let rawValue: UInt
>
> static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
> "reverse" ]
>
> static let
> velocity = param(0),
> flam = param(1),
> roll = param(2),
> reverse = param(3),
>
> // ...
>
> }
>
> enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral
> {
> public init( dictionaryLiteral elements: (String,Any)... ) {
> if let pair = elements.first as? (String,ClosedRange) {
> self = .doub(pair.0,pair.1) }
> else if let pair = elements.first as? 
> (String,CountableClosedRange)
> { self = .int(pair.0, pair.1.lowerBound ... pair.1.upperBound ) }
> else { fatalError("Can only init from Double...Double or Int...Int") }
> }
>
> // ...
> }
>
>
> On Tue, Jan 9, 2018 at 6:10 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com <
>> charlesism@gmail.com> wrote

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Charles Constant via swift-evolution]

Hi Nevin (et al)

Here's the relevant section of my code. It's from a protocol I use called
"ParameterSet" to extend OptionSets to contain small numbers (like an Enum
with an associated type, but all the data is stored in the UInt). Wouldn't
be my first choice to share, as it breaks KISS. Anyhow, the
"ExpressibleByDictionaryLiteral" lets me specify a "params" template
tersely. I only found out how to use the -Literal initializers last year. I
love them.

struct DrumNote: ParameterSet {
let rawValue: UInt

static let params: [ParamType] = [ ["velocity":0...255], "flam", "roll",
"reverse" ]

static let
velocity = param(0),
flam = param(1),
roll = param(2),
reverse = param(3),

// ...

}

enum ParamType: ExpressibleByStringLiteral, ExpressibleByDictionaryLiteral {
public init( dictionaryLiteral elements: (String,Any)... ) {
if let pair = elements.first as? (String,ClosedRange) {
self = .doub(pair.0,pair.1) }
else if let pair = elements.first as?
(String,CountableClosedRange) { self = .int(pair.0,
pair.1.lowerBound ... pair.1.upperBound ) }
else { fatalError("Can only init from Double...Double or Int...Int") }
}

// ...
}


On Tue, Jan 9, 2018 at 6:10 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com <
> charlesism@gmail.com> wrote:
>
>> I used a DictionaryLiteral only yesterday, and it turned what would have
>> a typically unreadable array of Structs into something much more elegant.
>> I'm pretty sure the only reason Literals (of all varieties) aren't used
>> more often is because Swift programmers don't realize they are available
>> and easy to implement.
>>
>
> Could you provide an example of how you used DictionaryLiteral?
>
> Nevin
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

[Charles Constant via swift-evolution]

The disadvantage is that it's easy in Swift to push millions of things in
protocols, and end up with:

class MyClass: SwiftProtocollable, MoreFunctionalityable, MoreHereable,
StillMoreable, ThisTooable, StillMoreable {
...
}

Given enough thought, maybe this can be avoided, but the problem is (as far
as I can tell, and I may be out to lunch) that protocols are
philosophically the "correct" way in Swift to do a lot of things.

I recently wrote a tiny framework for Drag n Drop, and I wound up with
various combinations of almost 10 protocols - and, afai could tell, that
was "correct" because I was specifying the different abilities of my
classes (eg: do they have methods for reading text data, file data, writing
promises, reading promises, etc) It's just not easy to read.




On Mon, Nov 14, 2016 at 4:10 PM, Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:

> Given optionals and closures, is it necessary to support optional
> protocols?
>
> protocol MyProtocol {
> var titleForRow:((_ indexPath:IndexPath)->(String))? { get }
> }
>
> One disadvantage is that you need Obj-C, which means it doesn’t run on
> linux, or several other platforms.
> Another disadvantage, as I understand it, is it requires slower Obj-c
> dispatch, instead of witness tables.  Obj-C dispatch also only considers
> names, not argument & return types.
>
> > On Nov 14, 2016, at 5:48 PM, Rick Mann via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Will Swift ever support optional methods without @objc?
> >
> > What are the disadvantages of marking a protocol @objc?
> >
> > Thanks!
> >
> > --
> > Rick Mann
> > rm...@latencyzero.com
> >
> >
> > ___
> > 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] [pitch] "import" declaration, support for comma-separated modules

[Charles Constant via swift-evolution]

> Having one import per line is much more readable and maintainable

This depends on how much importance you give to "import" declarations. If
you feel they equally important as the rest of your code, I can understand
why you would want to see them. I don't.

My preference is to see as much of the rest of my code as possible. I don't
spend nearly as much time checking which modules I imported, as I do
editing functions and classes. I'd almost always prefer to have another
three lines of a protocol visible, than three lines of imports. Except that
the imports will be visible anyways, just - and even this is arguable in
many cases - harder to read.

> I never understood the desire for *extreme* vertical conciseness

It's probably *because* I use more vertical space than most people, that
losing screen real-estate to "import" declarations bothers me.


On Mon, Oct 17, 2016 at 8:40 AM, Said Sikira via swift-evolution <
swift-evolution@swift.org> wrote:

> -1. I disagree.
>
> Having one import per line is much more readable and maintainable
> especially when you have statements like `import func Framework.someMethod`.
>
> Being able to use `let a, b, c, …` doesn’t have to do anything with
> importing modules since those are completely different features of the
> language.
>
> On October 17, 2016 at 5:22:02 PM, Jay Abbott via swift-evolution (
> swift-evolution@swift.org) wrote:
>
> -1 - I don't like this.
>
> I never understood the desire for *extreme* vertical conciseness, it tends
> to make code less readable in general and definitely makes diffs a lot
> harder harder to read.
>
>
> On Sun, 16 Oct 2016 at 11:26 Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Purely additive feature, not for Swift 4 Phase 1.
>> And a -1 from me for reasons already mentioned.
>> ___
>> 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] [pitch] "import" declaration, support for comma-separated modules

[Charles Constant via swift-evolution]

How would we all feel about allowing multiple modules with one import
statement?

Eg: the option to write

*import Cocoa, Foo, Bar.Baz *

in addition to just:

*import Cocoa   *
*import Foo *
*import Bar.Baz *

When I'm writing smaller files that import a few modules, I'd  prefer to
lump the imports together like this. Doesn't seem like a feature that would
require much effort to implement either.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charles Constant via swift-evolution]

+1 for me for "in-module" as a stop-gap, since I imagine it would be the
quickest, and least disruptive, way to make this happen.

I would add the caveat that if we do so, I really hope we commit to making
stored properties available *everywhere* later.

Even though it's more often than not "in-module" where I need this, the
fewer "exceptions to the rule" we have in Swift the better. It gets tricky
trying to plan things out when one has to juggle too many features that
work in one context, but not another.

So +1 with the hope that it doesn't stay "in-module" till the end of time.



On Fri, Oct 14, 2016 at 6:01 PM, Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Let extensions introduce stored properties, but only in the same module
> as the type’s definition. Then, the compiler can just take any extensions
> into consideration when it’s determining the size of the type, just as if
> the properties had been declared in the type. Declaring stored properties
> on an extension outside of the type’s module results in a compiler error,
> exactly as today. This would, without any performance drawbacks, solve one
> of the big problems that people are hoping to solve via stored properties
> in extensions—the ability to organize members by protocol conformance.
>
> Yes please! A big strong +1 to this from me. I can think of several
> specific chunks of problem code that this would clean up immensely.
>
> Contra Karl in another message, it’s _in-module_ stored property
> extensions that I want most frequently. By far.
>
> It seems to me that Charles’s idea could be introduced as its own
> proposal. If out-of-module stored property extensions do eventually become
> feasible, then Charles’s proposal is a good stepping stone. If they never
> do, then his proposal has done no harm.
>
> I realize this probably falls into the post-ABI stability bucket, but I’d
> love to help write/support the proposal when its time comes.
>
> Cheers,
>
> Paul
>
> ___
> 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] [proposal] Allow convenience initializers to use "self = Foo()"

[Charles Constant via swift-evolution]

Does anyone else think we should allow assignment to self in Class
"convenience init" methods?

Ie: this is legal for a struct, but complains about self being immutable if
you try it in a Class, even if it's a convenience init:

init( foo:String ){
self = Me( bar:foo )
}

I haven't seen this proposed so far, but is there even a reason why can't?

I've run into headaches with this a couple times lately. Specifically,
where the appropriate construct for my code seemed to be an init, but I
didn't have access to the desired required init, only a class function.
It's also confusing if you decide to change some Type from a struct to a
class, to find you have to turn an init into a static function.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Charles Constant via swift-evolution]

I actually prefer "fileprivate" to the alternatives, but imo using the word
"private" is a bad choice for this, since it's basically a relative term.
If we're going with parens "visibility(file)" makes more sense to me.



On Fri, Oct 7, 2016 at 5:00 AM, Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> > FWIW, I fully agree with you and I do believe your suggestion just much
> > ...
> > 'moduleprivate'.. but these are just ugly(just like fileprivate ;-) )
>
> +1
>
> I would also much prefer
>
> private(scope)
> private(file)
> private(module)
> etc...
> ___
> 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] associated objects

[Charles Constant via swift-evolution]

-1 for me, but...

> I’m aware of how associated objects work, I’m not aware of why they are
particularly useful in Swift

If stored properties in Extensions aren't useful, why would anything else
in an Extension be useful either? I gather there are reasons it is
impractical to implement them, but saying there's no benefit to them is
like arguing against allowing methods in Extensions, or computed
properties.

My own reason for wanting stored properties in Extensions, is that it would
allow me to organize my classes according to their features. I'm working on
drag and drop at the moment, and I would find it much less confusing in
future, if I could keep all the related properties and methods I'm creating
isolated in a single file. It would also allow me to reuse the same View in
other projects that don't require Drag and Drop *as is.* Otherwise, when I
reuse the class, I'll have to either carry along stored properties I don't
need, or carefully weed them out.

> we have to do better than ObjC

That's the reason I'm against the proposal, too. If we allow stored
properties they should be first-class citizens (assuming that is
technically possible, I don't understand enough about how Frameworks
etc are compiled to know if it would cause issues). I already avoid
Associated Objects because I worry the additional complexity will make my
apps harder to debug if there are memory or performance issues, so the
thought of baking them into Swift doesn't really appeal to me.




On Wed, Sep 28, 2016 at 6:52 PM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Sep 28, 2016, at 11:26 AM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have implemented Associated Objects (and values) in pure swift here:
> https://github.com/j-h-a/AssociatedObjects
>
> The README is very short and straight-forward so I won't re-describe it
> here.
>
> The implementation isn't great, but it's a small and simple proof of
> concept. I have further extended this (not in GH, but very simple and happy
> to share if anyone cares) to add dynamic methods using closures onto
> individual object instances. Useful for user interactions, or adding
> 'actions' to objects.
>
> I'd like to propose that this or something similar be added to the
> standard library. It could potentially even be added to AnyObject so that
> developers can use it without having to declare an extension for whichever
> classes they want to use it on.
>
> As mentioned, this can easily be extended (either in the standard library
> or by developers) to add closures dynamically to any object, or to any
> class, which could serve as a useful way for those not concerned with type
> safety and the like to get some dynamic behaviour in there in the shorter
> term. With a little language support it could even be used to implement
> stored properties in extensions very easily.
>
>
> I’m not convinced by this explanation.  You haven’t shown me any cases
> where this feature is absolutely necessary, merely enumerated features.
> I’m aware of how associated objects work, I’m not aware of why they are
> particularly useful in Swift and I’d like to be given something to the
> contrary.
>
> As for the point about dismissing type safety: There is no precedent in
> the language for type-unsafe operations to be exposed wholesale to the end
> user like this.  At the very least you should tag the API as Unsafe
> Associated Objects and now you’re stuck explaining why you’d like to stick
> a completely unsafe feature into a language that touts “Safety by
> Default”.  It feels like pining for the Objective-C days of old, and I
> happen to think that that’s fine, but we have to do better than ObjC, not
> have features for the sake of features.
>
>
> A better implementation would need some language changes - specifically
> deinit hooks (has that ever been discussed?) because of the way weak
> references are lazily zeroed. Another implementation improvement might
> lazily add the dictionary to each object instead of storing it globally -
> not sure if this would have ABI implications.
>
>
> That kind of implementation would be space-inefficient - all Swift classes
> now automatically incur an extra pointer-sized allocation per instance.  It
> absolutely has ABI implications too because now we have to track an extra
> part of the header for an object and standardize on access patterns for the
> associated objects table.
>
> Interested in feedback and thoughts :)
> ___
> 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 3.0 vs 3.x and Timing Clarification

[Charles Constant via swift-evolution]

The date I can submit my Swift 3 app to the App Store has significant
impact on my life at the moment. I think Chris' meaning was actually fairly
clear, but I'd also appreciate if the team could spell out an ETA again in
black and white. I'd like to be 100% sure I didn't misunderstand.



On Sat, Jul 30, 2016 at 6:38 PM, Robert Hedin via swift-evolution <
swift-evolution@swift.org> wrote:

> My team has been closely following things here and has been looking
> forward with great anticipation to using Swift 3 in our production systems.
>
> To that end, I'd like to confirm (or not) that "Swift 3.0" is no longer
> expected to ship in "late 2016" as currently reflected on the Swift
> Evolution GitHub repo but will rather ship in "Spring 2017".
>
> Over the past 24 hours I've got different members of my team coming up
> with different reads of what, exactly, "3.x" means in context.
>
> Thanks!
>
> rob.
>
> --
> *Robert **Hedin  *|Dir Software Engineering
> *w:* 770-226-2650  *e:* robert.he...@weather.com
>  
>  
>  
>
> ___
> 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

[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

[Charles Constant via swift-evolution]

An enthusiastic +1 to Erica's suggestion.

While I also see the appeal of Chris Kornher's suggestion of giving the
enum a proper Type, I think Erica's syntax is more appropriate. I haven't
though through the implications of having an "anonymous enum" but since the
main use case is just to give functions a more convenient and legible way
to specify options, I think shorter is better.

I really like this proposal. It would result in a lot of Swift code, out
there in the world, being a little easier to read :)



On Tue, May 31, 2016 at 9:53 AM, Christopher Kornher via swift-evolution <
swift-evolution@swift.org> wrote:

> *Forwarding on behalf of Chris Kornher:*
>
> I think that this is a great idea. It would be nice to:
> 1) Have a standard way to generate these values from textual or other
> serialized representations.
> 2) A way to be able to store these vales (as preferences, for example)
>
> A simple way to do support this is to make these into full-fledged enums:
>  1) make these rawrepresentable string enums
>  2) give the type a name for use when needed: e.g.
> scaleAndCropImage.fitImage.options_t or perhaps, :
> scaleAndCropImage_fitImage_options_t enabling:  struct MyPreferenceStruct
> { .. var fitOptions: scaleAndCropImage_fitImage_options_t }
>
> Thinking about this a bit more, requiring a name like:
>
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> *operation: ScaleCropFitFitFill{.Fit | .Fill} = .Fit*
> ) -> UIImage {
> would be cleaner.
>
> - Chris
>
>
> On May 31, 2016, at 10:16 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

[Charles Constant via swift-evolution]

It did occur to me to use "::" but it seemed a bit cruel to have the
equivalent of  "? :" be reversed. Ie: by using ":: ??" If the team had
chosen :: to be the Nil Coalescing Operator, rather than ?? it would be
more tempting.

I had some problems messing around with these symbols. I think it was that
"??" is 131 and something else (maybe "==") was 130. Also the compiler can
be grumpy about long chains of things. I assume that will get better. Maybe
it has already gotten better, I'm still not on the latest version.

Anyhow, I think I'm fine just using the existing ternary... now that Dany
has made me realize I've been avoiding, any inefficiently mentally parsing,
long ternary chains for no good reason for the past decade. I'm fine, aside
from feeling disoriented!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

[Charles Constant via swift-evolution]

Right... per "[swift-evolution] [Idea] Find alternatives to `switch self`"
 it was only "impossible" in my head.

Thanks Dany

This proposal is unnecessary.

On Mon, May 23, 2016 at 8:53 PM, char...@charlesism.com <
charlesism@gmail.com> wrote:

> I'm not actually familiar with the term "tri op" but if you're referring
> to the ternary, it's only useful when you two, or three items.
>
> If you chain a ternary to use more than three options it becomes
> error-prone and almost impossible for a human to read
>
> When I'm at my desktop I'll add a couple better examples of what I'm
> proposing.
>
> Sent from my iPhone
>
> On May 23, 2016, at 6:18 PM, Dany St-Amant <dsa@icloud.com> wrote:
>
>
> Why reinvent the wheel, when the old trusty (but a bit cryptic according
> to some) tri-op can do the trick…
>
> Le 23 mai 2016 à 04:29, Charles Constant via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Here's a few examples of what this change would allow.
>
> I just plucked the first instances of other people's switch statements
> that I found on GitHub.
>
> If there were an easy way to search GitHub for chained ternary
> expressions, I would have added some examples of those too, since they
> could all be improved with this where clause + ??.
>
>
> mutating func toggle() {
> switch self{
> case Off:
> self = On
> case On:
> self = Off
> }
> }
>
>
>
> mutating func toggle() {
> self = .On where (self == .Off) ?? .Off
> }
>
>
> mutating func toggle() { self = self == .Off ? .On : .Off }
>
>
> switch switchNumberThree {
> case 10, 11, 12:
> println("It is \(switchNumberThree)")
> default:
> ("It is none of them!")
> }
>
>
> println(
> "It is \(switchNumberThree)" where 10...12 ~= switchNumberThree
> ?? "It is none of them!"
> )
>
>
> print( 10...12 ~= switchNumberThree ? "It is \(switchNumberThree)"
>: "It's none of them" )
>
>
> switch x {
> case 1:
> j++
> case 2:
> j++
> case 3:
> j++
> case 4:
> j++
> fallthrough
> case 5:
> j++
> fallthrough
> default:
> j++
> }
>
>
> j = j+1 where (4...5 ~= x) ?? j+2
>
>
> Broken conversion:
> j += 4...5 ~= x ? 1 : 2
>
> Proper conversion:
> j += 4 ~= x ? 3 : 5 ~= x ? 2 : 1
>
> Earlier e-mail example:
>
> *let foo = *
> *"positive" where ( bar > 0 )  ?? *
> *"negative" where ( bar < 0 ) ?? *
> *"zero"*
>
>
> let foo = bar > 0 ? "positive" :
>   bar < 0 ? "negative" :
>   "zero"
>
> Dany
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Charles Constant via swift-evolution]

Good grief. I think you're right.

Some how, a long time ago, I got it into my head that the order in which
each part of the ternary got evaluated would cause problems for this kind
of thing.

I've had a huge blindspot and I've been railing on the list for something I
don't need for weeks.

Wow, I couldn't be more embarassed.

But I'm happy too, because I can go ahead and just use a chained ternary.

Sorry all, and thanks.


On Mon, May 23, 2016 at 6:26 PM, Dany St-Amant <dsa@icloud.com> wrote:

>
> Le 20 mai 2016 à 07:14, Charles Constant via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I wrote some code tonight to experiment with this kind of thing. I
> apologize if it's off-topic for the thread, but it might be useful to
> others who want to experiment.
>
>
>
> //: Playground - noun: a place where people can play
>
> import Cocoa
>
> infix operator • { precedence 180 }
> infix operator → { associativity left precedence 70 }
> infix operator … { associativity right precedence 60 }
>
> func → ( lhs: Bool, rhs: T ) -> T? {
> return lhs ? rhs : nil
> }
>
> func … ( lhs:T?, rhs:T ) -> T {
> return lhs != nil ? lhs! : rhs
> }
>
> func depends<I,O>( dep:I, _ closure: (I)->(O) ) -> O {
> return closure( dep )
> }
>
> func • <I,O>( lhs: I, rhs: (I)->(O) ) -> O {
> return depends( lhs, rhs )
> }
>
> /* Example using "depends" */
>
> let
> str:String,
> i = 7
>
> str = depends( i ){
> $0==2 → "two" …
> $0==3 → "three" …
> $0==4 → "four" …
> "other"
> }
>
>
> Hmm… replacing -> by ?, and … by : you get:
>
> str = depends( i ){
> $0==2 ? "two" :
> $0==3 ? "three" :
> $0==4 ? "four" :
> "other"
> }
>
> which work as is without a need to define new operators.
>
> Dany
>
> /* Example using "•" operator as "depends" */
>
> enum People { case Kurtz, Popescu, Lime, Martins }
> enum Order { case First, Second, Third, Unknown }
>
> let
> order:Order,
> person:People = .Lime
>
> order = person • {
> $0 == .Kurtz → .First …
> $0 == .Popescu → .Second …
> $0 == .Lime → .Third …
> .Unknown
> }
>
>
> I also have some trepidation about posting it here, because it might have
> bugs. I wans't sure what "precedence" and "associativity" should be, for
> example. But it does make it more convenient to test alternative characters
> for operators, etc.
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Apr 9, 2016 at 12:05 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On 09.04.2016 9:31, Brent Royal-Gordon wrote:
>>
>>> This design is still very much under development—it hasn't even been
>>> reviewed, let alone added to the language. Here's the draft proposal:<
>>> https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md
>>> >
>>>
>>> I'm not saying that this will necessarily be a solution that ends up
>>> being accepted—I'm merely saying that yes, it's something people are
>>> thinking about and designing; it's just been inactive for a few weeks.
>>>
>>
>> Oh, I see. Thank you for letting know. Just missed "you would be able" in
>> your previous message, did read it as "you are able", so was trying to find
>> this in current Swift version. OK, glad to know that most likely we'll have
>> improvements in enums eterations for Swift 3.0.
>>
>> ___
>> 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] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

[Charles Constant via swift-evolution]

Correction. My example reused "val" This is what I should have typed:

*let foo = *
*"positive" where ( bar > 0 )  ?? *
*"negative" where ( bar < 0 ) ?? *
*"zero"*

Sorry for that. My mind seems to switch itself off whenever I submit to
this list :)

Also, since my previous posts to this list about ternary and switch
assignment, etc. I now feel that including the variable name in the bool
side is useful. It would be a quick way to do the following sort of thing:

*let foo = *
*"positive" where ( bar > 0 )  ?? *
*"negative" where ( bar < 0 ) ?? *
*"animal zero" where ( is_animal == true ) ?? *
*"normal zero"*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Charles Constant via swift-evolution]

Would this still be an issue if switch statements were less verbose? I
don't see why a "switch" statements should be so much more verbose than an
"if statement".

Writing boiler plate for switch statements is by far my #1 irritation at
the moment (now that argument labels have been made beautiful - thanks! -
and Generics are being improved).

As Paul alluded to, this has been discussed with
https://github.com/cacruden/swift-evolution/blob/master/proposals/0024-Pattern-Matching-Partial-Function.md



On Fri, Apr 8, 2016 at 2:30 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 23, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> * Allow you to attach member definitions to particular cases. It would be
> an error if they didn't all define the same members, unless there was a
> top-level catchall.
>
>enum Suit: Int {
>var isRed: Bool { return false }
>
>case Hearts {
>let description: String { return "♥️" }
>let isRed: Bool { return true }
>}
>case Spades {
>let description: String { return  "♠️" }
>}
>case Diamonds {
>let description: String { return  "♦️" }
>let isRed: Bool { return true }
>}
>case Clubs {
>let description: String { return  "♣️" }
>}
>
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>}
>
>
> Oh my, I absolutely *love this.* This would be a godsend for making
> ErrorType enums that bridge nicely to NSErrors, with code and userInfo
> properties attached to each case.
>
> +1.
>
> Charles
>
>
> ___
> 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] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

I can't stop fiddling around with this... so here's another minor
variation. My new new favourite, if we're doubling down on the ternary.

We could start with Paul's ternary example... but it seems more in keeping
to me, with the existing ternary, to use a colon as a separator. If we do
that, an exclamation point seems appropriate, and pretend that it's just
how a ternary expression behaves when it's testing something extra-ternary
(like a n enum with four possible cases)

// Syntax when the value you’re testing is a Boolean

let val = boo ? 0xFF : 0x00FF00


// Syntax when the value you’re testing is not Boolean

let val = color ? ( .Red ! 0xFF ) : ( .Green ! 0x00FF00 ) : ( .Blue !
0xFF ) : ( _ ! 0xFF )


// … Parens are not required, but probably unwise unless you format on
multiple lines. Eg:

let val = color ?

.Red ! 0xFF :

.Green ! 0x00FF00 :

.Blue ! 0xFF :

_ ! 0xFF

I actually like this a lot because it's concise, and aesthetically in
harmony with the normal ternary.

There's obvious downsides to using an exclamation point in Swift, but I
think it's still pretty nice.








On Tue, Jan 5, 2016 at 11:41 PM, Paul Ossenbruggen via swift-evolution <
swift-evolution@swift.org> wrote:

> Heh, one other thought. Pretty sure this was rejected by the switch
> statement but if keeping it concise for expressions is a goal then _ might
> make sense for the default case especially with this form. :-)
>
> let fh = ?(color, .Red: 0xFF // only one expression can be the result
> here so case is unnecessary.
>   .Green: 0x00FF00
>   .Blue: 0xFF
>   _: 0xFF) // default is always last, unless all
> cases are handled.
>
> I agree with it being rejected for the statement form, but kinda makes
> sense here.
>
> On Jan 5, 2016, at 10:50 PM, Paul Ossenbruggen  wrote:
>
> The thing I don’t like is the repeated use of case. and default. This, I
> think makes the expression longer than it needs to be. For expressions it
> is not necessary because you only have one expression which returns one
> value, where as in a statement you have multiple statements following it,
> so it is necessary to separate the cases with the word “case”. I think
> trying to reduce clutter is important.
>
> For example, statements have to deal with multiple statements per case.
>
> let color = Colors.Red
> // hello
> let res : Int
> switch color {
> case .Red:
> res = 0xFF
> print(res) // case is necessary here to separate statement lists.
> case .Green:
> res =  0x00FF00
> print(res)
> case .Blue:
> res = 0xFF
> print(res)
> default:
> res = 0xFF
> }
>
> This is why I went down the path of trying to group it with parenthesis
> and optionally remove the word case. I know it may seem a little less like
> a "switch" but I think having to write out “case" over and over is not
> great when it does not serve the same purpose as it does in the statement
> form. So in the compact form:
>
> let fh = ?(color, .Red: 0xFF // only one expression can be the result
> here so case is unnecessary.
>   .Green: 0x00FF00
>   .Blue: 0xFF
>   : 0xFF) // default is always last, unless all cases
> are handled.
>
>
> This seems more light and more and just as understandable as Thorsten's
> suggestion. (Note: I keep playing with the separators because the feedback
> was, my latest suggestions were not Swift like). Also, it is possible to
> drop the “case" in this structure and it can be read more like a function
> if desired. My suggestion also supported this form but its only advantage
> is that it looks more like a “switch", there may be value in that but I
> think conciseness and less clutter should win:
>
> let fh = ?(color, case .Red: 0xFF
>   case .Green: 0x00FF00
>   case .Blue: 0xFF
>   default: 0xFF)
>
> Not sure though if people don’t like having alternatives forms though.
>
> I think there is value in having a consistent way of doing index based as
> well as boolean based expressions as I have suggested in my proposal. I
> know that is a harder thing to push for but I think it is a win. I have
> backpedaled on some of my weirder character choices here so it more like
> the ternary.
>
> let fb = ?(pickOne, “A", "B", "C", "D", "E", "F", "G” : "Z")
> let fe = ?(truthy == truth, “unlikely” : “likely")
>
> If you look at these suggestions above, I have only moved one ? added a
> comma, and added parenthesis to the ternary. I think these latest
> suggestions look more like Swift and more like the ternary than my last
> email.
>
> If it is really preferred the control value could be moved outside the
> parens but I think it makes it harder to find the beginning and end of the
> ternary and it does not have the advantage of the function like feel to
> it:.
>
> let fe = truthy == truth ?(“unlikely” : “likely")
>
> let 

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

[Charles Constant via swift-evolution]

I support this, not because I find NS- and CG- geometric structs confusing.
I support it because I'm hoping Swift library versions would be generic. I
would be very glad to see us get *Rect* or *Point* as part of
the standard library.

On Wed, Jan 6, 2016 at 9:32 PM, John Randolph via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 5, 2016, at 10:10 PM, Brent Royal-Gordon 
> wrote:
> >
> >> As an OS X and iOS developer, it sometimes seems that I work with
> [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or
> String.  I’d love to see Swift’s standard library include Rect, Point, and
> Size types, with bridging to make them “just work” with any UIKit or AppKit
> API that expects their NS or CG equivalents.  Maybe also typealias Frame
> and Bounds to Rect while we’re at it.
> >>
> >> Thoughts?
> >
> > My main thought is that, although I use these types in my iOS and Mac
> apps all the time, I think I've used a rectangle type in web development
> maybe once (when I was generating images). Swift is currently used mainly
> for GUI programming, but most of the domains it's expanding into are ones
> where it doesn't need those types.
>
> It’s a feature that would be useful in the areas where Swift is being used
> today.  Whether a feature is important in other domains doesn’t make it any
> less useful in Swift’s current applications.
>
> -jcr
> ___
> 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] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

Alex,

We know, from the traditional ternary, that a colon is going to satisfy the
requirements of a separator, even when we want to chain.

Is this the case with bar "|"? To me, this doesn't bode well

let a = b ?
2 : 3 |
4 : 5 |
_ : -1

Above, are we talking about a result of "3 [Bitwise OR] 4" or is the result
"3 [SEPARATOR] 4"? I could be wrong, but I suspect in practise, it would be
complicated to use, and probably not possible to chain.




On Wed, Jan 6, 2016 at 9:10 PM, Alex Popov  wrote:

> I like the bar `|` variation, but I do think the control value should be
> out front, otherwise the ? reads as an optional to my mind, whereas the
> former comes across as the beginning of a ternary (which this is
> effectively an extension of).
> The bar variation feels Haskell-y in a satisfying way, and also has the
> added benefit of clearly delimiting the effective "range" of the multiary.
>
> Alex Popov Jr.
> Principal iOS developer | Shelfie
> www.shelfie.com | @getshelfie
>
>
>
>
> On Wed, Jan 6, 2016 at 8:35 PM -0800, "Paul Ossenbruggen via
> swift-evolution"  wrote:
>
> Hi Charles,
>>
>> Chris, already said he did not like ? being used for ternary because it
>> was already used for optionals. I think because of historical precedent it
>> may be acceptable here.  I have tried combos earlier with ! and got no
>> support, admittedly not with the same usage as yours.
>>
>> Do you really find it confusing not having a separator there? It is
>> essentially a switch case without the word “case”. In my model the colon
>> only indicates the “else” or “default” case, the other cases are separated
>> by commas or whitespace. With my email taking the Swift Book examples and
>> converting it from statement to expression form, I did not find any of them
>> confusing, well maybe the first one, which found vowels and consonants, but
>> that did not look that great in statement form either. .
>>
>> if so maybe the | would be better as the separator because it would not
>> change the switch like syntax:
>>
>> let numberSymbol: Character = "三"  // Simplified Chinese for the number 3
>> let possibleIntegerValue:Int? = numberSymbol ?
>>| "1", "١", "一", "๑": 1
>>| "2", "٢", "二", "๒": 2
>>| "3", "٣", "三", "๓": 3
>>| "4", "٤", "四", "๔": 4
>>|  _ : nil
>>
>> if let integerValue = possibleIntegerValue {
>> print("The integer value of \(numberSymbol) is \(integerValue).")
>> } else {
>> print("An integer value could not be found for \(numberSymbol).")
>> }
>> // prints "The integer value of 三 is 3.”
>>
>> But I still don’t see it a necessary.  perhaps that would allow removal
>> of the parenthesis and I think this would get rejected as not looking very
>> Swift like. Also single line form which isn’t bad:
>>
>> * let val = color ? **.Red:** 0xFF | **.Green:** 0x00FF00 | *
>> *.Blue:** 0xFF** | **_:** 0xFF*
>>
>> But still not sure the | adds that much.
>>
>> * let val = color ? **.Red:** 0xFF, **.Green:** 0x00FF00, * *.Blue:*
>> * 0xFF, * *_:** 0xFF*
>>
>> Or this is without the commas is still readable but maybe a little harder:
>>
>> * let val = color ? **.Red:** 0xFF **.Green:** 0x00FF00 * *.Blue:*
>> * 0xFF * *_:** 0xFF*
>>
>> One other thing, I would still prefer the control value inside the brace
>> rather than out front, but I see that most people still want it out front
>> and since it would be a breaking change for ternary, I have kind of backed
>> off it but I think this is still clearer because the control value is not
>> floating out in front.
>>
>> * let val =  ?(color, **.Red:** 0xFF, **.Green:** 0x00FF00, *
>> *.Blue:** 0xFF, * *_:** 0xFF)*
>>
>> On Jan 6, 2016, at 7:06 PM, Charles Constant 
>> wrote:
>>
>> > I see what you are trying to do, because of the colon being both used
>> for switch cases and
>> > separators for the ternary and so there needs to be a new character for
>> each case.
>> > I am not sure that putting colons between each case is really necessary
>> though.
>>
>> Most of us (including you and I) like a form that starts with " let val =
>> condition ? " like the existing ternary. Let's say a proposal like that
>> gets accepted... I really believe "colons as separators" is the best idea
>> in the case. Otherwise, it gets pretty confusing.. we'll have the existing
>> ternary where a colon does one thing, and our new "extra ternary" where it
>> does something else.
>>
>> This is why I like colons (this won't make sense unless your email has
>> rich text to show the colors):
>>
>> * let val = color ? *
>> *.Red !**  0xFF : *
>> *.Green !**  0x00FF00 : *
>>
>> *_ !**  0xFF*
>>
>> ... no syntax here different from the existing except the addition "
>> *.Red !* ". As for the exclamation... Swift already uses an exclamation
>> for a billion other things, which is unfortunate. But the same can be said
>> of "?" and that's already used 

Re: [swift-evolution] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

Hi Paul,

My opinion, atm, is that ":" as a separator is the best solution. True,
it's not *Swift-like*, but neither is the existing ternary, which Chris
wants to keep. On then other hand, "colon as separator" is extremely
*ternary-like*.

So benefits of "colon as separator" as I see them:

- Syntax is *easy to remember* (as long as you're used to writing ternary
expressions)
- Extremely *compact* syntax
- Each component is demarked by a special character, which I'm pretty sure
makes any *chaining* possible
- *Easy to "market"* as a "new modification of ternary expressions in
Swift" rather than a brand new construct
- *Somewhat intuitive*. The compact form and cryptic symbols mean a ternary
isn't going to be self explanatory. But at least there's a call and
response sort of logic to "condition *?*" followed by "case *!*"

That said, I don't want to dig my heels in about "colon as separator"
version. If others don't like it, I support *any* version we've discussed
in this thread, switch-like or ternary-like. As long as it means we do away
with a preceding variable declaration and some of the repeated
boilerplate... that's the important thing for me.


















On Wed, Jan 6, 2016 at 8:35 PM, Paul Ossenbruggen  wrote:

> Hi Charles,
>
> Chris, already said he did not like ? being used for ternary because it
> was already used for optionals. I think because of historical precedent it
> may be acceptable here.  I have tried combos earlier with ! and got no
> support, admittedly not with the same usage as yours.
>
> Do you really find it confusing not having a separator there? It is
> essentially a switch case without the word “case”. In my model the colon
> only indicates the “else” or “default” case, the other cases are separated
> by commas or whitespace. With my email taking the Swift Book examples and
> converting it from statement to expression form, I did not find any of them
> confusing, well maybe the first one, which found vowels and consonants, but
> that did not look that great in statement form either. .
>
> if so maybe the | would be better as the separator because it would not
> change the switch like syntax:
>
> let numberSymbol: Character = "三"  // Simplified Chinese for the number 3
> let possibleIntegerValue:Int? = numberSymbol ?
>| "1", "١", "一", "๑": 1
>| "2", "٢", "二", "๒": 2
>| "3", "٣", "三", "๓": 3
>| "4", "٤", "四", "๔": 4
>|  _ : nil
>
> if let integerValue = possibleIntegerValue {
> print("The integer value of \(numberSymbol) is \(integerValue).")
> } else {
> print("An integer value could not be found for \(numberSymbol).")
> }
> // prints "The integer value of 三 is 3.”
>
> But I still don’t see it a necessary.  perhaps that would allow removal of
> the parenthesis and I think this would get rejected as not looking very
> Swift like. Also single line form which isn’t bad:
>
> * let val = color ? **.Red:** 0xFF | **.Green:** 0x00FF00 | * *.Blue:*
> * 0xFF** | **_:** 0xFF*
>
> But still not sure the | adds that much.
>
> * let val = color ? **.Red:** 0xFF, **.Green:** 0x00FF00, * *.Blue:*
> * 0xFF, * *_:** 0xFF*
>
> Or this is without the commas is still readable but maybe a little harder:
>
> * let val = color ? **.Red:** 0xFF **.Green:** 0x00FF00 * *.Blue:*
> * 0xFF * *_:** 0xFF*
>
> One other thing, I would still prefer the control value inside the brace
> rather than out front, but I see that most people still want it out front
> and since it would be a breaking change for ternary, I have kind of backed
> off it but I think this is still clearer because the control value is not
> floating out in front.
>
> * let val =  ?(color, **.Red:** 0xFF, **.Green:** 0x00FF00, * *.Blue:*
> * 0xFF, * *_:** 0xFF)*
>
> On Jan 6, 2016, at 7:06 PM, Charles Constant 
> wrote:
>
> > I see what you are trying to do, because of the colon being both used
> for switch cases and
> > separators for the ternary and so there needs to be a new character for
> each case.
> > I am not sure that putting colons between each case is really necessary
> though.
>
> Most of us (including you and I) like a form that starts with " let val =
> condition ? " like the existing ternary. Let's say a proposal like that
> gets accepted... I really believe "colons as separators" is the best idea
> in the case. Otherwise, it gets pretty confusing.. we'll have the existing
> ternary where a colon does one thing, and our new "extra ternary" where it
> does something else.
>
> This is why I like colons (this won't make sense unless your email has
> rich text to show the colors):
>
> * let val = color ? *
> *.Red !**  0xFF : *
> *.Green !**  0x00FF00 : *
>
> *_ !**  0xFF*
>
> ... no syntax here different from the existing except the addition "
> *.Red !* ". As for the exclamation... Swift already uses an exclamation
> for a billion other things, which is unfortunate. But the same can be said
> of "?" 

Re: [swift-evolution] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

> I see what you are trying to do, because of the colon being both used for
switch cases and
> separators for the ternary and so there needs to be a new character for
each case.
> I am not sure that putting colons between each case is really necessary
though.

Most of us (including you and I) like a form that starts with " let val =
condition ? " like the existing ternary. Let's say a proposal like that
gets accepted... I really believe "colons as separators" is the best idea
in the case. Otherwise, it gets pretty confusing.. we'll have the existing
ternary where a colon does one thing, and our new "extra ternary" where it
does something else.

This is why I like colons (this won't make sense unless your email has rich
text to show the colors):

* let val = color ? *

*.Red !**  0xFF : *

*.Green !**  0x00FF00 : *

*_ !**  0xFF*

... no syntax here different from the existing except the addition "
*.Red !* ". As for the exclamation... Swift already uses an exclamation for
a billion other things, which is unfortunate. But the same can be said of
"?" and that's already used in a "switch" without causing confusion.

> To point 1: I agree it needs a new name, I came up with the “demux
expression”

> but maybe there is a better name.

Has anyone suggested "multiary expression" yet? Seems in keeping with
"ternary"
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

> multiary is not a natural and easy expression to pronounce.

I'd be fine with "match expression". Also fine with "multary" (no "i"),
which is apparently a common alternative to "multiary."

If we use the "colon as separator" version of this proposal, which uses the
existing syntax for a ternary, I'd prefer we just called it a "ternary" or
a "[something] ternary". Granted with 3+ terms, it's a misnomer, but it's
not hard to imagine someone saying "Oh, when you write a Ternary in Swift,
you can add conditions to it." I'm quite sure "ternary" is the first thing
you would Google, if you came across the kind of expression we're proposing.



On Wed, Jan 6, 2016 at 7:39 PM, Craig Cruden <ccru...@novafore.com> wrote:

> multiary is not a natural and easy expression to pronounce.
>
> ternary was likely used originally because they could not think of
> something better - but at least it is easy on the tongue…. [composed of 3
> parts]
>
> regardless of syntax - maybe just call it a “match expression”.
>
>
> On 2016-01-07, at 10:06:46, Charles Constant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> > I see what you are trying to do, because of the colon being both used
> for switch cases and
> > separators for the ternary and so there needs to be a new character for
> each case.
> > I am not sure that putting colons between each case is really necessary
> though.
>
> Most of us (including you and I) like a form that starts with " let val =
> condition ? " like the existing ternary. Let's say a proposal like that
> gets accepted... I really believe "colons as separators" is the best idea
> in the case. Otherwise, it gets pretty confusing.. we'll have the existing
> ternary where a colon does one thing, and our new "extra ternary" where it
> does something else.
>
> This is why I like colons (this won't make sense unless your email has
> rich text to show the colors):
>
> * let val = color ? *
> *.Red !**  0xFF : *
> *.Green !**  0x00FF00 : *
>
> *_ !**  0xFF*
>
> ... no syntax here different from the existing except the addition "
> *.Red !* ". As for the exclamation... Swift already uses an exclamation
> for a billion other things, which is unfortunate. But the same can be said
> of "?" and that's already used in a "switch" without causing confusion.
>
> > To point 1: I agree it needs a new name, I came up with the “demux
> expression”
> > but maybe there is a better name.
>
> Has anyone suggested "multiary expression" yet? Seems in keeping with
> "ternary"
>
>
>
>
>
>
> ___
> 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] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

Our ternary-like switch is now in the "commonly_proposed.md" file, which
doesn't bode very well. It puzzles me that there isn't more enthusiasm. Are
we the only ones who get irritated taking up so much space with a "switch"
when all we need to do is transform between two sets of values?

I think we need to revamp the proposal somehow to make the idea clearer,
because it ought to be pretty compelling.

• Does anyone here have better "side by side" examples of code
before/after?

• Can anyone think of a way to revise the (English) language of the
proposal to make it shorter and sweeter?

Apologies for prescribing instead of doing. My only excuse is that I'm "too
busy"




On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Good feedback, I am all for making it feel more like swift. Any ideas
> would be welcome. I will also try to come up with some myself.
>
>
> My suggestion is to leave ternary alone and try to come up with a
> ternary-like switch expression that is workable.  I think that is likely
> the best change possible at this point.
>
>
>
> On Jan 4, 2016, at 12:34 PM, Rod Brown  wrote:
>
> For all the proposals I've seen on this topic, I have to say -1.
>
> While I agree with the notions surrounding this operator, I've yet to see
> a better alternative presented, and none that feel truly Swift.
>
> If someone has a great proposal, though, I look forward to seeing it.
>
> - Rod
>
> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> -1 for me. None of it looks or feels like Swift, more like Haskell. I
> would prefer a library solution for now and remove ?: from the language and
> add a which into the standard library and see how that goes and if there is
> need for more.
>
> Sorry,
>
> Howard.
>
> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Any feedback on this? I am rethinking the idea of #( because of the #
> prior usage as a preprocessor directive, but like how it stands out and has
> a meaning.  If no feedback, does it make sense to update my proposal with
> these ideas? Or does this feel like the wrong direction.
>
>
> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  wrote:
>
> Some more ideas, this moves away from the notion that we should make it
> look really close to the ternary but keeps all the benefits of the ternary
> and improves upon it. Since I have been suggesting a breaking change, it is
> a good time to rethink it a bit. With this idea a horizontal line
> (double-dash) separates the control value from the choices, the vertical
> line (bar) indicates none of the above.
>
> Rather than use the ?( as I have suggested in the past, I think #( works
> here, where you can think of it as a numerical index. The advantage of this
> is, it stands out better and leaves ? for optionals only. This works well
> with the list form. In the enum case the index is the enum key. I can see
> that this however may be a problem because # is used for preprocessor like
> directives. I am suggesting though just the #( sequence is treated
> differently. Or the ?( is fine with me as well.
>
> I have gone through a lot of options, some others I looked at are !( which
> could be read as "match stick” paren, where the word “match” matches a
> case, I am pretty sure that would not be considered any better than ?(
> because it is used for optionals. Another is “witch hat paren” ^( which can
> be read as “which”.  This might create a parse problem with "power of"
> though, which maybe using ^[ (hat square bracket) could resolve that but
> not sure if that would create other problems. Some other choices would be
> &(  and @( but did not choose them because  they don’t have meaning to me
> but they do have the advantage of standing out like the #(.
>
> let fa = #(truth -- 1 | 0) // boolean case.
> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list
> form, pick index, zero based.
> let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF |
> 0xFF) // enum form.
> let fd = #(color -- .Red:0xFF,
>   .Green:  0x00FF00,
>   .Blue:   0xFF
>  | 0xFF) // enum multiline, default: can be used here if
> preferred.
> let fe = #(color -- .Red:0xFF,
>   .Green:  0x00FF00,
>   .Blue:   0xFF) // if all cases handled, the last bar is optional
>
> This visually kind of represents what is going on. Horizontal-line directs
> eye to one of the normal choices. Vertical-line says none found stop
> looking and do the otherwise choice. Kind of like a train switch.
>
> The strong feedback was that a replacement has to be usable in places
> where a ternary could be used. So it needs to work on a single line (and
> 

Re: [swift-evolution] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

My best guesses here, since I didn't write and don't entirely agree...

*> Please detail what the trade offs are*

Other than more complexity, I think this refers to making the "switch"
statement do two slightly different things. Of course, if we call it
something else, like "match" or "which" then it stops being an issue.

*> What are the other ways that Swift currently supports this?*

As far as I can see, the closest we get are...

a) The existing "switch" statement, or if else statement (preceded with
a statement to declare the variable. yuck). I think this is verbose enough
to qualify as "confusing"

b) Creating an anonymous dict, and immediately accessing it (which
means the keys need to be Hashable). This isn't very flexible

c) Creating a special init or function, to map one enum, to another.
This  is also verbose, and not flexible, and moves the code away from where
it used (even if you never reuse the mapping).

d) Chaining a bunch of conditions in a ternary... Horrible.

Anyone know of any better alternatives? It feels like I'm missing something.









On Mon, Jan 4, 2016 at 10:34 PM, Paul Ossenbruggen  wrote:

> This is what is on the Commonly Rejected Changes section:
>
>-
>
>Replace ?: Ternary Operator
>
> :
>Definitely magical, but it serves a very important use-case for terse
>selection of different values. Proposals for alternatives have been
>intensely discussed, but none have been "better enough" for it to make
>sense to diverge from the precedent established by the C family of
>languages.
>-
>
>if/else and switch as expressions
>
> :
>These are conceptually interesting things to support, but many of the
>problems solved by making these into expressions are already solved in
>Swift in other ways. Making them expressions introduces significant
>tradeoffs, and on balance, we haven't found a design that is clearly better
>than what we have so far.
>
> Please detail what the trade offs are in making them expressions. What are
> the other ways that Swift currently supports this?
>
> - Paul
>
>
> On Jan 4, 2016, at 4:42 PM, Paul Ossenbruggen  wrote:
>
> I can work on making the proposal shorter if that will help.  Any
> suggestions, for what could be made better. I am trying to be detailed but
> maybe that is making it too long.
>
> I am also not sure why this is not getting people excited. This seems like
> a clear win to me just being able to use  auto type inference when
> initializing it compared to switch statements is huge. I feel like I have
> tried to address most of the objections and what I am suggesting is quite a
> bit better than ternary, but with any solution there will be something that
> involves a trade off, these are problems with ternary as well.
>
> • terse but hard to understand.
> • more descriptive but longer.
>
> These are conflicting problems and you can’t solve both but there is
> nothing so magical about the ternary that I can see. The problems I see
> with ternary:
>
> • hard to see beginning and end **
> • not immediately obvious what it does
> • can’t be searched on the web **
> • only supports boolean and can’t support more than two outcomes. **
> • does not support switch like capabilities **
>
> Good aspects of ternary:
> • Terse **
> • Fits in small places can be formatted multiline or single line. **
> • guarantees the return type is compatible. **
> • it is well known by C like language users
> • it does not interrupt the control flow like an if statement does. So the
> code is linear. **
> • you are guaranteed a result. **
> • Automatically will infer type when binding a name. **
> • reduces duplicated code. **
> • quick conversions are possible. **
>
> All the items with ** stars next to them are addressed with the proposal
> others are no worse than ternary.
>
> And it adds some things:
> • Adds switch expressions
> • Adds using a zero based index to execute an expression.
> • Lets you easily see begin and end of the expression
> • Different but better
> • Supports more than two outcomes.
>
> Downsides:
> • breaking change (I think there is value in a unified approach to doing
> expressions like this, we could leave ternary alone and adapt the rest of
> the proposal though, this has the downside that there are two ways of doing
> booleans though).
> • not as immediately as familiar as ternary (but similar enough that
> anyone who knows about ternary will quickly adapt).
>
> On Jan 4, 2016, at 3:45 PM, Charles Constant 
> wrote:
>
> Our ternary-like switch is now in the "commonly_proposed.md" file, which
> doesn't bode very well. It puzzles me that there isn't more enthusiasm. Are
> we the only ones who get irritated taking up so much space with a "switch"

Re: [swift-evolution] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

I'm with Matthew/Craig.

We discussed a couple very ternary-like versions earlier in the thread,
which I increasingly think are the best options.

The major objection to this came from Lattner, and his objection, if I have
it right, is "this proposal doesn't add enough functionality to justify the
additional complexity/confusion"

The sticking point, at the moment, is formulating a really persuasive
argument for "why we need this." If we can't do that, this proposal is dead.






On Tue, Dec 29, 2015 at 5:38 AM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Dec 29, 2015, at 7:28 AM, Craig Cruden via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> That looks pretty ugly.
>
> I think the best we can hope for at this point is maybe another keyword
> that mirrors switch but is expression based (aka match) — leaving the
> ternary ? : expression as is - which is not all that bad since any if else
> that becomes a compound expression or more than two resultant values
> (chaining) quickly becomes a mess.
>
>
> I agree that this is probably the best path forward at the moment.  There
> was a post early on showing a ternary-like switch expression.  I don't
> remember whether there were any specific problems with that idea or not,
> but if there aren't that might best route forward.
>
>
> I am not sure that even a “match” expression would be accepted at this
> point because there seems to be general resistance to anything more than
> the existing paradigm with a few functional decorations — and the way of
> doing things is good enough.
>
> Concurrency is also currently off the table at this point -- the fact that
> immutable pure functional code can theoretically be parsed into a
> dependance graph which would allow for out of order [within scope] parallel
> execution on different threads [not sure if the overhead of doing so would
> outweigh the benefits]…. would also not be of sufficient benefit.
>
> The primary focus of Swift is a language for UI development, not server
> development….
>
>
> On 2015-12-29, at 15:07:57, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What if you could wrap the existing switch statement in a closure and
> return a value from that closure like so
>
> Let value = { switch (other) {
> Case .Some(let value):
> Return value // because this is in a closure the closure will return the
> value not the function this is in
> Case .None:
> Return "hello"
> }}
>
>
> Sent from my iPhone
>
> On 29 Dec 2015, at 07:53, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> You can replace the proposed statement `which` (another thread), the
> existing statement `?:` (this thread), and the global function `??` (which
> is an odd ball) with matching library methods.
>
> A library method is likely slower than a built in at this stage until the
> optimiser improves, but a library function:
>
>
>1. Is documented right in the IDE including code completion,
>statements aren’t (you don’t see quick help for `for`!)
>2. Having a library function allows the use case to be throughly
>investigated. Is worth while as a language statement? What exact features
>are useful? EG should `which` support pattern matching, general boolean
>expressions, or simply be `Equatable` as shown below?
>3. It is simpler to implement, maintain, and change a library function
>that a built-in.
>4. There is no need for a keyword.
>
>
> First `which`:
>
> // Alternative to introducing `which` statement
>
> final
> class Which {
> private
> var result: R?
>
>
> private
> let which: I
>
>
> init(_ which: I) {
> self.which = which
> }
>
>
> func match(value: I, @noescape matchResult: () throws -> R) rethrows
>  -> Self {
> if self.result == nil && self.which == value {
> self.result = try matchResult()
> }
> return self
> }
>
>
> func matchDefault(@noescape defaultResult: () throws -> R) rethrows
>  -> R {
> switch self.result {
> case .None:
> return try defaultResult()
> case .Some(let value):
> return value
> }
> }
> }
>
>
> // Demo
> enum Color {
> case Red, Blue, Green
> }
>
> // Which with a default value
> let i1 = Which(Color.Red) // i = 16711680
> .match(.Red)   { 0xFF }
> .match(.Green) { 0x00FF00 }
> .match(.Blue)  { 0x0FF }
> .matchDefault  { 0 }
>
> // Which that throws an error if it defaults
> let i2: Int! = Which(Color.Green) // i = 16711680
> .match(.Red)   { 0xFF }
> .match(.Green) { 0x00FF00 }
> .match(.Blue)  { 0x0FF }
> .matchDefault  { nil }  // Cant type call to fatalError as no return,
> hence nil and type Int! (note !)
>
>
> Note runtime check for default rather than static check via compiler, not
> as good but not a big deal most of the time. The vast majority of 

Re: [swift-evolution] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

> In the case where your input is hashable, you could just do:
>
> let i = [.Red:0xff, .Green:0x00ff00, .Blue:0xff][color]

You forgot to declare the type, which is mandatory if you want to use
abbreviated cases like ".Red" to construct a one-off like that. That's one
of the reasons I complained that using a Dictionary is not a pleasant
alternative earlier on. The proposal ought to infer the enum Type, just
like a normal Switch statement.

On top of that, the limitations you mention also limit usefulness.

If it weren't for these issues, it would be good enough for me.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ternary operator ?: suggestion

[Charles Constant via swift-evolution]

> In the case where your input is hashable, you could just do:
>
> let i = [.Red:0xff, .Green:0x00ff00, .Blue:0xff][color]

Mea culpa: you were correct, this actually *does* work in a Playground, as
long as you access it when you construct it.

I didn't realize Swift was smart enough to infer a one-off Dict by its key.
Thanks Lattner & co! That is extremely cool :)

So that just leaves the fact that the Keys need to be hashable / not
optional.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Charles Constant via swift-evolution]

When I started using Swift, and wanted to learn the syntax for closures, I
found the "in" token very confusing. I probably would have figured it out
at least a half hour sooner, if it had been a different word, or an
operator. I kept thinking "that can't be right, I must be misinterpreting
the documentation"

Once you learn the syntax once, it's not a practical issue ever again.
Still, it's kinder to new learners, and reads better, if the syntax uses
something other than "in"


On Tue, Dec 22, 2015 at 1:54 AM, Daniel Valls Estella via swift-evolution <
swift-evolution@swift.org> wrote:

> Just to add my point of view as language user. I don’t know so much about
> compilers and neither have many familiarity with language grammars. I like
> to  learn, and this list helps.
>
> I think clousures are strangely written and break some coherence. I agree
> with Alexander on that.
> But I don’t like the proposed solution.
>
> In the other side, I think trailing closures are a really a great feature,
> I like a lot.
> But I feel it’s a bit confusing in some way, as Alexander pointed. As if
> it was the body definition of the called function.
>
> To throw an idea, the *with* keyword:
>
>
> with (  *parameters* ) -> *return_type* {
> *statements*
> }
>
>
> sorted = names.sort( *with*(s1: String, s2: String) -> Bool {
> return s1 > s2
> })
>
>
> sorted = names.sort( *with*(s1, s2){  return s1 > s2 } )
>
>
> reversed = names.sort( *with*(s1, s2){ s1 > s2 } )
>
>
> reversed = names.sort( { $0 > $1 } )
> OR? reversed = names.sort( *with*{ $0 > $1 } )
>
>
> reversed = names.sort(>)
> OR? reversed = names.sort(*with* >)
>
>
> reversed = names.sort()  *with* { $0 > $1 }   // I think clarifies it is
> an input to exeute not a definition
>
>
> reversed = names.sort *with* { $0 > $1 }  // I think clarifies it is an
> input to exeute not a definition
>
>
> Thanks!
>
>
> Daniel
>
>
> Daniel Valls Estella · tel. 659.910.830 · dan...@upzzle.com
>
> El 22 des 2015, a les 7:57, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> va escriure:
>
> Well, I'm actually happy with the current closure syntax as it allows very
> succinct simple cases and trailing closures as Chris has already pointed
> out.
>
> Am 21.12.2015 um 23:44 schrieb Alexander Regueiro via swift-evolution <
> swift-evolution@swift.org>:
>
> Okay, I assume you are aware this essentially the same syntax as used in
> languages like C# and Python, yes? I’m not sure there are any problems in
> those languages with it.
>
> If you dig through (very early) history you’ll see that we had this.
> There are a couple of problems with it:
>
> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of
> simple map and filter closures.
>
>
> Not really. The above example would just be `X.sort func { $1 < $0 }” or
> "X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to
> have all operators implicitly
>
>
> Having "func" or the backslash crammed in there is really ugly and
> unreadable IMHO.
>
> And in Haskell you don't have braces for the body to begin with and you
> would have to enclose the closure in parenthesis if it is part of an
> expression like your examples so in effect it would look quite similar,
> i.e. having the parameters within the parenthesis (sure, the semantics are
> different, but I made argument just to demonstrate that what looks good in
> one syntactic environment might not look good in another).
>
> 2) It reads really weird in trailing closure cases.
>
>
> Honestly, I strongly dislike trailing closures. I don’t think they add
> much, and moreover they use a confusing syntax that make the whole function
> call look superficially like a function declaration (or indeed the whole
> thing being a closure).
>
>
> Trailing closures are a great feature IMHO because they make the code much
> more readable by allowing constructs to look similar to control flow
> statements.
> This allows creating very readable DSLs.
>
>
> Lets step back: What problems are you trying to solve with the current
> closure syntax?
>
>
> Readability, mainly. I think this is a big improvement.
>
>
> Well, I think it's the opposite for the simple cases and for trailing
> closures.
>
>
> Then there’s similarity with other languages, which is minor, but nice. I
> don’t know any language that uses a syntax like the current one of Swift.
>
>
> Smalltalk and Ruby immediately come to mind and I'm sure there are others.
>
> Scala has a trailing closure syntax which is similar to Swift's syntax as
> well.
>
> -Thorsten
> ___
> 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

Re: [swift-evolution] Brace syntax

[Charles Constant via swift-evolution]

> just not sure weather it would be good to put more complexity into Xcode

Braceless mode is sort of a special case. It could be useful, even for
people prefer braces, to temporarily hide some of the more, uh, decorative
elements - and vice versa.

The option to switch back and forth, for braces/significant whitespace is
helpful to both sides. As much as I like Python, it would be cool to be
able to "turn on braces" and double-check some section of my code with an
unusually high number of indentations. Likewise, I can imagine it being
useful to get rid of some vertical space for someone who otherwise likes
braces - e.g.: to scan through a Class that has a large number of getters /
setters (which just love to barf out newlines with braces in Swift).

And it would be quite like Apple to brand it "Pseudo-Code View" or
something.






On Sun, Dec 20, 2015 at 3:48 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> -1, I like braces
>
> But it's interesting to see that there are many wishes that could be
> addressed quite easily by the IDE:
> Mandatory self, braces, optional return keyword… just not sure weather it
> would be good to put more complexity into Xcode than into the compiler ;-)
> ___
> 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] Brace syntax

[Charles Constant via swift-evolution]

Andrey's post encourages me to veer into the merits of significant
whitespace vs braces. This is probably unwise of me, since we're not all
going to agree any time soon, but I can't resist pointing out an example:



var foo: Int
{
get
{
return _foo
}
set
{
_foo = newValue
}
}



var foo: Int:
get:
return _foo
set:
_foo = newValue



It's obvious no programmer is going to be consistent about braces in the
first example - it's absurdly verbose. So with braces in Swift, pretty much
everything you write carries the overhead of "what inconsistent way will i
format the braces for this code?" For me, I'd rather throw out the (largely
redundant) noise, and stick with just the content.






On Sun, Dec 20, 2015 at 3:59 AM, Andrey Tarantsov via swift-evolution <
swift-evolution@swift.org> wrote:

> I don't know many people who have experienced a large variety (8+?) of
> programming languages and prefer Python's forced indentation
>
>
> Count me as one. I'd prefer Swift to have Python-style indentation, just
> on the grounds of braces being stupid (why would you want to enter the same
> scope information *twice*)?
>
> So +1 from me, although I don't suffer from the braces at all.
>
> I do want to point out that the amount of code that fits on a screen *is* 
> fairly
> important, and you should keep your methods short, so one less brace per
> method means a couple more methods per screen.
>
> This would also free up braces to mean “closure” in 100% of cases, which
> is good for consistency.
>
> But it would introduce it's share of problems for sure, so I don't feel
> strongly about this proposal.
>
> I also admit that braces are generally preferred, for some mysterious
> reason that I hope a believer can articulate here. Take Sass, for example;
> it has both an indentation-based syntax and a braces-based syntax, and the
> latter one seems way more popular.
>
> A.
>
>
> ___
> 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] Brace syntax

[Charles Constant via swift-evolution]

Yes, that is the point. If you use braces in Swift, you will naturally
gravitate to all sorts of personalized strategies. Now this is possible
with significant whitespace (e.g.: Python uses the semicolon to put
multiple statements on the same line) but not nearly as common.


On Sun, Dec 20, 2015 at 4:22 AM, Tino Heth <2...@gmx.de> wrote:

>
> var foo: Int
> {
> get
> {
> return _foo
> }
> set
> {
> _foo = newValue
> }
> }
>
> I assume you know that braces don't require an extra line for themselves?
> ;-)
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Using "where" to filter an array

[Charles Constant via swift-evolution]

Thanks Charles ,

I know it's possible to do the same thing with filter. The syntax I drew
attention to would be an alternate way.

My only rationale is that, if it works in one place, it ought to work
everywhere. The redundancy bothers me too, but since the concept exists, we
may as well allow it everywhere. Otherwise, it's still redundant in a "for"
loop (maybe performance is better, but that could be optimized?), but also
inconsistent because it seems intuitively like it ought to create a subset
whereas in reality it is illegal.

Does it bother anyone else, or am I nitpicking?

On Sat, Dec 19, 2015 at 7:52 PM, Charles Srstka <cocoa...@charlessoft.com>
wrote:

> On Dec 19, 2015, at 9:43 PM, Charles Constant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> I noticed several weeks ago that the following is illegal:
>
> let new_arr = el in arr where el.is_foo // illegal
>
> I assumed it would work because it's consistent with the filtering that
> exists in a "for" loop, i.e.:
>
> for el in arr where el.is_foo // legal
>
> Is this "new proposal" material? I thought I would check in case it's
> already on the roadmap, or inherently wrong.
>
>
> I believe what you want is already possible via the “filter” method.
>
> Charles
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Brace syntax

[Charles Constant via swift-evolution]

This entire thread is just beating dead horse. Having said that; why not
allow braces for closures, and disallow them elsewhere? It doesn't seem
like a deal-breaker, really. I don't think there's much to debate aside
from this: some people worry that significant whitespace makes code more
error-prone, and others feel the increased legibility makes it less
error-prone.

On Sat, Dec 19, 2015 at 5:58 PM, Kevin Ballard via swift-evolution <
swift-evolution@swift.org> wrote:

> There is not in fact an emphasis on conciseness. This has been repeated
> many times by the swift team. Conciseness is not a goal of Swift, but
> expressiveness absolutely is. Braces are a well-understood and simple way
> to express the notion of a scope/closure. And FWIW removing braces means
> you have to come up with a completely different syntax for closures,
> because indentation does not suffice there.
>
> Also, "don't be like C" is not even remotely a goal of Swift. The Swift
> syntax is C-like in many respects. "Be like C" isn't a goal either of
> course, but when deciding between two alternatives that have no compelling
> arguments either way, picking the one that would be more familiar to Obj-C
> programmers is usually a good idea.
>
> -Kevin Ballard
>
> On Sat, Dec 19, 2015, at 05:39 PM, Alexander Regueiro via swift-evolution
> wrote:
> > Has anyone considered removing braces from the Swift language? The main
> alternative would be indentation-based scoping like in Python or Ruby.
> There already seems to be a general emphasis on conciseness,  lack of
> redundancy, and a modern syntax. e.g. semicolons are not required for
> single-line statements; brackets have been removed from if/for/while
> expressions, compared to C-style syntax. So, why not go the whole way in
> breaking the C-style connection? The present syntax seems to be shunning C,
> but only slightly.
> >
> > Thoughts?
> > ___
> > 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] Using "where" to filter an array

[Charles Constant via swift-evolution]

I noticed several weeks ago that the following is illegal:

let new_arr = el in arr where el.is_foo // illegal

I assumed it would work because it's consistent with the filtering that
exists in a "for" loop, i.e.:

for el in arr where el.is_foo // legal

Is this "new proposal" material? I thought I would check in case it's
already on the roadmap, or inherently wrong.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Brace syntax

[Charles Constant via swift-evolution]

+1 fwiw

Grr, I hate braces so much I can't even... but I've seen this discussed on
the Apple dev forums. It's not going to happen. I think the best we (those
of us who dislike braces) can ever hope for is that Xcode gives us a way to
view our code in the IDE as though braces didn't exists - even if the
underlying file uses them, and probably the clipboard so that the outside
world can have "one way" of writing Swift. I doubt that will happen either,
but it seems far more likely to me than that Swift will suddenly do a 180
on something I'm sure Chris and the rest considered at length already.



On Sat, Dec 19, 2015 at 5:39 PM, Alexander Regueiro via swift-evolution <
swift-evolution@swift.org> wrote:

> Has anyone considered removing braces from the Swift language? The main
> alternative would be indentation-based scoping like in Python or Ruby.
> There already seems to be a general emphasis on conciseness,  lack of
> redundancy, and a modern syntax. e.g. semicolons are not required for
> single-line statements; brackets have been removed from if/for/while
> expressions, compared to C-style syntax. So, why not go the whole way in
> breaking the C-style connection? The present syntax seems to be shunning C,
> but only slightly.
>
> Thoughts?
> ___
> 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