Re: [swift-evolution] [Pitch] Percentage Type

[Saagar Jha via swift-evolution]

Saagar Jha

> On Jan 17, 2018, at 16:56, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Wed, Jan 17, 2018 at 2:04 AM, David Sweeris  > wrote:
> 
> 
> Sent from my iPhone
> 
> > On Jan 16, 2018, at 23:45, Jonathan Hull via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > Mainly semantics.
> >
> > We could technically use Int instead of having a Bool type (just using 1 
> > and 0).  We don’t do that since Int and Bool have intrinsically different 
> > meanings in code.
> >
> > What I am saying is that parameters that take the range 0 to 1 typically 
> > have a fundamentally different meaning (or at least a different way of 
> > thinking about them) than Doubles.  It would be nice to be able to see that 
> > distinction when using APIs.
> >
> > With both this and the Angle type, I am pointing out areas where, due to 
> > historical reasons in C, we have conflated a bunch of types which have 
> > different behavior, and then just expect programmers to be conscientious 
> > enough to use them correctly in each case.  These types/numbers all have a 
> > different forms of dimensionality.
> >
> > I’d like to discuss that before we lock everything down.
> 
> +1 (although I think a “normalized to [0, 1]” type would be more useful than 
> a “percentage” type)
> 
> Bool is not a good example; it permits precisely two logical values (0 and 
> 1). By contrast, if you're going to support 1000%, then your type supports 
> the same values as the underlying storage. As I wrote in a different thread, 
> one way to look at a type is the set of values that a variable can have.
> 
> What is your limiting principle here if you think that a range that's not 
> enforced makes a value become of a different type? Often, a 1-5 rating system 
> is used. Sometimes, it's 1-4 or 1-10. And of course, a "3" on a 1-5 scale 
> means something very different from a "3" on a 1-10 scale. Should 
> ScaleFrom1To5 be its own type? And also ScaleFrom1To4 and ScaleFrom1To10?

Just a thought: if Swift ever allows integer literals in generics (e.g. for a 
fixed size array equivalent to C++’s std::array), this seems like how a type 
like ScaleFrom (and a percent type, for that matter) could be implemented.

> 
> Besides, even supposing a percentage type would be in high demand, there's no 
> need for its inclusion in the standard library. It's very easy to implement 
> on your own in a third-party library. Moreover, custom operators will allow 
> you to define a postfix `%`, and then you could write: `let x = 100%`. Throw 
> in some heterogeneous arithmetic operators and you could do almost any math 
> you want.
> ___
> 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] Protocol conformance error

[Saagar Jha via swift-evolution]

Interestingly, it seems like Swift allows for contravariance for subclassing, 
in that this is valid code:

protocol A {}
protocol B: A {}

class C { // Notice this is a class, not a protocol
   func test(x: B) {}
}

class M: C {
   func test(x: A) {}
}

Is it an oversight that this doesn’t apply to protocols?

Saagar Jha

> On Jan 17, 2018, at 11:38, Paul Cantrell  wrote:
> 
> Note that it would be sound for the language to allow the opposite, which is 
> called “contravariance” (the more specific type takes a more general input):
> 
> protocol A {}
> protocol B: A {}
> 
> protocol C {
>func test(x: B)// was A
> }
> 
> class M: C {
>func test(x: A) {} // was B
> }
> 
> It could also allow covariant return types (the more specific type returns a 
> more specific output):
> 
> protocol C {
>func test() -> A
> }
> 
> class M: C {
>func test() -> B {
>   fatalError("just a stub")
>}
> }
> 
> Some languages support this, and Swift certainly could — though I don’t know 
> that it’s a frequently request feature.
> 
> It would also be interesting if associated type constraints allowed this, 
> which I don’t think they currently do:
> 
> protocol C {
>associatedtype TestInput where B: TestInput   // error here
> 
>func test(x: TestInput)
> }
> 
> Curiously, the following does not work, although it seems like it should:
> 
> protocol A {}
> protocol B: A {}
> 
> protocol C {
>associatedtype TestOutput: A
> 
>func test() -> TestOutput
> }
> 
> class M: C {
>func test() -> B {
>   fatalError("just a stub")
>}
> }
> 
> It gives the error “inferred type 'B' (by matching requirement 'test()') is 
> invalid: does not conform to ‘A’” even though B does conform to A. Huh.
> 
> Cheers, P
> 
> 
>> On Jan 17, 2018, at 2:43 AM, Saagar Jha via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> If we have:
>> 
>> class N: A {}
>> 
>> you can pass an N into C’s test(x:), since N is an A, but not M’s test(x:), 
>> since N is not a B. Thus, it’s not a valid conformance.
>> 
>> Saagar Jha
>> 
>>> On Jan 17, 2018, at 00:04, Roshan via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> Cross posting from swift-users in case this behaviour isn't part of
>>> the language and might be interesting to you folks.
>>> 
>>> Here is some sample code that gives a protocol conformance error in a
>>> playground:
>>> 
>>> protocol A {}
>>> protocol B: A {}
>>> 
>>> protocol C {
>>>func test(x: A)
>>> }
>>> 
>>> class M: C {
>>>func test(x: B) {}
>>> }
>>> 
>>> Is there a reason why the compiler doesn't infer that ((B) -> ())
>>> matches ((A) -> ()) because of inheritance?
>>> 
>>> -- 
>>> Warm regards
>>> Roshan
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] Protocol conformance error

[Saagar Jha via swift-evolution]

If we have:

class N: A {}

you can pass an N into C’s test(x:), since N is an A, but not M’s test(x:), 
since N is not a B. Thus, it’s not a valid conformance.

Saagar Jha

> On Jan 17, 2018, at 00:04, Roshan via swift-evolution 
>  wrote:
> 
> Hi,
> 
> Cross posting from swift-users in case this behaviour isn't part of
> the language and might be interesting to you folks.
> 
> Here is some sample code that gives a protocol conformance error in a
> playground:
> 
> protocol A {}
> protocol B: A {}
> 
> protocol C {
>func test(x: A)
> }
> 
> class M: C {
>func test(x: B) {}
> }
> 
> Is there a reason why the compiler doesn't infer that ((B) -> ())
> matches ((A) -> ()) because of inheritance?
> 
> -- 
> Warm regards
> Roshan
> ___
> 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] No disjunctions in type constraints: why?

[Saagar Jha via swift-evolution]

The “Swifty” way of doing such a thing is to have the types you care about 
conform to a protocol that clearly defines the API you’re trying to expose. For 
example:

protocol Fooable {
func doFoo()
}

extension Int: Fooable {
func doFoo() {
print("I’m an Int")
}
}

extension String: Fooable {
func doFoo() {
print("I’m a String")
}
}

Now, instead of a disjunctive Int | String union type you can just use Fooable 
and call doFoo on it when necessary:

func doSomethingWithAFooable(_ foo: Fooable) {
foo.doFoo()
}

doSomethingWithAFooable(0) // prints: I’m an Int
doSomethingWithAFooable("") // prints: I’m a String

Saagar Jha

> On Jan 13, 2018, at 01:45, Daryle Walker via swift-evolution 
>  wrote:
> 
> From 
>   
> >.
> 
> Maybe I’m not up on my Type Theory, but why should type constraint 
> disjunctions be banned?
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT 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] [Proposal] Revamp the playground quicklook APIs

[Saagar Jha via swift-evolution]

CustomPlaygroundRepresentationConvertible?

Saagar Jha

> On Jan 11, 2018, at 11:22, Connor Wakamo via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 10, 2018, at 4:21 PM, Chris Lattner > > wrote:
>> 
>>> On Jan 10, 2018, at 2:10 PM, Connor Wakamo >> > wrote:
 What is the use-case for a type conforming to this protocol but returning 
 nil?  If there is a use case for that, why not have such an implementation 
 return “self” instead?
>>> 
>>> Riley and Saagar answered this down-thread, but to confirm — returning nil 
>>> would allow some instances of a type to use the “default” playground 
>>> logging presentation while others use an alternate presentation instead.
>> 
>> Right, this gets back to the question: what is the use case for this?  When 
>> would a type want to “sometimes” replace the default representation?
>> 
>> It seems to me that a type author either wants to take control of 
>> presentation or not.  While I’m sure we could imagine some use case for the 
>> behavior you’re describing, is it big enough to make it worth complicating 
>> the API?
>> 
>>> 
>>> This isn’t handled by `return self` because, unless I’m mistaken, there’s 
>>> no way to detect that from the caller’s side (e.g. with two `Any` values, I 
>>> can’t do `self === self.playgroundRepresentation`). 
>> 
>> Ok
>> 
 In short, can we change playgroundRepresentation to return Any instead of 
 Any?.  Among other things, doing so could ease the case of playground 
 formatting Optional itself, which should presumably get a conditional 
 conformance to this.  :-)
>>> 
>>> I don’t think we can change this to return `Any` instead of `Any?`. I think 
>>> there are potentially cases where a developer might want to selectively 
>>> opt-in to this behavior.
>> 
>> Which cases?  How important are they?
> 
> I can think of a couple of cases where this could be useful.
> 
> The first is an enum. Extending Riley’s example from earlier in the thread:
> 
>   enum MyUnion {
>   case string(String)
>   case image(UIImage)
>   case intPair(Int, Int)
>   case none
>   }
> 
> This enum might want to present the string and image cases as strings and 
> images, but treat the intPair and none cases the “default” way for the enum. 
> This is probably not the most compelling example as there is a workaround — 
> return a second enum or other structured type from playgroundRepresentation — 
> but that feels not great.
> 
> The second case, and the one I’m more worried about, is subclassing. If, for 
> instance, you have the following:
> 
>   class FooView: UIView, CustomPlaygroundRepresentable {
>   var playgroundRepresentation: Any {
>   return “A string describing this view"
>   }
>   }
> 
>   class BarView: FooView {
>   override var playgroundRepresentation: Any {
>   // BarView instances wanted to be logged as themselves, 
> but there’s no way to express that
>   return ???
>   }
>   }
> 
> There’s nothing that BarView can do to ensure it gets logged like a view 
> because FooView declared a conformance to CustomPlaygroundRepresentable.
> 
> I’m not sure how important these cases are. If it were just the first one, 
> I’d probably say we can safely ignore it because there’s a reasonable 
> workaround. But the subclassing case worries me because there’s no escape 
> hatch (aside from a potential implementation-defined failsafe).
> 
> 
>>> I also don’t think that `Optional` would get a conditional conformance to 
>>> this. I’m not proposing that any standard library or corelibs types gain 
>>> conformances to this protocol. Instead, it’s up to a playground logger 
>>> (such as PlaygroundLogger in swift-xcode-playground-support 
>>> ) to recognize 
>>> these types and handle them accordingly. The playground logger would look 
>>> through the `Optional` so that this would effectively be true, but ideally 
>>> the log data generated by a logger would indicate that it was wrapped by 
>>> `Optional.some`.
>> 
>> Why not?  I understand that that is how the old algorithm worked, but it 
>> contained a lot of special case hacks due to the state of Swift 1 :-).  This 
>> is a chance to dissolve those away.
> 
> It’s a feature that Optional (and other standard library/corelibs/OS types) 
> don’t conform to CustomPlaygroundRepresentable. In my mind, it’s the role of 
> the PlaygroundLogger library to understand the types for which it wishes to 
> generate an opaque representation instead of the standard/fallback structured 
> representation. So Optional, String, Int, UIColor, NSView, etc. don’t 
> themselves conform to CustomPlaygroundRepresentable — they’re not customizing 
> their presentation in a playground.
> 
> Semi-related to this proposal, I’m w

Re: [swift-evolution] [Proposal] Random Unification

[Saagar Jha via swift-evolution]

Which begs the question: why would you want to do something like this? Creating 
a “random” Double from its full range of values is an odd thing to do, and the 
fact that it is non-uniform and has irregularities like infinity and signed 
zeros makes it likely that any such usage is probably done in error (the one 
reason I can think of is if you’re trying to test your code with random 
Doubles, but I’d argue for keeping NaN in that case). Generally users are 
looking for uniform distributions or ones that follow some set pattern (e.g. 
normal, Bernoulli), so this doesn’t seem useful at all.

Saagar Jha

> On Jan 10, 2018, at 14:39, Jens Persson  wrote:
> 
> On Wed, Jan 10, 2018 at 11:27 PM, Saagar Jha  > wrote:
> Not a floating point expert, but are you sure this works? I have a feeling 
> this would lead to a distribution that’s not uniform.
> 
> 
> Yes, it would not be uniform, which is exactly what I meant by the last part 
> of: "Assuming you are ok with signed zero and infinities and "strange" bias 
> as result of IEEE 754"
> 
> Also, I think it's impossible to get a uniform distribution of all non-Nan 
> Double values (since they include +- infinity).
> 
> /Jens
> 
>  
> Saagar Jha
> 
>> On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> One additional question.  How do you ergonomically get a Double which 
>> doesn’t have a range, but also isn’t NaN?
>> 
>> 
>> Assuming you are ok with signed zero and infinities and "strange" bias as 
>> result of IEEE 754:
>> 
>> func randomNonNanDouble(using generator: R) -> 
>> Double {
>> while true {
>> let rndUInt64 = generator.next()
>> let rndDouble = Double(bitPattern: rndUInt64)
>> if rndDouble != Double.nan { return rndDouble }
>> }
>> }
>> 
>> /Jens
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 

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

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Saagar Jha via swift-evolution]

Saagar Jha

> On Jan 10, 2018, at 14:10, Connor Wakamo  wrote:
> 
>> On Jan 10, 2018, at 12:39 PM, Saagar Jha > > wrote:
>> 
>> Well, in my experience performance issues tend to come not from trying to 
>> display a single object, but when you have an aggregation of many objects. 
>> For example, displaying one Int is pretty lightweight, as is an [Int] with a 
>> handful of elements, but displaying an [Int] with million elements is not 
>> (this is assuming that collections will run the playgroundRepresentation on 
>> their individual elements as they do currently). I don’t think the current 
>> proposal can solve this issue as it’s pitched currently. (For those curious, 
>> this doesn’t have a good solution today, either: the best “solution” I’ve 
>> been able to come up with is to move performance-sensitive out into a 
>> Playground’s Sources folder, which isn’t displayed.)
> 
> Yes, this proposal does not affect this case: the playground transform will 
> still instrument all of the source code in the main source file. This 
> proposal is merely about deprecating/removing a substandard API for 
> controlling how values are presented in playgrounds with a better, more 
> flexible one. (Though see my other reply to Chris where I present an 
> alternative which could be extended to include support for disabling logging 
> altogether for an instance.)
> 
>> Fundamentally, I don’t think it’s clear what the “default” value is supposed 
>> to be: we already have three different interpretations of what it could do: 
>> do literally nothing (i.e. display an empty representation), use a 
>> superclass’s representation, or use a structural representation based on 
>> whether the type is an enum, struct, class, etc. I think we need to clear up 
>> what the default actually means (and if we even need it at all) before we 
>> can proceed.
> 
> This API is a bit wishy-washy as to what the “default” is. That’s somewhat 
> intentional — the default presentation of an arbitrary Swift value/object is 
> defined by the IDE, not by an API in Swift. I think my terminology is a bit 
> confused here, and I’ll try to address that in a revision of the proposal. 
> Let me try to clarify this a bit:
> 
> The fundamental design of playgrounds is that the compiler will insert calls 
> to a logging function which is effectively required to take an `Any`. So 
> therefore every instance of every type must be loggable by the playground 
> logger. The PlaygroundLogger framework in swift-xcode-playground-support 
>  implements this by 
> generating either structured log entries using `Mirror` or specialized, 
> opaque (aka IDERepr) log entries. PlaygroundLogger will generate a structured 
> log entry for most instances, but for instances of special types it knows 
> about (e.g. String, Int, NSColor, UIView, etc.) it will generate an opaque 
> log entry which an IDE can then consume and display as is appropriate.
> 
> The CustomPlaygroundRepresentable API I’ve proposed does exactly one thing: 
> it allows instances of conforming types to provide an optional stand-in to be 
> used by the playground logger. So PlaygroundLogger would handle the following 
> cases thusly:
> 
>   - If a type conforms to CustomPlaygroundRepresentable and returns a 
> non-nil value, PlaygroundLogger will generate the appropriate log entry for 
> the returned value
>   - If a type conforms to CustomPlaygroundRepresentable and returns nil, 
> PlaygroundLogger will generate the appropriate log entry for `self`
>   - If `self` is one of the types (or a subclass of one of the 
> types) for which PlaygroundLogger generates an opaque entry, PlaygroundLogger 
> will generate an opaque log entry
>   - Otherwise, PlaygroundLogger will generate a structured log 
> entry

Just wanted to make it totally clear here: is the superclass selected the one 
that is the closest to the current type, or the one that is the most distant 
parent? Referring back to the example I had further upthread:

class FooView: UIView {
override var playgroundRepresentation: Any? {
return “foo”
}
}

class BarView: FooView {
override var playgroundRepresentation: Any? {
return nil
}
}

Does BarView show up as a UIView, or a FooView? If it’s shown as a FooView, 
then returning nil is superfluous: you can just not override 
playgroundRepresentation and it’ll pick up the one from FooView.

> 
> This process if potentially recursive (likely up to an implementation-defined 
> limit): if `Foo: CustomPlaygroundRepresentable` and `Bar: 
> CustomPlaygroundRepresentable`, and a `Foo` instance returns an instance of 
> `Bar` from `playgroundRepresentation`, then the playground logger should 
> effectively log `self.playgroundRepresentation.playgroundRepresentation`.
> 
> Connor

___
swift-

Re: [swift-evolution] [Proposal] Random Unification

[Saagar Jha via swift-evolution]

Not a floating point expert, but are you sure this works? I have a feeling this 
would lead to a distribution that’s not uniform.

Saagar Jha

> On Jan 10, 2018, at 14:07, Jens Persson via swift-evolution 
>  wrote:
> 
> On Tue, Jan 9, 2018 at 10:07 PM, Jonathan Hull via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> One additional question.  How do you ergonomically get a Double which doesn’t 
> have a range, but also isn’t NaN?
> 
> 
> Assuming you are ok with signed zero and infinities and "strange" bias as 
> result of IEEE 754:
> 
> func randomNonNanDouble(using generator: R) -> 
> Double {
> while true {
> let rndUInt64 = generator.next()
> let rndDouble = Double(bitPattern: rndUInt64)
> if rndDouble != Double.nan { return rndDouble }
> }
> }
> 
> /Jens
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Saagar Jha via swift-evolution]

Well, in my experience performance issues tend to come not from trying to 
display a single object, but when you have an aggregation of many objects. For 
example, displaying one Int is pretty lightweight, as is an [Int] with a 
handful of elements, but displaying an [Int] with million elements is not (this 
is assuming that collections will run the playgroundRepresentation on their 
individual elements as they do currently). I don’t think the current proposal 
can solve this issue as it’s pitched currently. (For those curious, this 
doesn’t have a good solution today, either: the best “solution” I’ve been able 
to come up with is to move performance-sensitive out into a Playground’s 
Sources folder, which isn’t displayed.)

Fundamentally, I don’t think it’s clear what the “default” value is supposed to 
be: we already have three different interpretations of what it could do: do 
literally nothing (i.e. display an empty representation), use a superclass’s 
representation, or use a structural representation based on whether the type is 
an enum, struct, class, etc. I think we need to clear up what the default 
actually means (and if we even need it at all) before we can proceed.

Saagar Jha

> On Jan 10, 2018, at 10:02, Chris Lattner  wrote:
> 
>> On Jan 9, 2018, at 11:30 PM, Saagar Jha  wrote:
>>> 
>>> In short, can we change playgroundRepresentation to return Any instead of 
>>> Any?.  Among other things, doing so could ease the case of playground 
>>> formatting Optional itself, which should presumably get a conditional 
>>> conformance to this.  :-)
>> 
>> I believe the rationale behind this was to provide a way to “opt-out” of a 
>> customized representation, although now that I think about it, what exactly 
>> does the default mean? In particular, what happens in this case?
> 
> If you want a type to display as nothing (e.g. to avoid the perf impact of 
> formatting it) just make the playground representation be an empty string or 
> something.
> 
> -Chris
> 
> 

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

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Saagar Jha via swift-evolution]

Saagar Jha

> On Jan 9, 2018, at 22:02, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>> Good afternoon,
> 
> Hi Connor,
> 
> Huge +1 for this proposal, I’m thrilled you’re cleaning this up.  Couple of 
> detail questions:
> 
>>  
>> 
>> Detailed design
>> 
>> To provide a more flexible API, we propose deprecating and ultimately 
>> removing the PlaygroundQuickLook enum and CustomPlaygroundQuickLookable 
>> protocol in favor of a simpler design. Instead, we propose introducing a 
>> protocol which just provides the ability to return an Any (or nil) that 
>> serves as a stand-in for the instance being logged:
>> 
> 
> What is the use-case for a type conforming to this protocol but returning 
> nil?  If there is a use case for that, why not have such an implementation 
> return “self” instead?
> 
> In short, can we change playgroundRepresentation to return Any instead of 
> Any?.  Among other things, doing so could ease the case of playground 
> formatting Optional itself, which should presumably get a conditional 
> conformance to this.  :-)

I believe the rationale behind this was to provide a way to “opt-out” of a 
customized representation, although now that I think about it, what exactly 
does the default mean? In particular, what happens in this case?

// I’m not sure how this will be implemented: possibly UIView won’t conform to 
CustomPlaygroundRepresentable and the first class inheriting from it will do 
this?
// Either way, it shouldn’t really affect my example since this will just mean 
that FooView will implement it instead
class UIView: CustomPlaygroundRepresentable {
var playgroundRepresentation: Any? {
return self // I assume this is done somewhere in the bowels of 
PlaygroundSupport or whatever
}
}

class FooView: UIView {
override var playgroundRepresentation: Any? {
return “foo”
}
}

class BarView: FooView {
override var playgroundRepresentation: Any? {
return nil
}
}

In this case, what’s the default? UIView’s implementation, or that of the 
immediate parent (FooView’s)?

> 
> 
>> /// Implementors of `CustomPlaygroundRepresentable` may return a value of 
>> one of
>> /// the above types to also receive a specialized log representation.
>> /// Implementors may also return any other type, and playground logging will
>> /// generated structured logging for the returned value.
>> public protocol CustomPlaygroundRepresentable {
> On the naming bikeshed, the closest analog to this feature is 
> CustomStringConvertible, which is used when a type wants to customize the 
> default conversion to string.  As such, have you considered 
> CustomPlaygroundConvertible for consistency with it?
> 
> The only prior art for the word “Representable” in the standard library is 
> RawRepresentable, which is quite a different concept.
> 
>>   /// Returns the custom playground representation for this instance, or nil 
>> if
>>   /// the default representation should be used.
>>   ///
>>   /// If this type has value semantics, the instance returned should be
>>   /// unaffected by subsequent mutations if possible.
>>   var playgroundRepresentation: Any? { get }
> Again to align with CustomStringConvertible which has a ‘description’ member, 
> it might make sense to name this member “playgroundDescription”.
> 
> Thank you again for pushing this forward, this will be much cleaner!
> 
> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Saagar Jha via swift-evolution]

I’ve just glanced through this, so I apologize if this was already addressed, 
but will the default behavior (i.e. that of something that doesn’t conform to 
CustomPlaygroundRepresentable) remain the same?

Saagar Jha

> On Jan 9, 2018, at 15:19, Connor Wakamo via swift-evolution 
>  wrote:
> 
> Good afternoon,
> 
> In preparation for ABI stability, I’ve reviewed the API exposed by the 
> standard library for providing customized “quick looks” in playgrounds. This 
> is exposed as the PlaygroundQuickLook enum and the 
> CustomPlaygroundQuickLookable protocol. The PlaygroundQuickLook has a handful 
> of issues:
> 
>   - It hard-codes the list of supported types in the standard library, 
> meaning that PlaygroundLogger/IDEs cannot gain support for new types without 
> standard library changes (including swift-evolution review)
>   - The cases of the enum are poorly typed: there are cases like `.view` 
> and `.color` which take NS/UIView or NS/UIColor instances, respectively, but 
> since they’re in the standard library, they have to be typed as taking `Any` 
> instead
>   - The names of some of these enum cases do not seem to match Swift 
> naming conventions)
> 
> To that end, I am proposing the following:
> 
>   - Deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in 
> Swift 4.1 (including in the Swift 3 compatibility mode)
>   - Remove PlaygroundQuickLook and CustomPlaygroundQuickLookable in Swift 
> 5 to avoid including them in the stable ABI (this affects the compatibility 
> modes, too)
>   - Introduce a new protocol, CustomPlaygroundRepresentable, in the 
> PlaygroundSupport library in Swift 4.1:
> 
>   protocol CustomPlaygroundRepresentable {
>   /// Returns an alternate object or value which should 
> stand in for the receiver in playground logging, or nil if the receiver’s 
> default representation is preferred.
>   var playgroundRepresentation: Any? { get }
>   }
> 
>   - Update the PlaygroundLogger library in Swift 4.1 to support both 
> CustomPlaygroundRepresentable and 
> PlaygroundQuickLook/CustomPlaygroundQuickLookable
>   - Provide a compatibility shim library which preserves 
> PlaygroundQuickLook and CustomPlaygroundQuickLookable as deprecated in Swift 
> 3/4 and unavailable in Swift 5, but only in playgrounds (including in the 
> auxiliary source files stored inside a playground)
> 
> I’ve put a full proposal below. Please let me know what you think of this 
> proposal; I’d like to get some feedback before taking this through the review 
> process, but I’ll need to get that quickly so I can get it under review soon 
> as this is targeted at Swift 4.1.
> 
> Thanks,
> Connor
> 
> —
> 
> Playground QuickLook API Revamp
> 
> Proposal: SE- 
> 
> Authors: Connor Wakamo 
> Review Manager: TBD
> Status: Awaiting implementation
>  
> Introduction
> 
> The standard library currently includes API which allows a type to customize 
> its representation in Xcode playgrounds and Swift Playgrounds. This API takes 
> the form of the PlaygroundQuickLook enum which enumerates types which are 
> supported for quick looks, and the CustomPlaygroundQuickLookable protocol 
> which allows a type to return a custom PlaygroundQuickLook value for an 
> instance.
> 
> This is brittle, and to avoid dependency inversions, many of the cases are 
> typed as taking Any instead of a more appropriate type. This proposal 
> suggests that we deprecate PlaygroundQuickLook and 
> CustomPlaygroundQuickLookable in Swift 4.1 so they can be removed entirely in 
> Swift 5, preventing them from being included in the standard library's stable 
> ABI. To maintain compatibility with older playgrounds, the deprecated symbols 
> will be present in a temporary compatibility shim library which will be 
> automatically imported in playground contexts. (This will represent an 
> intentional source break for projects, packages, and other non-playground 
> Swift code which use PlaygroundQuickLook or CustomPlaygroundQuickLookable 
> when they switch to the Swift 5.0 compiler, even in the compatibility modes.)
> 
> Since it is still useful to allow types to provide alternate representations 
> for playgrounds, we propose to add a new protocol to the PlaygroundSupport 
> framework which allows types to do just that. (PlaygroundSupport is a 
> framework delivered by the swift-xcode-playground-support project 
>  which provides API 
> specific to working in the playgrounds environment). The new 
> CustomPlaygroundRepresentable protocol would allow instances to return an 
> alternate object or value (as an Any) which would serve as th

Re: [swift-evolution] Renaming SwiftObject

[Saagar Jha via swift-evolution]

Well, there’s always the option of Swift._NonObjcSwiftObject…but to be honest 
what this class looks like from the Swift side is much less of a concern to me. 
Getting “Swift” in the mangled name is probably good enough.

Saagar Jha

> On Jan 8, 2018, at 15:00, Greg Parker  wrote:
> 
> Adding "Swift" to the mangled name is reasonable. The class is not ordinarily 
> visible, so most of the time that people see it will be in potentially 
> mangled contexts like crash logs.
> 
> I'm reluctant to put too much ObjC into the name, because this is the base 
> class for classes that are *not* @objc. 
> 
> 
>> On Jan 6, 2018, at 7:21 PM, Saagar Jha > > wrote:
>> 
>> Just my 2¢, from the point of view of someone runs into SwiftObject 
>> frequently: I’d really appreciate it if this class had “Swift” in it’s name. 
>> At first glance, it’s name in mangled form (“_TtCs7_Object”) gives no 
>> indication as to where it’s from. Obviously it’s not a “pure” Objective-C 
>> object, but it’s not clear that it’s a Swift object either–maybe it’s C++? 
>> Saagar’s cool new language that also does name mangling? Who knows. I guess 
>> “_T” is kind of enough to figure it out, but since you’re changing the name 
>> anyways it would be great if it was something that reduced my cognitive 
>> overload, like Swift._SwiftObject.
>> 
>> If you’re going to expose this to Swift as well, a similar argument applies: 
>> from it’s name, it’s not clear that it’s part of Objective-C interop. I’m 
>> not sure if this is visible to Swift programmers, and if it isn’t this isn’t 
>> an issue, but in the case that it is Swift._Object looks more like a private 
>> implementation detail of a base class akin to NSObject in Objective-C or 
>> Object in Java than a compatibility shim with Objective-C.
>> 
>> Saagar Jha
>> 
>>> On Jan 4, 2018, at 19:10, Greg Parker via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> SwiftObject is an Objective-C class that is the base class of all "pure 
>>> Swift" class types. It needs to be renamed for the Swift stable ABI in 
>>> order to avoid ObjC class name collisions between the stable ABI's Swift 
>>> runtime and the runtime embedded into existing Swift apps.
>>> 
>>> I suggest `Swift._Object`, mangled as _TtCs7_Object like other Swift ObjC 
>>> class names. 
>>> 
>>> Any comments?
>>> 
>>> https://github.com/apple/swift/pull/13748 
>>> 
>>> 
>>> 
>>> -- 
>>> Greg Parker gpar...@apple.com  Runtime 
>>> Wrangler
>>> 
>>> 
>>> ___
>>> 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] Renaming SwiftObject

[Saagar Jha via swift-evolution]

Just my 2¢, from the point of view of someone runs into SwiftObject frequently: 
I’d really appreciate it if this class had “Swift” in it’s name. At first 
glance, it’s name in mangled form (“_TtCs7_Object”) gives no indication as to 
where it’s from. Obviously it’s not a “pure” Objective-C object, but it’s not 
clear that it’s a Swift object either–maybe it’s C++? Saagar’s cool new 
language that also does name mangling? Who knows. I guess “_T” is kind of 
enough to figure it out, but since you’re changing the name anyways it would be 
great if it was something that reduced my cognitive overload, like 
Swift._SwiftObject.

If you’re going to expose this to Swift as well, a similar argument applies: 
from it’s name, it’s not clear that it’s part of Objective-C interop. I’m not 
sure if this is visible to Swift programmers, and if it isn’t this isn’t an 
issue, but in the case that it is Swift._Object looks more like a private 
implementation detail of a base class akin to NSObject in Objective-C or Object 
in Java than a compatibility shim with Objective-C.

Saagar Jha

> On Jan 4, 2018, at 19:10, Greg Parker via swift-evolution 
>  wrote:
> 
> SwiftObject is an Objective-C class that is the base class of all "pure 
> Swift" class types. It needs to be renamed for the Swift stable ABI in order 
> to avoid ObjC class name collisions between the stable ABI's Swift runtime 
> and the runtime embedded into existing Swift apps.
> 
> I suggest `Swift._Object`, mangled as _TtCs7_Object like other Swift ObjC 
> class names. 
> 
> Any comments?
> 
> https://github.com/apple/swift/pull/13748 
> 
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> 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] [Review] SE 0192 - Non-Exhaustive Enums

[Saagar Jha via swift-evolution]

(Disclaimer: I’m no expert in this, and I know there are people in this list 
that are, so if there’s anything wrong please feel free to step in and correct 
me)

As far as I’m aware, Apple’s frameworks check which version of the framework 
you linked with at runtime (for UIKit, I believe this function is 
UIApplicationLinkedOnOrAfter) and modify their behavior to match. For example, 
if this function shows your application was linked with the iOS 6 SDK you’d get 
the old skeuomorphic UI instead of the “flatter”, newer iOS 7-style controls. 
What this means is every library actually keeps old implementations around in 
addition to the newer ones and picks the necessary one at runtime, so binary 
compatibility boils down to things like “don't change the memory layout of 
classes” rather than “don’t change the behavior of your program”.

Saagar Jha

> On Jan 5, 2018, at 19:11, Jon Shier via swift-evolution 
>  wrote:
> 
> At this point I think it might be useful to outline how binary compatibility 
> works for Objective-C on Apple platforms right now. As an app developer I’m 
> not intimately familiar with what happens when you run an app compiled with 
> the iOS 10 SDK on iOS 11. Are there just runtime checks to call old code 
> paths or something else? The more this thread goes on the more confused I get 
> about why Swift would have this issue while it doesn’t appear to be one for 
> Obj-C. If an enum adds a case now, I don’t have to care until I recompile 
> using the new SDK. Is the intention for Swift to be different in this regard?
> 
> 
> 
> Jon Shier
> 
> On Jan 5, 2018, at 6:41 PM, Jordan Rose via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> 
>>> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Is it hard to imagine that most everyone can get what they want and keep 
>>> the syntax clean and streamlined at the same time? Without any "@" signs or 
>>> other compiler hints?
>> 
>> For what it's worth, the original version of the proposal started with a 
>> modifier (a context-sensitive keyword, like 'final'), but the core team felt 
>> that there were a lot of modifiers in the language already, and this didn't 
>> meet the bar.
>> 
>> 
>>> "Rather, we are how to enable the vendor of a nonexhaustive enum to add new 
>>> cases without breaking binaries compiled against previous versions"
>>> 
>>> When an enum changes, and the change causes the code to break, the user can 
>>> be presented with migration options from an automated IDE tool. In what 
>>> specific way does this not solve the issue about having to upgrade your 
>>> code when using someone else's code library? This very notion implies your 
>>> disgruntled about doing work when things are upgraded, is that really what 
>>> this fuss is all about?
>>> 
>>> A well written language interpreter and auto-tooling IDE would not need 
>>> hints embedded in the code syntax itself. Migration hints from version to 
>>> version should not be a part of either the past or future version of the 
>>> code library.
>> 
>> Thanks for bringing this up! Unfortunately, it falls down in practice, 
>> because if there's a new enum case, it's unclear what you want to do with 
>> it. If you're handling errors, it's not obvious that the way you've handled 
>> any of the other errors is appropriate. In the (admittedly controversial) 
>> SKPaymentTransactionState case, none of the existing code would be 
>> appropriate to handle the newly-introduced "deferred" case, and nor could 
>> StoreKit provide "template" code that would be appropriate to the client app.
>> 
>> 
>> In any case, though, the key point on this particular quoted sentence is 
>> "without breaking binaries". Any such change must be valid without 
>> recompilation, and indeed without any intervention from the developer or an 
>> IDE, because that's what happens when the user updates their OS.
>> 
>> Jordan
>> 
>> 
>> 
>>> 
>>> ...
>>> 
>>> I don't expect the community to agree on language grammar, but the common 
>>> sense here on how to achieve the intended goals seems to be out of wack.
>>> 
>>> If someone can present a clear logical statement as to how an automated 
>>> migration tool behind the scenes in the IDE to handle all your versioning 
>>> worries, does not make this whole discussion about adding more convoluted 
>>> syntax additions irrelevant, I'd love to hear it.
>>> 
>>> ___
>>> 
>>> Sincerely,
>>> Jason
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Jan 2, 2018 at 12:36 PM, Xiaodi Wu >> > wrote:
>>> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> I think this whole thing has been unnecessarily convoluted. As a result, 
>>> the majority of the replies are rabbit holes.
>>> 
>>> In my opinion, the true root of the concept in question is as follows:
>>> 
>>> A list of something is desired:

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

[Saagar Jha via swift-evolution]

Sent from my iPhone

> On Sep 25, 2017, at 22:16, Jonathan Hull via swift-evolution 
>  wrote:
> 
> As he says, it is an in-place equivalent of filter, so the use-cases would be 
> similar.  I could see this being extremely useful.  Off the top of my head:
> 
>   views.remove(where: {$0.isHidden}) //Remove all views which are hidden 
> from the list.
> 
> Another thing which seems to be missing (although it could be there and I 
> don’t know the name) is the ability to split a list into two using a filter 
> (one with the filtered items and one with the remainder).  I am surprised 
> every time I reach for it and it isn’t there (the last time being yesterday). 
>  
> 

There’s partition(by:), which gives you an index that you can split with. 

> Thanks,
> Jon
> 
> 
>> On Sep 25, 2017, at 9:55 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> What is the use case?
>> On Mon, Sep 25, 2017 at 23:27 Félix Cloutier  
>> wrote:
>>> Actually, IMO, it's an oversight that there's no remove(where:), or another 
>>> in-place equivalent to `filter`. I'm in favor of it.
>>> 
>>> Félix
>>> 
>>> 
 Le 25 sept. 2017 à 15:17, Xiaodi Wu  a écrit :
 
 On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu  wrote:
> Brent has a great proposal in the pipeline regularizing the names of some 
> of these functions and filling in some of the more glaring gaps.
> 
> With regard to the specific items proposed here, Felix shows that 
> ‘filter’ provides an idiomatic one-line way of doing some of what is 
> proposed; currently remove(index(of:)) and operating on sliced would 
> accomplish the rest. Therefore, I do not think these proposed additions 
> meet the very high bar for expansion of the standard library API.
 
 I should add, however, it is wonderful (IMO) that more people are thinking 
 about these APIs; welcome and thank you for restarting this very important 
 conversation. It would be nice to get some more eyeballs on the previously 
 discussed set of rationalizations to the Collection APIs so that we can 
 make their use a little more ergonomic--with any luck, some better names 
 for existing extension methods and filling in a very few gaps judiciously 
 would allow us to make the existing facilities sufficiently more 
 discoverable that it will be easier to accomplish what you seek without 
 adding more extensions.
 
 
>> On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution 
>>  wrote:
>> Another alternative is to use `array = array.filter { $0 != someElement 
>> }`.
>> 
>> I thought that there would be a `remove(where:)` method, but there isn't.
>> 
>> Félix
>> 
>>> Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution 
>>>  a écrit :
>>> 
>>> Hello,
>>> 
>>> After going through the Swift standard library functions provided for 
>>> removing elements from a collection, one common pattern can be observed 
>>> in all those functions and that is the functions provide to remove 
>>> elements from the collection by passing the position or index of the 
>>> element or passing a range of indices or positions to remove the 
>>> elements.The standard library does not provide options to remove an 
>>> element from a collection by passing the actual element  to be removed 
>>> directly to the remove method.I've encountered this situation many 
>>> times when programming in Swift wherein I want an element or a set of 
>>> elements to be removed directly without always accessing it's index in 
>>> the collection but I have always ended up having to first access the 
>>> index of the element or elements which I want to remove and then pass 
>>> that index to the remove method.
>>> 
>>> The idea is to have an extension of the RangeReplaceableCollection 
>>> protocol to include a method to remove elements from a collection by 
>>> passing directly the element to be removed to the remove method and 
>>> also include methods to remove multiple elements from the collection by 
>>> passing in a sequence of the elements to be removed to the remove 
>>> method and to remove an element in a particular subrange of the 
>>> collection.
>>> 
>>> The prototype of the methods will be as follows - 
>>> 
>>> extension RangeReplaceableCollection where Element:Equatable{
>>> 
>>> mutating func removeElement(_ elementToBeRemoved:Element){
>>> 
>>> //check if elementToBeRemoved exists ;if yes, remove all occurrences of 
>>> elementsToBeRemoved from the collection.
>>> 
>>> }
>>> 
>>> mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in 
>>> range:Range){
>>> 
>>> //check if elementoBeRemoved exists; if yes, check if the index of 
>>> elementToBeRemoved is part of the subrange, if yes then remove else 
>>> don't remove.

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[Saagar Jha via swift-evolution]

Saagar Jha

> On Aug 30, 2017, at 16:42, Robert Bennett via swift-evolution 
>  wrote:
> 
> But countless editors have popped up since vi(m) first appeared. If anything, 
> this is a testament to the fact that old, “crusty” technology can remain 
> relevant forever, even as new technologies offering better ergonomics enter 
> the market.
> 
> Also, could someone tell me how ImageLiteral and similar types are 
> represented in the file? What appears when you open it in TextEdit? This same 
> sort of thing — presumably some ascii delimiters signifying specially 
> formatted data (I don’t have access to a computer) — could enable the desired 
> matrix, sqrt, etc functionality in Xcode. (Unless Xcode is doing 
> preprocessing of those types before compiling.)
> 

It’ll show up as #imageLiteral([file name here]). Xcode will detect these 
automatically and fill it in with an image.

> On Aug 30, 2017, at 6:49 PM, Ryan Walklin via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> I think we've possibly moved beyond the scope of swift-evolution. 
>> Skim-reading the OP's manifesto demonstrates nothing relevant to general 
>> purpose programming languages or Swift in particular.
>> 
>> Ryan
>> 
>> August 31, 2017 8:40 AM, "John Pratt via swift-evolution" 
>> > >
>>  wrote:
>> Well, here is one question: 100 years from now do you think all computers
>> should use vi?
>> At what point would people ever have anything that ever slightly resembles
>> something advanced?
>> Do you ever want anything that
>> slightly resembles science fiction, ever, in society? Or should everyone be
>> using vi for the rest of civilization?
>>> On Aug 30, 2017, at 5:32 PM, Eagle Offshore >> > wrote:
>>> While I am in theory a fan of literate programming and enjoy integrated 
>>> programming environments when they are integrated into a complete literate 
>>> system (Smalltalk browsers, LISP environments, HyperCard, etc...)...In 
>>> practice if its just a language and not a complete holistic system, and I 
>>> can't command the entire thing with God's own editor (I speak of vi - 
>>> because its "there" and it is the only editor guaranteed to be "there" on 
>>> any system I am ever likely to try to access), I'm not gonna use it.
>>> Just my $0.02
 On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 I sent a postal envelope to the Swift team with an article I wrote, 
 arguing that
 symbols and graphics would push the programming language forward.
 Wouldn’t it be nice to have an actual multiplication matrix broken out 
 into code,
 instead of typing, “matrix()”? It seems to me Swift has the chance to do 
 that.
 Also: why does "<==" still reside in code as "less than or equal to” when
 there is a unicode equivalent that looks neat?
 Why can’t the square of x have a superscript of 2 instead of having 
 “pow(x,2)?
 I think this would make programming much easier to deal with.
 I expound on this issue in my article:
 http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf 
 
 Thank you for reading.
 -John
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] pitch: Unified libc import (again)

[Saagar Jha via swift-evolution]

Just thought I’d link the previous thread on this topic: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023927.html
 
.
 I had promised to write a proposal for it back then, but never got around to 
doing it. Now that we’re out of the hectic Swift 3 timeframe, I can write a 
proposal and implementation for this, since it’s more likely to be accepted.

More broadly, however, I think a “Swiftication” of POSIX or libc is extremely 
necessary for anyone who’s not working with Foundation–and not everyone is! 
There are still parts of POSIX that are either 1. not a part of Foundation or 
2. part of Foundation/CoreFoundation but not in the open source Swift 
Foundation or CFLite (and hence not available on Linux). A big part of 
attracting newer Swift developers a moving away from the “Swift is for apps 
only” and the in my experience the need to drop down to UnsafePointer or errno 
just to use this API has been a big turn-off for programmers.

Saagar Jha

> On Aug 18, 2017, at 04:17, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Not “fundamentally” incompatible:
> 
> var stderr = FileHandle.standardError
> /* Conform FileHandle to TextOutputStream */
> print("foo", to: &stderr)
> 
> 
> On Fri, Aug 18, 2017 at 01:39 Brent Royal-Gordon  > wrote:
>> On Aug 17, 2017, at 8:20 PM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> * stderr should go wherever stdin and stdout go. Since it’d be silly for a 
>> function like `print(_:separator:terminator:)` or 
>> `readLine(strippingNewline:)` to live anywhere but the standard library, 
>> then it stands to reason that the stderr version should also live in the 
>> standard library.
>> 
>> FWIW, FileHandle.standardInput, FileHandle.standardError, 
>> FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation.
> 
> And, since they're read-only, are fundamentally incompatible with 
> `print(…to:)`, which requires its `output` parameter to be passed `inout`.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Xcode Fix-It action for returning closures

[Saagar Jha via swift-evolution]

You should probably file a Radar for this, since Xcode isn’t part of the Swift 
project.

Saagar Jha

> On Jul 13, 2017, at 19:46, iCloud via swift-evolution 
>  wrote:
> 
> Hi Swift community,
> 
> I was wondering if we have considered adding support for providing Xcode 
> automatic fix-it’s for closures being returned from a function.
> 
> For example, here is an incorrect version of a function that requires two 
> `@escaping` keywords to be inserted.
> 
> func mapping  (f: (A) -> (B)) -> ((C, B) -> (C)) -> ((C, A) -> (C))
> 
> Despite the complexity, the compiler manages to catch two errors.
> 
> 1. Closure use of non-escaping parameter `f` may allow it to escape
>  a. Automatic Fix-it by doing `f: @escaping (A) - > (B)`
> 
> 2. Closure use of non-escaping parameter `reducer` may allow it to escape
>  b. No Fix-it provided < 
> 
> As you see above, the two places where a compile-time error occurred had the 
> same exact problem; they both needed a `@escaping`. However, while the 
> function parameter was offered an automatic fix-it, the nested closure being 
> returned was not.
> 
> Here’s the correct version of the function.
> 
> func mapping  (f: @escaping (A) -> (B)) -> (@escaping ((C, B) -> 
> (C))) -> ((C, A) -> (C)) {
> return { reducer in
> return { accum, input in
> reducer(accum, f(input))
> }
> }
> }
> 
> I know this is a small feature for a very specific use case but I think it 
> could help make Xcode a little smarter :D 
> Thanks for reading!
> 
> 
> 
> 
> ___
> 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] [SR-3281] Update swift man page

[Saagar Jha via swift-evolution]

Looks great…at least, it’s much better than the old one.

One thing that stuck out was the “by Apple Inc.” in the synopsis. I think you 
should ask one of the Core Team members for advice on this, but to me it 1. 
reduces the impact of outside collaborators on the language and 2. makes it 
appear tied to Apple’s platforms when is in fact not. Not to downplay the role 
that Apple has had in the language, but I feel as though this like should at 
least be reworded or moved down into the description instead.

Saagar Jha

> On Jun 13, 2017, at 22:06, Natthan Leong via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> I have submitted an attempt at updating the swift man(1) page as
> Github Pull Request #10241 [1] based on the JIRA ticket SR-3281 [2].
> 
> Feedback is welcomed up to the end of Thursday, June 15th, preferably
> through discussion in the pull request thread and not through the mailing 
> list.
> 
> [1] https://github.com/apple/swift/pull/10241
> [2] https://bugs.swift.org/browse/SR-3281
> 
> Regards,
> Nate @contraultra
> ___
> 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: Support for map and flatMap with smart key paths

[Saagar Jha via swift-evolution]

It reads better and feels more natural. In my mind, it’s similar to the 
difference between 

["1", "2", "3"].flatMap { Double($0) }

and

["1", "2", "3"].flatMap(Double.init)

Saagar Jha

> On Jun 9, 2017, at 16:06, Max Moiseev via swift-evolution 
>  wrote:
> 
> Sorry. I might be missing something. Why is this better than:
> 
> let allEmployees = Set(managers.flatMap { $0.directReports }
> 
> ?
> 
>> On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution 
>>  wrote:
>> 
>> The new smart key path feature is really lovely, and feels like a great 
>> addition to Swift.
>> 
>> It seems like it might be straightforward to add overloads of `map` and 
>> `flatMap` to the standard library to make use of the new functionality:
>> 
>>  let managers = flatOrganisation.managers
>>  let allEmployees = Set(managers.flatMap(\.directReports))
>>  let employeeNames = Set(allEmployees.map(\.name))
>> 
>> This feels like a really natural way of working with key paths in a 
>> functional style. It makes a lot of sense for collections, and possibly for 
>> Optional too (although as far as I can see optional chaining is more or less 
>> equivalent, and with more compact syntax).
>> 
>> I’m hoping that this might be low-hanging fruit that could be considered for 
>> the Swift 4 release. I’d be happy to have a go at writing a proposal if 
>> there’s interest!
>> 
>> –Adam
>> 
>> ___
>> 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] [Idea] `enum` case count feature

[Saagar Jha via swift-evolution]

Not Nicholas, but I thought I’d share one of my use cases.

I use a enum (with a Int raw value) for sections in a table view, so whenever 
the table view asks for the number of rows I pass in the number of cases. 
Currently, I’m doing something like this:

enum Sections: Int {
case section1: 0
case section2
case section3
case _count
}

Obviously, this cases issues in switch statements since I need to handle the 
_count case with an assertion, but other than that it works rather well.

Saagar Jha

> On May 10, 2017, at 01:04, Yuya Hirayama via swift-evolution 
>  wrote:
> 
> Hi, Nick.
> I have no idea about it and am interested in why you want to count the cases.
> 
> -- 
> Yuya Hirayama
> 
> On 2017年5月10日 at 16:58:41, Nicholas Maccharoli via swift-evolution 
> (swift-evolution@swift.org ) wrote:
> 
>> Swift-Evolution, 
>> 
>> I'm sorry if this has been brought up before but is there a reason why there 
>> is no built-in way of getting the number of cases an enum defines?
>> 
>> Given something like: enum MyEnum { case foo, bar, baz }
>> 
>> It would be nice to get the number of cases this enum defines, something 
>> like:
>> 
>> MyEnum.count
>> 
>> Looking forward to hearing back about this!
>> 
>> - Nick 
>> 
>> 
>> 
>> ___
>> 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] optional variable with ternary operator

[Saagar Jha via swift-evolution]

Well, you’re not allowed to compare optionals any more. You can try binding the 
value to an Int, so that it’s not an optional anymore:

if let number = number {
let result = number > 0 ? 1 : 2
}

Either way, you’ll have to decide what you think should happen when number is 
nil.

Saagar Jha

> On May 8, 2017, at 00:36, Suresh Kansujiya via swift-evolution 
>  wrote:
> 
> Hey,
> 
> i am using ternary operator with optional variable. like below ex.
> 
> var number:Int?
> let result = number > 0 ? 1 : 2  
> here i am getting this waring : comparison operators with optionals were 
> removed from the Swift Standard Library. Consider refactoring the code to use 
> the non-optional operators
> 
> Note : i must need to use ternary operator for checking.
> 
> Regards
> Suresh Kansujiya
> ___
> 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] [Review] SE-0173: Add `MutableCollection.swap(_:with:)

[Saagar Jha via swift-evolution]

+1 overall; the proposal is well justified and I don’t see any reason why it 
should be rejected.

One nitpick I do have is with the choice of the argument parameter: 
elements.swap(i, with: j) seems at first glance (to me, at least) to swap the 
elements i and j, not the element at i with the element at j. The original 
(free) function made sense because it actually performed its operation on the 
elements, but here I’d prefer it if we used elements.swap(at: i, j) to make it 
explicit that that arguments are on indices and not elements.

Saagar Jha

P.S. The link to the manifesto has a typo (“manfiesto”).

> On Apr 25, 2017, at 11:32, Ted Kremenek via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0173 "Add MutableCollection.swap(_:with:)" begins now and 
> runs through April 28, 2017.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md
>  
> 
> Reply text
> 
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> Ted (Review Manager)
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Low efficiency multidimensional array problem

[Saagar Jha via swift-evolution]

It might be helpful if you showed a bit more of the code you’re working on, so 
that we can better see what you’re trying to do. Is there any operation in 
particular that is slow?

Also, CC’ing swift-users since I think it belongs there.

Saagar Jha

> On Apr 18, 2017, at 22:57, Hbucius Smith via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> 
> When I used multidimensional array in swift, I found it is very low 
> efficiency.
> 
>   
> I used in the following way : 
> 
>
> var array = Array.init(repeating: Array.init(repeating: 0, count: 5), 
> count: 5)
>
> array[0][0] = 0
> 
>
>   I have read some posts in stack overflow. It suggests using one dimension 
> to fake multidimensional array. I think it is too ugly. DO we have better 
> choice for this ?
> 
> 
> 
> 
> 
> 
> best wishes for you 
> ___
> 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] Adding safety to arrays

[Saagar Jha via swift-evolution]

Dynamic programming comes to mind.

Saagar Jha

> On Apr 16, 2017, at 19:33, Riley Testut  wrote:
> 
> My bad, should have phrased my response better :^)
> 
> Under what circumstances would you need to be able to assign elements in an 
> array out of order, while also requiring Array size/performance? (Genuinely 
> curious, not trying to attack).
> 
> IMO, if the differences between Array and Dictionary would cause that much of 
> an issue for your implementation, my guess is you have more important 
> priorities than the need to assign elements out-of-order 😉 I don't think we'd 
> need to add another type to the standard library for this use case.
> 
> On Apr 16, 2017, at 11:22 AM, Saagar Jha  > wrote:
> 
>> A Dictionary uses a lot more space than an Array, though, and allow for 
>> bogus keys like “-1”, etc.
>> 
>> Saagar Jha
>> 
>>> On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 Personally, the only valid use-case I can think of is when you want to 
 initialise an Array’s elements out-of-order - i.e., you want to set a 
 value for myArray[2] despite myArray[0] and [1] not being populated. In 
 that case, it would be better to have some kind of SparseArray type, and 
 for us to have a proper API for unsafe initialisation of stdlib types. 
>>> 
>>> Wouldn't the same functionality be accomplished by a Dictionary with Int as 
>>> the key type?
>>> 
>>> On Apr 14, 2017, at 10:00 AM, Karl Wagner via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
> I'd actually say the #1 reason not to add this feature is that a lot of 
> developers don't seem to understand this, and they're likely to use the 
> feature to make their code try to continue in the face of programmer 
> error instead of trapping like it properly should. A program in an 
> inconsistent state is dangerous; best to stop it quickly before it does 
> some damage.)
 
 Right, so I think the reason is actually that a lot of developers don’t 
 understand what an Array is. There are two use-cases for an Array:
 
 1) As a string of items, don’t care about the length. The maximum prior 
 knowledge you can have is that the order may or may not be significant. 
 This includes operations like iteration, mapping, reducing and filtering.
 2) As a string of items of specific length. You have prior knowledge about 
 what you expect to find at each location. This includes operations like 
 random-access subscripting, which is what we’re talking about.
 
 Basically, the interesting part of a statement such as “let someValue = 
 myArray[2]” is: why index 2? What’s so special about that element; why 
 couldn't someValue be the item at any index N instead? It’s because we 
 know to expect something of special significance at index 2.
 
 In that case, the only time myArray[2] will fail is when your prior 
 knowledge breaks down. The type-system has no way to encode and check for 
 the length of an Array, and that has allowed somebody to pass in a bad 
 value. So what to do?
 
 A) If you absolutely require a value for myArray[2]: Insert a precondition 
 check.
 B) If you can still continue without myArray[2]: Check the length of the 
 Array. Your logic will be branching anyway in this case, to account for 
 the value (and subsequent values) being/not being present.
 
 
 Personally, the only valid use-case I can think of is when you want to 
 initialise an Array’s elements out-of-order - i.e., you want to set a 
 value for myArray[2] despite myArray[0] and [1] not being populated. In 
 that case, it would be better to have some kind of SparseArray type, and 
 for us to have a proper API for unsafe initialisation of stdlib types. 
 
 - Karl
 ___
 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] Adding safety to arrays

[Saagar Jha via swift-evolution]

A Dictionary uses a lot more space than an Array, though, and allow for bogus 
keys like “-1”, etc.

Saagar Jha

> On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution 
>  wrote:
> 
>> Personally, the only valid use-case I can think of is when you want to 
>> initialise an Array’s elements out-of-order - i.e., you want to set a value 
>> for myArray[2] despite myArray[0] and [1] not being populated. In that case, 
>> it would be better to have some kind of SparseArray type, and for us to have 
>> a proper API for unsafe initialisation of stdlib types. 
> 
> Wouldn't the same functionality be accomplished by a Dictionary with Int as 
> the key type?
> 
> On Apr 14, 2017, at 10:00 AM, Karl Wagner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>>> I'd actually say the #1 reason not to add this feature is that a lot of 
>>> developers don't seem to understand this, and they're likely to use the 
>>> feature to make their code try to continue in the face of programmer error 
>>> instead of trapping like it properly should. A program in an inconsistent 
>>> state is dangerous; best to stop it quickly before it does some damage.)
>> 
>> Right, so I think the reason is actually that a lot of developers don’t 
>> understand what an Array is. There are two use-cases for an Array:
>> 
>> 1) As a string of items, don’t care about the length. The maximum prior 
>> knowledge you can have is that the order may or may not be significant. This 
>> includes operations like iteration, mapping, reducing and filtering.
>> 2) As a string of items of specific length. You have prior knowledge about 
>> what you expect to find at each location. This includes operations like 
>> random-access subscripting, which is what we’re talking about.
>> 
>> Basically, the interesting part of a statement such as “let someValue = 
>> myArray[2]” is: why index 2? What’s so special about that element; why 
>> couldn't someValue be the item at any index N instead? It’s because we know 
>> to expect something of special significance at index 2.
>> 
>> In that case, the only time myArray[2] will fail is when your prior 
>> knowledge breaks down. The type-system has no way to encode and check for 
>> the length of an Array, and that has allowed somebody to pass in a bad 
>> value. So what to do?
>> 
>> A) If you absolutely require a value for myArray[2]: Insert a precondition 
>> check.
>> B) If you can still continue without myArray[2]: Check the length of the 
>> Array. Your logic will be branching anyway in this case, to account for the 
>> value (and subsequent values) being/not being present.
>> 
>> 
>> Personally, the only valid use-case I can think of is when you want to 
>> initialise an Array’s elements out-of-order - i.e., you want to set a value 
>> for myArray[2] despite myArray[0] and [1] not being populated. In that case, 
>> it would be better to have some kind of SparseArray type, and for us to have 
>> a proper API for unsafe initialisation of stdlib types. 
>> 
>> - Karl
>> ___
>> 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] class indent in swift, history?

[Saagar Jha via swift-evolution]

I believe the indentation is more a signal for a new scope than curly braces. 
Swift doesn’t indent its switch cases since they’re a part of the same scope, 
while nested types and methods are a new scope.

Saagar Jha

> On Mar 7, 2017, at 05:38, Derrick Ho via swift-evolution 
>  wrote:
> 
> It might have to do with C history. Anything inside two curly braces usually 
> had an increased indentation level.
> 
> I always thought the switch statement was an oddball for not indenting the 
> cases.
> On Tue, Mar 7, 2017 at 1:42 AM Will Stanton via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Hello Chris and perhaps core team members,
> 
> The comments on tab-levels for `switch` made me want to ask about the 
> considerations that went into class and protocol-level indentation.
> 
> Sorry if my wording isn’t precise, but in Objective-C, functions can (should) 
> be at the same 0-indent level as the class:
> @implementation Foo
> // No indent!
> - (void)doSomething {
> }
> @end
> 
> However, in Swift, method and nested types are indented by default:
> class Foo : Bar {
> // Things indented!
> enum Types {
> }
> func doSomething() {
> }
> }
> 
> 
> Was the change mostly driven by the desire for protocol+class+struct+enum 
> consistency in ‘increasing’ the scope+indent level? Were there other 
> considerations?
> Why didn’t the language evolve into something like this to reduce the use of 
> horizontal whitespace, allowing class functions/types at the root/top level? 
> Like:
> @class Foo : Bar
> enum Types {
> }
> func doSomething() {
> }
> @end
> 
> 
> Regards,
> Will Stanton
> 
> > On Mar 7, 2017, at 12:52 AM, Chris Lattner via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > I can understand how you might find this unnerving, but it is important to 
> > understand that Swift and Objective-C/C have different semantics when it 
> > comes to case labels:  in Swift, a case label *is* a scope, and *is* part 
> > of the switch statement.  In Objective-C, a case label is just a label, 
> > like any other goto label: it is not a scope and is not necessarily a 
> > direct child of the switch statement.
> >
> > C and Objective-C’s behavior is what leads to obscure but important things 
> > like Duff’s device (https://en.wikipedia.org/wiki/Duff's_device 
> > ).
> >
> > In contrast, Swift fixes the scoping, fallthrough, and other related 
> > problems all in one fell swoop, and ensures that cases are directly nested 
> > under the switch (unlike in C, where they can be nested under other 
> > statements within the switch).  Because the case/default labels are *part 
> > of* the switch in Swift, it makes sense for them to be indented at the same 
> > level.
> >
> > While I can respect that you aesthetically have a preference for the 
> > Objective-C way of doing things, the rationale for this behavior change 
> > wasn’t arbitrary and wasn’t due to "LLVM style".  It is an important 
> > reflection of the core semantics of the language model.
> >
> > Finally, conservation of horizontal whitespace is important for 
> > comprehension of code, particularly w.r.t. readability and maintenance.  
> > This is why statements like guard exist: to reduce nesting and indentation, 
> > directing the attention of someone reading and maintaining code to the 
> > important parts.
> >
> 
> ___
> 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] Strings in Swift 4

[Saagar Jha via swift-evolution]

Sorry, it looks like I left you hanging on this–luckily I found it when I was 
cleaning my inbox.

Overall, I believe the issue I have with the Swift String indexing model is 
that indices cannot be operated on like an Int can–you can multiply, divide, 
square, whatever you want on integer indices, while String.Index only allows 
for what is essentially addition and subtraction. Now, I get that these 
operations may not make sense on most Strings; the existing API covers them 
well. However, there are cases, where these operations would be convenient; 
such as when dealing with fixed-length records or tables of data; almost 
invariably these are stored as ASCII. Thus, for these cases, I believe that 
there should be some way to let String know that we are dealing with something 
that is purely ASCII, so that it can allow us to use these operations in an 
efficient manner (for example, having an optional .asciiString property that 
conforms to RandomAccess; since I don’t believe that extendedASCII does). Such 
an API would keep the existing String paradigm, which is what is needed most of 
the time, but allowing for random access when the data can be guaranteed to 
support it.

I’m not sure if I’m getting my point across, please do let me know if you don’t 
quite get what I mean.

Saagar Jha

> On Jan 20, 2017, at 5:55 PM, Ben Cohen  wrote:
> 
> 
>> On Jan 20, 2017, at 2:58 PM, Saagar Jha via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Sorry if I wasn’t clear; I’m looking for indexing using Int, instead of 
>> using formIndex.
> 
> 
> Question: why do you think integer indices are so desirable?
> 
> Integer indexing is simple, but also encourages anti-patterns (tortured 
> open-coded while loops with unexpected fencepost errors, conflation of 
> positions and distances into a single type) and our goal should be to make 
> most everyday higher-level operations, such as finding/tokenizing, so easy 
> that Swift programmers don’t feel they need to resort to loops as often.
> 
> Examples where formIndex is so common yet so cumbersome that it would be 
> worth efforts to create integer-indexed versions of string might be 
> indicators of important missing features on our collection or string APIs. So 
> do pass them along.
> 
> (There are definitely known gaps in them today – slicing needs improving as 
> the manifesto mentions for things like slices from an index to n elements 
> later. Also, we need support for in-place remove(where:) operations. But the 
> more commonly needed cases we know about that aren’t covered, the better)
> 
> 

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

Re: [swift-evolution] for-else syntax

[Saagar Jha via swift-evolution]

If you’re fine with a couple extra characters, you can use .isEmpty:

for name in names {
// do your thing
}
if names.isEmpty {
// do whatever
}

It’s a bit more typing, but I feel it makes your intentions more clear.

Saagar Jha

> On Feb 1, 2017, at 8:48 AM, Chris Davis via swift-evolution 
>  wrote:
> 
> Hi,
> 
> Often when I’m programming I stumble upon this scenario:
> 
> I have a list of items that may or may not be empty - if it’s full, I do one 
> thing, if it’s empty I do something else, my code looks like this:
> 
> class Example_1
> {
> let names = ["Chris", "John", "Jordan"]
> 
> /// Loop over names, if no names, print no names
> func run()
> {
> for name in names
> {
> print(name)
> }
> 
> if names.count == 0
> {
> print("no names")
> }
> }
> }
> 
> let exampleOne = Example_1()
> exampleOne.run()
> 
> However, Personally, I would find it more pleasing to write something like 
> this:
> 
> class Example_2_Proposed
> {
> let names:[String] = []
> 
> /// Loop over names, if no names, print no names
> func run()
> {
> for name in names
> {
> print(name)
> } else {
> print("no names")
> }
> }
> }
> 
> let exampleTwo = Example_2_Proposed()
> exampleTwo.run()
> 
> The difference here is a “for-else” type syntax where if there were no items 
> in the array it would simply fall through to the else statement.
> 
> What would be the pros/cons of introducing such syntax?
> 
> Is there’s a way of doing something similar in swift already?
> 
> Thanks
> 
> Chris
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Annotation of Warnings/Errors

[Saagar Jha via swift-evolution]

There's nothing wrong with fix-its and error messages, and indeed they can
be quite helpful-the issue is that sometimes they show up when they really
shouldn't, like in the middle of typing a line. Novices will then often
stop and see what it's trying to say (wouldn't you trust a tool if it tells
you something's wrong, especially if you're not acquainted with it?), and
the advice it gives is often irrelevant since the compiler doesn't have a
full understanding of what's going on. This simply suppresses the error
until the programmer is done typing.

Sent from my iPhone


> On Jan 25, 2017, at 23:31, Rien via swift-evolution <
swift-evolution@swift.org> wrote:
>
> OTOH, looking at fixit and error messages can also aid in understanding
Swift better.
> Seeing what happens when it happens is something I find quite useful.
>
> Not that I have anything against the proposal, but I do wonder if that is
the best usage of available resources.
>
> A BIG OT warning:
>
> If people are so easily put off, they probably are not very suited to
being a programmer/sw-engineer. It might be good for them to drop out asap
so they can pursue something more fitting to their personality… I have met
a lot of people that would have been better off not to get into
programming. It would have been better for them and for the projects they
worked on.
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
>> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:
>>
>> One of the biggest issues that I saw while teaching Swift to newbies
(most had not programmed before) is confusion based on the early
warnings/errors that swift/xcode gives you as they type.  What would happen
is that they would type a variable, and it would say… “You haven’t used
this variable” and so they would just click the fixit because they trust
the compiler more than they trust themselves.  This would lead to a point
where they were very confused because some of the code was code they had
thought through, and some of it was changed by random fixits in ways they
didn’t understand… and so it would lead to more errors/fixits until they
had errors which couldn’t be fixed.
>>
>> By the end of the semester they had learned to ignore the warnings until
they were finished, but it took a couple of months to get there, and was a
big deterrent to new users… (Also, learning to ignore warnings ignorer to
use a system seems like an anti-pattern)
>>
>> I have a good friend who is an expert perl programmer who tried Swift
and eventually gave up because he couldn’t figure out which errors to
ignore (and which might just disappear a minute later) and which he needed
to pay attention to. He was overwhelmed by the sheer number, and they
didn’t seem trustworthy to him (“Swift is full of lies!” he would say of
the warnings… which is a mantra I find myself parroting when I get those
appearing/disappearing errors).
>>
>>
>> To fix this, I propose adding a way to annotate warnings/errors to say
how immediate they need to be:
>> • Immediate - This error should always be shown
>> • DifferentLine - This error should only be shown once the cursor is on
a different line
>> • DifferentScope - This error should only be shown once the cursor is in
a different scope from this line
>> • DifferentFunction - This error should only be shown once the cursor is
in a different function
>>
>> So the “You haven’t used this variable” warning would be marked
.differentScope, meaning that it would only show up once you had clicked
away from the scope. The reason for this is that while you are in the same
scope, it is fairly likely that you are still going to use the variable… so
the warning is premature. Once I have left the scope, it makes sense to
warn me.
>>
>> Similarly, the “You need a return value” error would be marked
.differentFunction because you are likely to add one while typing the
function. But a type mismatch with the return value would either be
.immediate or .differentLine because you have made an error that isn’t
likely to be fixed with more typing on other lines.
>>
>> I think this will cut way down on the number of warnings/errors that
need to be ignored, which should increase trust in the system overall.
>>
>> To be clear, I am only proposing adding the annotation to Swift
(probably with a default of .differentLine). The compiler would not repress
the warning/error itself… just vend it with a way to retrieve the
annotation.  IDE makers like Apple/Xcode would then be free to use that
extra information in their UI if desired.
>>
>> Thanks,
>> Jon
>> ___
>> 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://

Re: [swift-evolution] Annotation of Warnings/Errors

[Saagar Jha via swift-evolution]

+1, provided these differences are ignored if the user manually builds a
project. Hopefully this takes some of the load off of SourceKitService.
On Wed, Jan 25, 2017 at 16:07 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> Yes.  It would stick once it appears (until it is fixed, of course)
>
> On Jan 25, 2017, at 4:02 PM, Xiaodi Wu  wrote:
>
> I didn't read the proposal to mean vanish; rather, just lazily displayed
> until some condition, but then permanently there once it shows up. It
> really is annoying to be constantly reminded you haven't used a variable
> when you've literally just declared it. Once you've left the scope once,
> it's fair to have that warning stay there whether or not you click back.
> On Wed, Jan 25, 2017 at 17:59 Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> > On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > One of the biggest issues that I saw while teaching Swift to newbies
> (most had not programmed before) is confusion based on the early
> warnings/errors that swift/xcode gives you as they type.  What would happen
> is that they would type a variable, and it would say… “You haven’t used
> this variable” and so they would just click the fixit because they trust
> the compiler more than they trust themselves.  This would lead to a point
> where they were very confused because some of the code was code they had
> thought through, and some of it was changed by random fixits in ways they
> didn’t understand… and so it would lead to more errors/fixits until they
> had errors which couldn’t be fixed.
> >
> > By the end of the semester they had learned to ignore the warnings until
> they were finished, but it took a couple of months to get there, and was a
> big deterrent to new users… (Also, learning to ignore warnings ignorer to
> use a system seems like an anti-pattern)
> >
> > I have a good friend who is an expert perl programmer who tried Swift
> and eventually gave up because he couldn’t figure out which errors to
> ignore (and which might just disappear a minute later) and which he needed
> to pay attention to. He was overwhelmed by the sheer number, and they
> didn’t seem trustworthy to him (“Swift is full of lies!” he would say of
> the warnings… which is a mantra I find myself parroting when I get those
> appearing/disappearing errors).
> >
> >
> > To fix this, I propose adding a way to annotate warnings/errors to say
> how immediate they need to be:
> > • Immediate - This error should always be shown
> > • DifferentLine - This error should only be shown once the cursor is on
> a different line
> > • DifferentScope - This error should only be shown once the cursor is in
> a different scope from this line
> > • DifferentFunction - This error should only be shown once the cursor is
> in a different function
> >
> > So the “You haven’t used this variable” warning would be marked
> .differentScope, meaning that it would only show up once you had clicked
> away from the scope. The reason for this is that while you are in the same
> scope, it is fairly likely that you are still going to use the variable… so
> the warning is premature. Once I have left the scope, it makes sense to
> warn me.
> >
> > Similarly, the “You need a return value” error would be marked
> .differentFunction because you are likely to add one while typing the
> function. But a type mismatch with the return value would either be
> .immediate or .differentLine because you have made an error that isn’t
> likely to be fixed with more typing on other lines.
> >
> > I think this will cut way down on the number of warnings/errors that
> need to be ignored, which should increase trust in the system overall.
> >
> > To be clear, I am only proposing adding the annotation to Swift
> (probably with a default of .differentLine). The compiler would not repress
> the warning/error itself… just vend it with a way to retrieve the
> annotation.  IDE makers like Apple/Xcode would then be free to use that
> extra information in their UI if desired.
> >
> > Thanks,
> > Jon
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Having warnings and errors vanish and then reappear as you click in/out of
> function seems far more confusing to me. Is there any other language/IDE
> that does things that way?
>
> - Karl
> ___
> 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-ev

Re: [swift-evolution] Strings in Swift 4

[Saagar Jha via swift-evolution]

Found it: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021548.html
 


Saagar Jha

> On Jan 20, 2017, at 4:10 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 20, 2017, at 12:55 PM, Maxim Veksler via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Please see discussion inline.
>> 
>> On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira 
>> mailto:jeremy.j.pere...@googlemail.com>> 
>> wrote:
>> 
>> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution 
>> > mailto:swift-evolution@swift.org>> wrote:
>> >
>> > One ask - make string interpolation great again?
>> >
>> > Taking from examples supplied at 
>> > https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation
>> >  
>> > 
>> >
>> > "Column 1: \(n.format(radix:16, width:8)) *** \(message)"
>> >
>> > Why not use:
>> >
>> > "Column 1: ${n.format(radix:16, width:8)} *** $message"
>> >
>> > Which for my preference makes the syntax feel more readable, avoids the 
>> > "double ))" in terms of string interpolation termination and function 
>> > termination points. And if that's not enough brings the "feel" of the 
>> > language to be scriptable in nature common in bash, sh, zsh and co.. 
>> > scripting interpreters and has been adopted as part of ES6 interpolation 
>> > syntax[1].
>> >
>> 
>> This idea came up once before on Swift Evo. The arguments against are:
>> 
>> 1. Swift already has an “escape” character for inserting non literal stuff 
>> into strings - the “\” character. Either you have two - increasing 
>> complexity for both the developer and the Swift compiler’s tokeniser - or 
>> you have to change everything that uses “\” to use $ e.g. $t $n instead of 
>> \t \n.
>> 
>> 
>> I would claim that this serves as an reinforcement of making the 
>> distinctions. "\t" is not the same behavior as "\(someVariable)" both 
>> conceptually - I think there is a clear distinction between inserting a 
>> "constant symbol" to inserting "the string content of a variable" and 
>> semantically - While you would use \t to insert a tab you are mandated by 
>> the semantics to use \( .. ) to insert the contents of a variable.
> 
> Hi Maxim,
> 
> there was quite a discussion on this matter a few months ago - I can't find 
> the thread right now, but the consensus of majority here seemed to be that 
> the current status is desirable by most and that it contains some unified 
> philosophy over anything that will "not print as typed". I believe that this 
> is something that has been discussed here several times - keep in mind Swift 
> 4 is supposed to be as much backward compatible as possible with breaking 
> changes requiring severe justification - there is unlikely to be one for this 
> other than "I like it better this way".
> 
>>  
>> 2. The dollar sign is a disastrous symbol to use for an special character, 
>> especially in the USA where it is commonly used to signify the local 
>> currency. Yes, I know it is used for interpolation in Perl, Shell and 
>> Javascript and others,  but “this other language I like does X, therefore 
>> Swift should do X” is not a good argument.
>> 
>> 
>> Please name concrete examples? I would believe that the case for 
>> $variableName to be rare enough to justify expecting the developer to make 
>> an escape claim with \$variableName, likewise for ${variableName}, if 
>> expected output is plain text I wouldn't imagine this "\$\{variableName\}" 
>> to be a far reaching expectation.
>> 
>> The use of $ symbol is more reaching[1], and is being adopted constantly as 
>> the selected patten for even recent developments as Facebook's GraphQL query 
>> syntax[2] which to the best of my knowledge was invented in US. 
>> 
>> 3. There is already quite a lot of code that uses \( … ) for interpolation, 
>> this would be a massive breaking change.
>> 
>> 
>> True, but going forward that would enable a "better readable" code for 
>> larger number of users. Additionally I would suggest that automatic 
>> conversion using Swift Migration Assistant should be possible.
>> 
>> 
>> ___
>> 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] Support for assertions/preconditions that sometimes fail.

[Saagar Jha via swift-evolution]

Why not just add a // TODO or // FIXME comment?

Saagar Jha

> On Jan 14, 2017, at 4:10 PM, Amir Michail via swift-evolution 
>  wrote:
> 
> It’s quite common for an assertion/precondition that you thought should hold 
> actually does not yet there is no bug. In that case, you might want to remind 
> yourself of this fact by commenting out the assertion/precondition (instead 
> of deleting it) so that you don’t make the same mistake in the future by 
> inserting such assertions/preconditions into the code.
> 
> However, it would be nice to have explicit support for 
> assertions/preconditions that don’t always hold where there is no bug.
> 
> For example:
> 
> preconditionNotAlwaysTrue( list.isEmpty )
> 
> When your app finishes running, the IDE could show you all such 
> preconditions/assertions that you thought fail sometimes that did not fail in 
> that particular run. In that case, you might consider switching them to 
> normal preconditions/assertions provided your code has now evolved to the 
> point where they always hold.
> ___
> 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] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Saagar Jha via swift-evolution]

So, then this should have a warning? I’m still not getting one.

func foo(a: () -> (), b: (() -> ())? = nil, c: Int) {
a()
b?()
}

foo(a: {
print(“Bar”)
}, c: 0)

Saagar Jha



> On Jan 4, 2017, at 9:34 PM, Douglas Gregor  wrote:
> 
> 
>> On Jan 4, 2017, at 9:32 PM, Saagar Jha > <mailto:saa...@saagarjha.com>> wrote:
>> 
>> 
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jan 4, 2017, at 8:35 PM, Douglas Gregor >> <mailto:dgre...@apple.com>> wrote:
>>> 
>>> 
>>> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> Check out this thread 
>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020470.html>–it’s
>>>>  very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to 
>>>> this as well as the ability to use multiple trailing closures like so:
>>>> 
>>>> animate(identifier: “”, duration: 0, update: {
>>>>// update
>>>> }, completion: {
>>>>// completion
>>>> }
>>>> 
>>>> Saagar Jha
>>>> 
>>>> 
>>>> 
>>>>> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
>>>>> mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> When you have a function with a closure and then another optional default 
>>>>> = nil closure at the end, like this:
>>>>> 
>>>>> open static func animate(identifier: String,
>>>>>  duration: Double,
>>>>>  update: @escaping AnimationUpdate,
>>>>>  completion: AnimationCompletion? = nil) {
>>>>> You can’t use trailing closure syntax for the update argument when 
>>>>> leaving the completion argument out/default.
>>>>> 
>>>>> This kind of breaks one of the benefits of default arguments, which is 
>>>>> that you can add them to existing released functions without breaking the 
>>>>> calling code. This means you have to add a separate convenience function 
>>>>> without the extra argument, which is annoying and inelegant.
>>>>> 
>>> Why not simply add the "completion" parameter before the trailing closure? 
>>> That would still allow existing callers to work, without having to change 
>>> the language. 
>>> 
>>>>> Another annoying thing is that you can easily miss this error if you 
>>>>> happen to not use trailing closure syntax in your tests or other usage, 
>>>>> because adding the extra default argument compiles fine for code that 
>>>>> uses normal syntax.
>>>>> 
>>> The Swift compiler warns when a parameter written as a closure type isn't 
>>> the last parameter. The warning is actually disabled in the specific case 
>>> above because you've written it using a typealias... maybe we should warn 
>>> on such cases (it's worth a bug report). Regardless, in the majority of 
>>> instances, you'll get a warning, so it won't be silent on disabling 
>>> trailing closure syntax. 
>> 
>> Tried this out in the playground:
>> 
>> func foo(a: () -> (), b: (() -> ())? = nil) {
>>  a()
>>  b?()
>> }
>> 
>> foo(a: {
>>  print(“Bar”)
>> })
>> 
>> and didn’t receive a warning for it, either.
> 
> We don’t warn here because ‘foo’ does have a trailing closure… it’s for the 
> second parameter. I guess we could still warn about ‘a’ (maybe lump it into 
> the same bug about the typealias case).
> 
>   - Doug
> 

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

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Saagar Jha via swift-evolution]

Saagar Jha



> On Jan 4, 2017, at 8:35 PM, Douglas Gregor  wrote:
> 
> 
> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> Check out this thread 
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020470.html>–it’s
>>  very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to 
>> this as well as the ability to use multiple trailing closures like so:
>> 
>> animate(identifier: “”, duration: 0, update: {
>>  // update
>> }, completion: {
>>  // completion
>> }
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> When you have a function with a closure and then another optional default = 
>>> nil closure at the end, like this:
>>> 
>>> open static func animate(identifier: String,
>>>  duration: Double,
>>>  update: @escaping AnimationUpdate,
>>>  completion: AnimationCompletion? = nil) {
>>> You can’t use trailing closure syntax for the update argument when leaving 
>>> the completion argument out/default.
>>> 
>>> This kind of breaks one of the benefits of default arguments, which is that 
>>> you can add them to existing released functions without breaking the 
>>> calling code. This means you have to add a separate convenience function 
>>> without the extra argument, which is annoying and inelegant.
>>> 
> Why not simply add the "completion" parameter before the trailing closure? 
> That would still allow existing callers to work, without having to change the 
> language. 
> 
>>> Another annoying thing is that you can easily miss this error if you happen 
>>> to not use trailing closure syntax in your tests or other usage, because 
>>> adding the extra default argument compiles fine for code that uses normal 
>>> syntax.
>>> 
> The Swift compiler warns when a parameter written as a closure type isn't the 
> last parameter. The warning is actually disabled in the specific case above 
> because you've written it using a typealias... maybe we should warn on such 
> cases (it's worth a bug report). Regardless, in the majority of instances, 
> you'll get a warning, so it won't be silent on disabling trailing closure 
> syntax. 

Tried this out in the playground:

func foo(a: () -> (), b: (() -> ())? = nil) {
a()
b?()
}

foo(a: {
print(“Bar”)
})

and didn’t receive a warning for it, either.

> 
>>> Are there any issues/gotchas if the trailing closure syntax were to work 
>>> for the last specified argument rather than the last definedargument?
>>> 
> The main gotcha, and the reason the rule is the way it is, is that it means 
> you'd lose trailing closure syntax if the caller wanted to specify an 
> argument for the last parameter.
> 
>- Doug
> 
> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Saagar Jha via swift-evolution]

Check out this thread 
–it’s
 very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to this 
as well as the ability to use multiple trailing closures like so:

animate(identifier: “”, duration: 0, update: {
// update
}, completion: {
// completion
}

Saagar Jha



> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> When you have a function with a closure and then another optional default = 
> nil closure at the end, like this:
> 
> open static func animate(identifier: String,
>  duration: Double,
>  update: @escaping AnimationUpdate,
>  completion: AnimationCompletion? = nil) {
> You can’t use trailing closure syntax for the update argument when leaving 
> the completion argument out/default.
> 
> This kind of breaks one of the benefits of default arguments, which is that 
> you can add them to existing released functions without breaking the calling 
> code. This means you have to add a separate convenience function without the 
> extra argument, which is annoying and inelegant. Another annoying thing is 
> that you can easily miss this error if you happen to not use trailing closure 
> syntax in your tests or other usage, because adding the extra default 
> argument compiles fine for code that uses normal syntax.
> 
> Are there any issues/gotchas if the trailing closure syntax were to work for 
> the last specified argument rather than the last defined argument?
> 
> ___
> 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] [Out of scope][Discussion] Modernize MapKit functions for Swift API Design Guidelines

[Saagar Jha via swift-evolution]

MapKit is not part of the Swift standard library; as such, it would probably be 
better if you used Apple’s Bug Reporter to let them know.

Saagar Jha



> On Jan 1, 2017, at 11:02 AM, Scott Gardner via swift-evolution 
>  wrote:
> 
> Hello Swift Community, and…
> 
> if Calendar.current.identifier == .gregorian {
> print("Happy new year! 🎉")
> }
> 
> I would like to propose that the MapKit framework functions be updated to 
> conform to the Swift API Design Guidelines.
> 
> For example, this is how you would currently determine if the user is 
> currently within the visible map view:
> 
> let userPoint = MKMapPointForCoordinate(mapView.userLocation.coordinate)
> let mapRect = mapView.visibleMapRect
> let inside = MKMapRectContainsPoint(mapRect, userPoint)
> 
> This should be more easily accomplished, such as by doing this:
> 
> let userPoint = mapView.userLocation.coordinate.mapPoint
> let inside = mapView.visibleMapRect.contains(userPoint)
> 
> There are 39 functions that should be updated:
> 
> https://developer.apple.com/reference/mapkit/1612565-mapkit_functions?language=swift
>  
> 
> 
> I realize that this proposal is out of scope for Swift 4. So I will develop 
> it for consideration in a future release, and keep it updated on my fork 
> until it’s ready to submit. All feedback welcomed and appreciated.
> 
> https://github.com/scotteg/swift-evolution/blob/master/proposals/mapkit-functions-for-swift-api-design-guideines.md
>  
> 
> 
> Cheers,
> Scott
> 
> --
> Scott Gardner
> https://github.com/scotteg 
> scotteg.com 
> @scotteg 
> 
> ___
> 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] Any consideration for directoryprivate as a compliment to fileprivate?

[Saagar Jha via swift-evolution]

Did someone ask for more feedback?

Overall, I'm pretty -1 on this proposal. I never really liked the fileprivate 
solution of scope being created to match (in my mind not quite related) file 
system/organizational boundaries of files–but it was the best compromise we 
could come up with at the time (I’m up for improvements, but I fear that it’s 
too late to change now). The issue with directoryprivate/folderprivate is that 
it takes these issues from fileprivate and compounds across many files. With 
one file it’s easy to figure out what’s going on, but once you have a more than 
a few than keeping track of access between them becomes a pain.

Saagar Jha



> On Dec 8, 2016, at 4:38 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> As an advice, you should first hear out what the community thinks about the 
> idea, before writing anything, because one person might share your idea. 
> Others including myself may not like it. Wait for more feedback first. ;)
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 8. Dezember 2016 um 13:35:56, Jim Malak (jim.ma...@beryle-lee.com 
> ) schrieb:
> 
>> Great. Is there some other steps I should go through or is the next step to 
>> write a draft proposal?
>> 
>> Kind regards,
>> Jim Malak
>> Director
>> Beryle & Lee, Inc,
>> O +1-330-818-2600
>> M +1-234-716-2658
>> F +1-330-818-2560
>> 
>> email/Skype: jim.ma...@beryle-lee.com 
>> http://beryle-lee.com 
>> http://linkedin.com/in/jamesmalak 
>> https://www.facebook.com/BeryleLeeInc 
>> From: Aron Lindberg 
>> Sent: Thursday, December 8, 2016 7:34:06 AM
>> To: Jim Malak
>> Cc: Adrian Zubarev; swift-evolution@swift.org
>> Subject: Re: [swift-evolution] Any consideration for directoryprivate as a 
>> compliment to fileprivate?
>>  
>> Since Xcode is not a requirement for Swift development no, I was talking 
>> about a file system folder.
>> 
>>> On 8 Dec 2016, at 13.30, Jim Malak via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I totally agree.  For clarity, are we in agreement that the definition of 
>>> "folder" is the underlying file system's implementation of a folder rather 
>>> than some metadata setting? I am thinking of how Xcode as a view of project 
>>> folder that at times can leave on one confused.
>>> 
>>> My preference is to keep it simple, to use the underlying file system to 
>>> decide what is a folder. Does that sound ok?
>>> 
>>> Kind regards,
>>> Jim Malak
>>> Director
>>> Beryle & Lee, Inc,
>>> O +1-330-818-2600
>>> M +1-234-716-2658
>>> F +1-330-818-2560
>>> 
>>> email/Skype: jim.ma...@beryle-lee.com 
>>> http://beryle-lee.com 
>>> http://linkedin.com/in/jamesmalak 
>>> https://www.facebook.com/BeryleLeeInc 
>>> 
>>> From: Aron Lindberg mailto:ar...@me.com>>
>>> Sent: Thursday, December 8, 2016 6:26:10 AM
>>> To: Adrian Zubarev
>>> Cc: Jim Malak; swift-evolution@swift.org 
>>> Subject: Re: [swift-evolution] Any consideration for directoryprivate as a 
>>> compliment to fileprivate?
>>>  
>>> I think this is a great idea!
>>> 
>>> I would prefer calling it folderprivate tho.
>>> 
 On 8 Dec 2016, at 08.29, Adrian Zubarev via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Whoops I meant directoryprivate not dictionaryprivate. I’m probably still 
 sleepy. 
 
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 8. Dezember 2016 um 08:18:24, Adrian Zubarev 
 (adrian.zuba...@devandartist.com ) 
 schrieb:
 
> You haven’t seen this in the list because no one requested 
> dictionaryprivate yet. :D
> 
> @core-team: See what you have done with >>file< typerprivate, typepublic all these requests for new access modifiers. 
> 
> Instead of just going with
> 
> private
> private(file)
> 
> // for new one
> private(type)
> I know there would be some people that would forget about (file/type) and 
> write only private everywhere, which is probably the main reason why we 
> have fileprivate now.
> 
> Anyways let’s be a little more constructive here.
> 
> Hi Jim, regarding your request, it feels like this is something that 
> falls into the topic of submodules. :) Correct me if I’m wrong here.
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 8. Dezember 2016 um 07:50:07, Jim Malak via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> My apologies up front if I am going about this incorrectly. I have been 
>> exploring extensions in Swift 3 bo

Re: [swift-evolution] [Idea] Extending syntax for `extension`

[Saagar Jha via swift-evolution]

How exactly would this work? Would it restrict the extension to only the scope 
it’s defined in?

Saagar Jha



> On Dec 5, 2016, at 1:48 PM, Braeden Profile via swift-evolution 
>  wrote:
> 
> I really enjoy having the ability to write and nesting my code at the 
> appropriate indentation level in my file.  Extensions are fabulous, but I 
> wonder—solely for readability/style sake, could we allow you to properly 
> namespace your extensions?  Though I don’t know the implementation cost of 
> this, I think it could be useful to be able to write this:
> 
> class MathEvaluator
> {
>   struct Number
>   {
>   let value: Double
>   }
>   
>   struct Operation
>   {
>   let numbers: (Number, Number)
>   let transform: (Double, Double) -> Double
>   }
>   
>   extension Number
>   {
>   var factors: [Double]
>   {
>   // Calculate and return the factors
>   }
>   }
> }
> 
> …which would be completely equivalent to:
> 
> class MathEvaluator
> {
>   struct Number
>   {
>   let value: Double
>   }
>   
>   struct Operation
>   {
>   let numbers: (Number, Number)
>   let transform: (Double, Double) -> Double
>   }
> }
>   
> extension MathEvaluator.Number
> {
>   var factors: [Double]
>   {
>   // Calculate and return the factors
>   }
> }
> 
> This change is in the same ball park as this, proposed a week or two ago:
> 
> struct MathEvaluator.Number
> {
>   let value: Double
>   
>   var factors: [Double]
>   {
>   // Calculate and return the factors
>   }
> }
> ___
> 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] Removing Setter/Observer Name Overrides

[Saagar Jha via swift-evolution]

oldValue is the value the property contained before didSet. self.value is the 
variable’s current value (i.e. newValue in willSet).

Saagar Jha



> On Dec 3, 2016, at 9:34 PM, Rick Mann via swift-evolution 
>  wrote:
> 
> -1.
> 
> I always name parameters to code blocks with an "in" or "out" prefix, and 
> want to maintain my ability to change the name for set.
> 
> As to oldValue, isn't that the same as self.value? Does it even need to exist?
> 
>> On Nov 30, 2016, at 14:40 , Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> This pitch is breaking, and should be considered under the phase 1 timeframe.
>> gist here: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b
>> 
>> As usual, I will update the gist with feedback. Please refer to gist rather 
>> than 
>> this email for the latest revisions.
>> 
>> -- E
>> 
>> 
>> Removing Setter/Observer Name Overrides
>> 
>>  • Proposal: TBD
>>  • Author: Erica Sadun
>>  • Status: TBD
>>  • Review manager: TBD
>> Introduction
>> 
>> This proposal removes setter and observer name overrides from the Swift 
>> programming language, limiting their use to the defaults of newValue and 
>> oldValue. 
>> 
>> Swift-evolution thread: TBD
>> 
>> Motivation
>> 
>> Swift setters and property observers supply predefined symbols that 
>> represent value arguments. These are newValue for set and willSet, and 
>> oldValue for didSet. These implicit names are always available -- you don't 
>> need to take any action to have access to them -- and they are instantly 
>> recognizable in context.
>> 
>> Swift allows you to override newValue and oldValue by supplying a name in 
>> parentheses after the set/willSet/didSet keyword, for example:
>> 
>> set
>> (temperature) { 
>> 
>> // use temperature instead of newValue
>> }
>> This feature is an attractive nuisance for the following reasons:
>> 
>> Preferring newValue and oldValue to custom names is consistent. Someone 
>> reading code needn't recognize a new and unfamiliar symbol in setter or 
>> observer context. 
>> 
>> Preferring newValue and oldValue to custom names avoids errors. Some 
>> developers prefer to name all mentioned values for the sake of consistency, 
>> clarity, and readability like this:
>> 
>> set(newValue) {...}
>> Developers who follow this rule may accidentally insert newValue or oldValue 
>> in the wrong observer. It is not that uncommon. (See this tweet, for 
>> example.) Swift does not check for name mismatches, specifically for the 
>> common error of using oldValue in place of newValue or vice versa.
>> 
>> Detailed Design
>> 
>> Upon adopting this proposal:
>> 
>>  • Swift removes name overrides from the language.
>>  • Swift allows the current grammar to be used but disallows the mention 
>> of any mismatched name:
>> set { ... } // okay
>> willSet { ... } // okay
>> didSet { ... } // okay
>> set(newValue) { ... } // okay, self-documenting
>> set(oldValue) { ... } // compiler error
>> willSet(newValue) { ... } // okay, self-documenting
>> willSet(oldValue) { ... } // compiler error
>> didSet(oldValue) { ... } // okay, self-documenting
>> didSet(newValue) { ... } // compiler error
>> didSet(bob) { ... } // compiler error
>> Type Members
>> 
>> As an optional extra, Swift could emit warnings for any type member named 
>> newValue or oldValue. 
>> 
>> var newValue: T { ... } // warning
>> A more extreme step would disallow the use of newValue and oldValue members, 
>> reserving those words for setters and observers. This proposal does not go 
>> so far since newValue and oldValue are reasonable property names for a 
>> generic ChangeSet struct.
>> 
>> Although a warning could be limited to the presence of property observers 
>> and setters, this is not recommended. Deferring warnings until there's a 
>> name conflict might introduce the desire to rename members and break APIs 
>> when observers and setters are added at a later date. That outcome is 
>> undesirable.
>> 
>> Please note that Swift properly differentiates between members 
>> (self.newValue) and the newValue argument, as in the following example. 
>> 
>> struct Foo
>> {
>> 
>> var newValue: Int = 0
>> 
>> 
>> var observedMember: Int
>> {
>> 
>> willSet
>> {
>> 
>> print
>> (newValue)
>> 
>> // newValue = 100 // error, `newValue` is immutable
>>self.newValue = 100
>> 
>>}
>>}
>> }
>> 
>> 
>> var test = Foo(newValue: 0, observedMember: 50
>> )
>> test.
>> observedMember = 60 // prints 60
>> test.newValue // 100
>> Impact on Existing Code
>> 
>> This proposal is breaking. The migrator will need to remove overrides and 
>> rename their mentions to newValue and oldValue.
>> 
>> Timeline
>> 
>> This proposal is breaking so needs to be considered in Swift 4 Stage 1
>> 
>> Alternatives Considered
>> 
>>  • If this proposal is not adopted, Swift could still warn or error on  
>> set(oldValue), willSet(oldValue), and didSet(newValue), since these can be 
>> considered to be always wrong.
>>

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Saagar Jha via swift-evolution]

I’m along the lines of keeping the old behavior+warnings if “oldValue” is used 
for “newValue” and vice versa. Nonbreaking, and removes the issue of 
accidentally swapping the two.

Saagar Jha



> On Dec 3, 2016, at 7:33 PM, Derrick Ho via swift-evolution 
>  wrote:
> 
> I believe Erica's point about RIGHT NAMES ONLY is the most clear. While a 
> block-like syntax using $0 is nice, it fails to communicate whether it is a 
> newvalue or an oldvalue.
> 
> Therefore instead of following a block-like pattern it should follow a 
> delegate-function like pattern. This would remove the ambiguity that $0 or 
> name changing would present.
> 
> 
> set (newValue: TheType) {
> let a = newValue
> }
> 
> didSet (oldValue: TheType) {
> let b = oldValue
> }
> 

Hmm, why do we need “TheType”? Is this not conveyed by the actual property’s 
declaration?

> 
> 
> On Sat, Dec 3, 2016 at 10:06 PM Erica Sadun via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> [Original pitch: 
> https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b 
> ]
> 
> GENERAL FEEDBACK
> 
> I received a gratifying amount of feedback about my pitch here, on Twitter, 
> through email, on several Slack channels, and on IRC. I wanted to summarize 
> the feedback, to start a new round of discussion.
> 
> * A majority of respondents believe the current feature is incorrectly 
> designed 
>   and that this is our best opportunity to change it.
> * A majority of respondents disagree on *how* it should be changed.
> 
> Before I commit to the (non-trivial) effort of pushing on this, I'd like to 
> know if any 
> of the core team can chime in on the "preferred" design. Thank you.
> 
> BUG REPORT
> 
> The notion that the compiler should check for `set(oldValue)`, 
> `willSet(oldValue)`, 
> and `didSet(newValue)` and emit warnings or errors had pretty much  universal
> support. I have submitted https://bugs.swift.org/browse/SR-3310 
>  to address
> this, regardless of whether the syntax changes or not.
> 
> MENTIONING NAMES
> 
> A majority of respondents prefer that argument names always be mentioned, 
> whether or not they *can* be omitted. Consensus is that it's unSwifty
> to use pre-built `newValue` and `oldValue` arguments without mentioning
> them first.
> 
> * The current system violates the principle of clarity. 
> * It adds too much magic (https://en.wikipedia.org/wiki/Magic_(programming)) 
>  
>   at the point of use. 
> * It is inconsistent with the binding of variable names in closures.
> 
> My original design, which I chose to provide the least impact on the compiler 
> and 
> existing code, was the least popular option.
> 
> PREFERRED DESIGN
> 
> The most popular design is that setters and property observers follow closures
> syntax,  namely that the old value and new value arguments be passed as $0, 
> and assignable using `name in`. Under this design, a setter looks like:
> 
> ```
> set { newValue in ... } // or
> set { somethingElse in ... } // or
> set { use $0 here }
> ```
> Swift loses the "magic" newValue and oldValue, but any developer who
> normally prefers to mention the name before use has a simple, visible
> and easy way to retain that clarity. 
> 
> * Mirrors closure syntax
> * Easy to use
> * Loses magic names
> * Encourages documenting names in context

Feels kind of “off”, since with closures the number represents a positional 
argument, but here the number has no value other than to match with closure 
syntax.

> 
> "NO CHANGE"
> 
> The second most popular design is "leave things as they are" (but implement 
> the bug
> report.) Developers with good style habits will use mandatory `newValue` and 
> `oldValue`
> names in their setter and observer declarations. No proposal is needed, and 
> the bug
> report guards against potential errors.
> 
> I would appreciate knowing whether the core team feels that the support for 
> "no change",
> even from a smaller group of developers, disqualifies this issue from the 
> high bar of Phase 1.
> 
> (This group also included the most developers who self-reported that they did 
> not
>  use the override feature.)

+1 provided bug report is considered.

> 
> REMOVING OVERRIDES
> 
> A third design entirely loses the ability to override variables or mention 
> their names. 
> This was in fact my *original* original design that I did not submit after 
> sufficient 
> devs told me they wanted to always spell out magic argument names. 

-1, keeping “newValue” and “oldValue” is too restrictive, both in the case that 
there is another property with these names (causing potential confusion with 
self.newValue/self.oldValue), and in the case that the developer has a better 
description for the value.

> 
> RIGHT NAMES ONLY
> 
> Finally, the least popular design is my original pitch. (Only allow the 
> "right" names,
> and allow them to

Re: [swift-evolution] [Pitch] Numeric enum cases

[Saagar Jha via swift-evolution]

I'm curious about the use case for this. For tuples it's a positional
argument; how does this apply to enum cases which shouldn't depend on their
order?
On Tue, Nov 22, 2016 at 05:43 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Have we already discussed this somewhere?
>
> enum MyEnum {
> case 0
> case 1(String)
> }
>
> // or
>
> enum MyEnum {
> case `0`
> case `1`(String)
> }
>
> let zero: MyEnum = .0
> let one = MyEnum.1("Swift")
>
> switch zero {
>
> case .0:
>print("zero")
>
> case .1(let string)
>print(string)
> }
>
>
> Tuples have this .# syntax, where the number is the index of the tuple
> value. Can’t we allow this on enum cases as well?
> --
>
> This is additive and something for phase 2, but I’d like to know if we
> want to allow this?! :)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> ___
> 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] [Bug] Foundation.URL should support semicolon(; ) appearing in URL path

[Saagar Jha via swift-evolution]

This is expected behavior. The semicolon character is reserved in URLs, and
it requires escaping if it is used.
On Tue, Oct 25, 2016 at 12:05 Cao, Jiannan via swift-evolution <
swift-evolution@swift.org> wrote:

>
> http://host/book;id=1/page;2/
>
> this URL is a valid URL, but URLComponents will ruin it with %3B
> http://host/book%3Bid=1/page%3B2/
>
> Since Swift Server is coming out, this bug should be solved.
>
>
> ___
> 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] Import Conditionals

[Saagar Jha via swift-evolution]

I believe there was a draft to merge all the "Libc" modules; let me see if
I can find that.

On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution <
swift-evolution@swift.org> wrote:

> *Description*
>
> In an effort to both (1) reduce boilerplate code, and (2) promote
> cross-platform reusability I propose that we implement the following *Import
> Conditional Operators*:
>
> *`||` *and `*&&`*
>
> Currently, import conditionals must be implemented like so:
>
> ```
> #if os(Linux) || os(FreeBSD)
> import Glibc
> #else
> import Darwin
> #endif
> ```
>
> With *import conditional operators* this would be condensed to:
>
> ```
> import Glibc || Darwin
> ```
>
> The first library/framework (Glibc) would be imported if found and the the
> second (Darwin) only in the event the first should fail.
>
> *Other Caveats:*
>
> *(A) —  *we could limit this to one conditional operator per import line
> OR we could implement order of operations. Obviously, there are tradeoffs
> of both that we should discuss.
>
> *(B) —* if-conditional statements currently explicitly show the import
> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to
> this new feature. I would argue that the reduction of boilerplate code
> would in itself be worth this abstraction.
>
>
> --
> Sean Alling
>
> ___
> 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] Tuples as RawRepresentable

[Saagar Jha via swift-evolution]

If you're looking for a use case for tuple equality, I often pack a bunch
of values in a tuple and check it with another, which makes it easy to
compare a multiple values at once and perform something only if all of them
are equal.

On Sat, Oct 15, 2016 at 09:28 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 15 Oct 2016, at 16:04, Xiaodi Wu  wrote:
> >
> > Yes it absolutely matters what the types are. Two floating point values
> can compare equal when their raw bytes differ and they can compare not
> equal even when their raw bytes are the same, and it would be absolutely
> necessary that a tuple of two floating point values behaves the same way.
> >
> > Moreover, if a value is not equatable, it's nonsense to ask if tuples of
> two of them are equal. Otherwise, you've effectively forced every value
> type to be equatable, since it'd be ridiculous if (a, a) == (b, b) didn't
> imply a == b.
>
> All I meant really is that you can always compare equality at the memory
> level, regardless of Equatable conformance; the type checker ensures the
> tuples being compared can only contain the same types in the same order, at
> which point a bitwise memory comparison can determine they are equal in the
> strictest possible sense, much like comparing whether two object references
> point to the same object (you're comparing the pointers).
>
> But actually it doesn't seem to even matter; tuples are already Equatable
> if all of their components are (again, something I don't seem to actually
> use), so that should be more than sufficient for using them as enum raw
> values, we can just ignore tuples that aren't/require the developer to add
> Equatable to any components that aren't.
> ___
> 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] [Idea]Why not get dynamically named variables?

[Saagar Jha via swift-evolution]

Have you thought about using a dictionary? You can fetch a recipe by looking up 
a key:

let foods: [String: Foods] = [:] // fill it up appropriately with your own data
let recipe = foods[TitleTextField.text].recipe

Saagar Jha



> On Sep 4, 2016, at 10:28, Fayez Hellani via swift-evolution 
>  wrote:
> 
> Hey! There should be an option to name variables AND constants dynamically. 
> For e.g. in an app from storing recipes, where the user creates a recipe,the 
> recipe should be stored in a constant (as a structure) with a name 
> “\(TitleTextField.text)_Recipe” (e.g. “Lasagna_Recipe”), so that it gets 
> stored easily and therefore fetched even easier.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Proposal for swift build linux on Mac os x

[Saagar Jha via swift-evolution]

Apple's bug reporter would be a better place.
On Sat, Aug 13, 2016 at 16:16 Félix Cloutier 
wrote:

> The swift-evolution mailing list is about the language itself, Xcode is
> independent. I don't know where you could try to push that suggestion.
>
>
> Félix
>
> Le 13 août 2016 à 16:40:42, apps4u via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I have a Proposal but I'm not sure if Its the right place to propose but
> as it has to do with building Swift So I'm going to submit here. So Please
> let me know if that is not the place to propose this feature. As it
> includes Xcode.
>
>
> Ok So this is a proposal for being able to build swift for linux on Mac Os
> X in Xcode just like a native target.
>
> With the release of Hypervisor.framework It would be good if from within
> Xcode I can create a project with a Linux Target and when clicking Build
> and run it create a VM running a small linux Kernel using
> Hypervisor.framework.
> By using Hypervisor.framework it would be better integrated into the tools
> as it has a small foot print. The idea would be to have the VM downloaded
> before a build. The linux VM should be small and only have the required
> software to test a server and using the hypervisor.framework the project
> build folder can be attached to the vm at build time so the working with
> different projects at the same time would not require lots of VM.
>
> Now I know that this would be best if integrated into Xcode and this is
> the Swift Language mailing list but Swift build is part of the Language.
>
> This could also be used to debugging. Now Its possible now to use Docker
> to run a linux vm and have a shared folder for your project and some
> scripts to kick off the build. But it take time to setup per project and is
> not the Experience i would expect in Xcode.
>
> Now My first thought when I found out about Hypervisor.framework that the
> reason it was created was to add linux targets to Xcode.
>
>
>
> ___
> 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] [META] Gmane and Swift Evolution

[Saagar Jha via swift-evolution]

I’ve submitted a pull that includes everything except for SE-0094, 0095, and 
0110, which I wasn’t able to find.

Saagar Jha



> On Aug 3, 2016, at 11:31, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Aug 2, 2016, at 9:22 AM, Ben Rimmington  wrote:
>> 
>> 
>>> On 2 Aug 2016, at 16:16, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> Anyone willing to adopt a proposal or a group and get them updated, please 
>>> reply in-thread and submit a PR with changes.
>> 
>> [SE-0076 ... SE-0090] 
>> 
>> -- Ben
>> 
> 
> Here's what's left
> 
> proposals/0092-typealiases-in-protocols.md:* Status: **Implemented in Swift 
> 3.0** 
> ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17317))
> proposals/0094-sequence-function.md:Swift-evolution thread: [Discussion 
> thread topic for that 
> proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15743/focus=17108)
> proposals/0094-sequence-function.md:[SE-0045a]: 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/16119
> proposals/0095-any-as-existential.md:Discussion threads: 
> [pre-proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018109.html),
>  [review thread 
> 1](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18349), 
> [2](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18350/focus=18447),
>  
> [3](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18351/focus=18440),
>  [4](http://thread.gmane.org/gmane.comp.lang.swift.evolution/18518), 
> [post-review 
> thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19463)
> proposals/0096-dynamictype.md:[RFC: didset and 
> willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0097-negative-attributes.md:[RFC: didset and 
> willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0098-didset-capitalization.md:[RFC: didset and 
> willset](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534)
> proposals/0099-conditionclauses.md:[\[Pitch\] making where and ,  
> interchangeable in guard 
> conditions](http://thread.gmane.org/gmane.comp.lang.swift.evolution/17926)
> proposals/0101-standardizing-sizeof-naming.md:* Swift Evolution Pitch: 
> [\[Pitch\] Renaming sizeof, sizeofValue, strideof, 
> strideofValue](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19459)
> proposals/0101-standardizing-sizeof-naming.md:* [Earlier 
> Discussions](http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830)
> proposals/0101-standardizing-sizeof-naming.md:* [SE-0101 
> Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21103)
> proposals/0103-make-noescape-default.md:* [Make non-escaping closures the 
> default](http://thread.gmane.org/gmane.comp.lang.swift.evolution/19756)
> proposals/0105-remove-where-from-forin-loops.md:Swift Evolution Discussion: 
> [\[Pitch\] Retiring `where` from for-in 
> loops](http://thread.gmane.org/gmane.comp.lang.swift.evolution/20142)
> proposals/0106-rename-osx-to-macos.md:Swift Evolution Discussion: [\[DRAFT\] 
> Aliasing the OS X Platform Configuration 
> Test](http://thread.gmane.org/gmane.comp.lang.swift.evolution/20815)
> proposals/0108-remove-assoctype-inference.md:swift-evolution thread: 
> [pre-proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21714)
> proposals/0108-remove-assoctype-inference.md:As Douglas Gregor (original 
> author of the relevant type inference code) [puts 
> it](http://article.gmane.org/gmane.comp.lang.swift.evolution/22058):
> proposals/0108-remove-assoctype-inference.md:To some extent, this is an issue 
> inherent to any design which makes no distinctions at the site of 
> implementation between members intended to satisfy protocol requirements and 
> members that are explicitly not intended to satisfy protocol requirements. 
> Rather than adding keywords to create this distinction, Douglas Gregor has 
> [proposed and implemented type checker 
> heuristics](http://article.gmane.org/gmane.comp.lang.swift.devel/1799) that 
> will generate warnings when a programmer implements a member that "looks 
> like" it should fulfill a protocol requirement but does not actually do so. 
> This is one possible mitigation strategy that should be revisited as a way to 
> decrease the possible impact of removing associated type witness inference 
> from the compiler.
> proposals/0108-remove-assoctype-inference.md:As well, Dave Abrahams expresses 
> a [potential 
> issue](http://article.gmane.org/gmane.comp.lang.swift.evolution/21892):
> proposals/0109-remove-boolean.md:* Status: Accepted 
> ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/23844))
> proposals/0109-remove-boolean.md:[Discussion 
> thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21559)
> proposals/0110-distingish-single-tuple-arg.md:Discussion: 
> [pre-proposal](http://thread.gmane.org/gmane.comp.lang.swift.evolution/21

Re: [swift-evolution] Swift 3.1 discussions, go?

[Saagar Jha via swift-evolution]

Well, it depends on what kind of Math you’re trying to do. The Accelerate 
framework is available if you need performance.
Saagar Jha



> On Aug 1, 2016, at 18:01, Muse M via swift-evolution 
>  wrote:
> 
> Have always wonder why Maths in Swift is slower than C and Go, it should be 
> address with priority if Swift is to be adopt for engineering, financial and 
> science industry.
> 
> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> See 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>  
> 
> 
> From what I understand, the discussion should stay focused on the main topics 
> for Swift 4 that Chris highlighted in 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>  
> 
> 
> I had several ideas in mind, but am postponing them for Swift 5, seeing the 
> schedule...
> 
> 
>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> It was stated that 27th of July was the last date for proposal acceptance, 
>> 29th of July was the last day for implementation, and 1th of August should 
>> be the starting day of Swift 3.1-related discussions.
>> Am I right? Should we begin?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [META] Gmane and Swift Evolution

[Saagar Jha via swift-evolution]

I’d be happy to help. I see 94 instances of “gmane", do we want to split it up 
(since I see Erica is on it already)?

Saagar Jha



> On Jul 31, 2016, at 15:42, Chris Lattner via swift-evolution 
>  wrote:
> 
>> 
>> On Jul 31, 2016, at 3:40 PM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Gmane.org  is shutting down. 
>> http://ostatic.com/blog/mint-18-xfce-imminent-gmane-org-shutting-down 
>>  
>> writes:
>> 
>>> "Long time mailing list archive site Gmane.org  is 
>>> shutting down. Gmane has been the home for technical mailing list 
>>> references since 2002. But it's no longer fun for founder and only 
>>> maintainer Lars Ingebrigtsen. He's been sued in India and threatened with 
>>> legal action in at least France, among other annoyances. The straw that 
>>> broke Ingebrigtsen's back was a sustained denial of service 
>>>  attack 
>>> throughout the month of July. He's been wondering a lot lately if it's all 
>>> worth it. So, he's decided 
>>> 
>>>  to move the mail and news servers to new hosting. However, Ingebrigtsen is 
>>> indeed discontinuing the web-based archive. He said he's just "fed up." 
>>> He's willing to send a disk with the web server archives to anyone who 
>>> wants to take it over. But with the Gmane.org  web 
>>> presence gone, it feels like the end of an era. There is much wailing and 
>>> gnashing of teeth throughout the community with some even trying to get a 
>>> petition started."
>> 
>> Because of this shutdown, numerous documents in the Swift Evolution github 
>> archive no longer point to valid web links. I have pasted a list of gmane 
>> links at the end of this message. As gmane's "robots.txt" disallowed 
>> crawling, Google has not preserved the titles or text of the links, which 
>> makes finding some of these a little tricky.
>> 
>> Here are the remaining links that are not yet converted. Please consider 
>> adopting a proposal, tracking down its links, and mailing this thread with 
>> the proposal number, gmane links and pipermail equivalents. Pipermail is 
>> located at https://lists.swift.org/pipermail/swift-evolution/ 
>> . Some of these may 
>> refer to  build dev discussions instead of evolution ones. If you can, 
>> please track down to the exact message for rationale, and the thread for 
>> discussion and review links.
> 
> Completely agreed.  All of these should point to https://lists.swift.org 
>  (and always should have, exactly for reasons like 
> this).  I’d appreciate any PRs to help clean up the evolution repo to point 
> to https://lists.swift.org  instead.
> 
> Thanks!
> 
> -Chris
> 
> 
>> 
>> -- E
>> 
>> proposals/0010-add-staticstring-unicodescalarview.md:* Status: **Rejected** 
>> ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/7697 
>> ))
>> proposals/0010-add-staticstring-unicodescalarview.md:[Swift Evolution 
>> Discussion 
>> Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9366 
>> ), 
>> [Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/2434 
>> )
>> proposals/0011-replace-typealias-associated.md:* Status: **Accepted for 
>> Swift 2.2** 
>> ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/2883 
>> ), 
>> [Bug](https://bugs.swift.org/browse/SR-511 
>> ))
>> proposals/0011-replace-typealias-associated.md:[Swift Evolution Discussion 
>> Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9301 
>> )
>> proposals/0012-add-noescape-to-public-library-api.md:[Swift Evolution 
>> Discussion Thread](http://thread.gmane.org/gmane.comp.lang.swift.corelibs/53 
>> )
>> proposals/0013-remove-partial-application-super.md:[Swift Evolution 
>> Discussion 
>> Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9778 
>> ), 
>> [Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/2880 
>> )
>> proposals/0014-constrained-AnySequence.md:* Status: **Accepted for Swift 
>> 2.2** 
>> ([Rationale](http://article.gmane.org/gmane.comp.lang.swift.evolution/9746/match=constraining+anysequence
>>  
>> 

Re: [swift-evolution] [Proposal] autocreate parameter for optional values

[Saagar Jha via swift-evolution]

If the compiler can figure out the type of the expression, you can use [:] in 
place of [NSObject: AnyObject], as below:

let config = URLSessionConfiguration.default
var headers = config.httpAdditionalHeaders ?? [:]
headers["Some-Additional-Info"] = "1992-08-01"

Saagar Jha



> On Jul 28, 2016, at 19:08, Kwanghoon Choi via swift-evolution 
>  wrote:
> 
> Dear swifters. 
> 
> I have an proposal for autocreation of optional variables
> 
> This idea came from below situation
> 
> I have to addtional header to NSURLSessionConfiguration like this
> 
> let config = NSURLSessionConfiguration.defaultSessionConfiguration()
> config.HTTPAdditionalHeaders?["Some-Additional-Info"] = "1992-08-01"
> 
> here is the problem
> 
> how to be sure not nil for HTTPAdditionalHeaders in 
> defaultSessionConfiguration
> 
> may be nil or not nil, I read api reference of HTTPAdditionalHeaders but, 
> did't see  for value state of creation.
> 
> yeah, I know. it's optional. so may be I should thought it must be nil. but 
> really must be? I think it's not very clear logic.
> 
> anyway, HTTPAdditionalHeaders was nil. so i have to solve, and solve like 
> this.
> 
> let config = NSURLSessionConfiguration.defaultSessionConfiguration()
> var headers = config.HTTPAdditionalHeaders ?? [NSObject: AnyObject]()
> headers["Some-Additional-Info"] = "1992-08-01"
> 
> May be another way to solve this.
> 
> so I suggest autocreate parameter or something like that
> 
> NSURLSessionConfiguration have this variable
> public var HTTPAdditionalHeaders: [NSObject : AnyObject]?
> 
> change above things to like below
> public autocreate var HTTPAdditionalHeaders: [NSObject : AnyObject]? {
> 
> create { return [NSObject: AnyObject]() }
> 
> }
> 
> 
> 
> let headers = config.HTTPAdditionalHeaders must be return nil
> 
> but 
> 
> config.HTTPAdditionalHeaders["SomeThinkConvenient"] = "YEAH~"
> 
> this is automatically create Dictionary and set key and value
> 
> 
> 
> What about this idea, Dears?
> 
> 
> 
> Thank you for reading.
> 
> ___
> 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] End of source-breaking changes for Swift 3

[Saagar Jha via swift-evolution]

The reason C-style for loops were removed were because most of the time they 
could be represented by Swift syntax. Have you taken a look at 
stride(from:to:by:)?

Saagar Jha



> On Jul 28, 2016, at 15:08, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Hi Austin,
> 
> please read inline.
>> On 28.07.2016, at 23:47, Austin Zheng > > wrote:
>> 
>> 
>> 
>> On Thu, Jul 28, 2016 at 2:37 PM, Ted F.A. van Gaalen > > wrote:
>> Hi Austin, thank you, please see inline
>> ? 
>> I have explained this many times before, didn’t I? 
>> 
>> Its removal causes a very crucial limitation/change in the way 
>> one writes programs, So writing about this for;; subject is
>> very, very different from long discussions like those about 
>> allowing a comma at the end of a list or not…
>> because removing the for;; has a very heavy impact.
>> 
>> Furthermore, IMHO the decision to remove the for;; was based
>> on very subjective loose and partly irrelevant criteria.
>> 
>> 
>> I don't care how good your reasons are, the fact of the matter is that it 
>> was extensively discussed, a decision was made, and it is now a done deal.
> Napoleon said something similar when pushing his army towards Moscow...
>> Please remember that these are high-traffic lists that many people subscribe 
>> to; complaining about the C for loop is a waste of everybody's time.
> That’s your opinion.
>> At the very least, please respect the process and put together a proposal 
>> that we can all discuss,
> As written before, I will write the proposal after Swift 3.0 is released.
> If you are interested in bringing it back then you could help
> me with it.
>> instead of asking Chris or whoever to step in and make an exception because 
>> you don't like it.
> Yes, indeed, I am exceptionally asking to make an exception, to keep the for 
> ;; in
> for the time being.
> 
> As concerning your “high traffic” notion, this is written material
> no doubt, the recipients are capable enough to put it aside for later
> if they’d wish to do so. 
> 
> Sorry, if you don’t like it.
> Thanks.
> TedvG
> 
> 
> 
> ___
> 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] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Saagar Jha via swift-evolution]

There’s remove, which is mutating in that it actually removes the elements from 
the target. removing, on the other hand is nonmutating and basically gives a 
copy and then removes from the copy.
Saagar Jha



> On Jul 25, 2016, at 21:21, Boris Wang via swift-evolution 
>  wrote:
> 
> "When the operation is naturally described by a verb, use the verb’s 
> imperative for the mutating method and apply the “ed” or “ing” suffix to name 
> its nonmutating counterpart."
> 
> I known it. But, the "verb" here should be a action will change the object. 
> Not every verb will change the object.
> 
> Like the word: peek ,copy.
> 
> In socket program, there's a action "peek", just check if there has new data 
> in socket data buffer, not move out the data(like the API receive()). It's 
> not "receiving".
> 
> 
> Daniel Duan mailto:dan...@duan.org>>于2016年7月26日 周二11:39写道：
> Please read the naming section in Swift API design guidelines 
> https://swift.org/documentation/api-design-guidelines/#naming 
> 
> 
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Jul 25, 2016, at 8:29 PM, Boris Wang via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> I am curious about the reason using "removing",
>> What we are doing is not remove, just selecting some elements from the 
>> original collection.
> 
>> ___
> 
>> 
>> 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] [Draft] Fix a typo in two String methods

[Saagar Jha via swift-evolution]

Ahh…I agree in that case; something like `utf8Array` might be a better choice.
Saagar Jha



> On Jul 24, 2016, at 16:44, Xiaodi Wu  wrote:
> 
> On Sun, Jul 24, 2016 at 6:42 PM, Saagar Jha  > wrote:
> Well, yes, but hardly anyone calls it a “char array” unless they’re trying to 
> emphasize the fact that it’s not being used as a String.
> 
> I was woefully unclear with that last email. IMO, `utf8CString` is fine, 
> since a CString really is a null-terminated array of CChars. But `utf8String` 
> implies that the property is a String, which `nulTerminatedUTF8` is not (it's 
> a `ContiguousArray`).
> 
> Saagar Jha
> 
> 
> 
>> On Jul 24, 2016, at 15:58, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution 
>> > mailto:swift-evolution@swift.org>> wrote:
>> >
>> > Xiaodi Wu via swift-evolution  writes:
>> >
>> >
>> >> In `String`, the methods `nulTerminatedUTF8` and
>> >> nulTerminatedUTF8CString` have the word "null" misspelled
>> >
>> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
>> 
>> One would hope so. A series of characters terminated by a zero byte.
>> 
>>   /// A contiguously stored null-terminated UTF-8 representation of
>>   /// the string.
>>   ///
>>   /// This is a variation on nulTerminatedUTF8 that creates an array
>>   /// of element type CChar for use with CString API's.
>> 
>> I think utf8String and utf8CString capture both meanings. I know they're
>> a little redundant but they get the meaning across, use CString term of
>> art, and are pithy compared to any alternatives (like "representation", etc)
>>  
>> They're arrays though, not strings.
>> 
>> -- E
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 

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

Re: [swift-evolution] [Draft] Fix a typo in two String methods

[Saagar Jha via swift-evolution]

Well, yes, but hardly anyone calls it a “char array” unless they’re trying to 
emphasize the fact that it’s not being used as a String.

Saagar Jha



> On Jul 24, 2016, at 15:58, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sun, Jul 24, 2016 at 5:34 PM, Erica Sadun via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> > On Jul 24, 2016, at 3:45 PM, Dave Abrahams via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > Xiaodi Wu via swift-evolution  writes:
> >
> >
> >> In `String`, the methods `nulTerminatedUTF8` and
> >> nulTerminatedUTF8CString` have the word "null" misspelled
> >
> > Whoa. Isn't "Cstring" redundant with "null-terminated?"
> 
> One would hope so. A series of characters terminated by a zero byte.
> 
>   /// A contiguously stored null-terminated UTF-8 representation of
>   /// the string.
>   ///
>   /// This is a variation on nulTerminatedUTF8 that creates an array
>   /// of element type CChar for use with CString API's.
> 
> I think utf8String and utf8CString capture both meanings. I know they're
> a little redundant but they get the meaning across, use CString term of
> art, and are pithy compared to any alternatives (like "representation", etc)
>  
> They're arrays though, not strings.
> 
> -- E
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Ah, I understand now; that’s a good point.

On Wed, Jul 20, 2016 at 9:54 PM Charlie Monroe 
wrote:

> To use the parameters, the function would have to check for nil anyways,
> right (or risk a crash at runtime)? If the parameter is changed from an IUO
> to an Optional, the check for nil simply becomes a shadowing with guard.
>
>
> And what if the overridden method returns "T!"? It would become T? in the
> code, while the original API expects a non-nil value. This IMHO adds
> confusion to the language. As I've mentioned previously, these are examples
> that you'd get:
>
> func addObject(object: AnyObject?)
> func objectAtIndex(index: Int) -> AnyObject?
>
> This is from NSArray, but if you had a similar un-audited API, then
> created your subclass of this, you'd get something semantically completely
> different and users of your API would assume you can pass nil to addObject
> and that objectAtIndex can return nil.
>
> In case of addObject, would you just silently ignore the nil, or would you
> crash as NSArray would?
>
> Yes, it's unexpected sometimes to find nil coming from these methods, or
> getting them as arguments, but it's just as unexpected as finding out that
> your app is crashing because it's accessing index out of bounds.
>
>
> Saagar Jha
>
>
>
> On Jul 20, 2016, at 21:10, Chris Lattner  wrote:
>
>
> On Jul 20, 2016, at 5:24 PM, Saagar Jha  wrote:
>
> Sorry for the last email…I didn’t see your response.
>
> I realize that disallowing IUOs in parameters (but not as properties) is
> inconsistent, but IUOs for properties make sense: they must be set during
> initialization, but sometimes this isn’t possible. IUOs make it possible to
> use the property just as any other non-Optional one, *provided the
> property is set before it is used* (see the proposal). This kind of
> guarantee doesn’t work for function parameters and return values.
>
> As for IUOs for non-audited methods; why can’t they just all use Optional
> parameters? It should have the same behavior as before, since you can pass
> in both an Optional as well as a non-Optional even today.
>
>
> Because an override of an unaudited method has to *use* the parameters.
>
> -Chris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Saagar Jha via swift-evolution]

Sorry, my word choice here is poor. I meant that Swift Strings don’t really 
match up with character arrays in the usual sense; your “subscript” is O(n). 
Use a Range instead.
Saagar Jha



> On Jul 20, 2016, at 18:52, Ted F.A. van Gaalen  wrote:
> 
>> 
>> On 21.07.2016, at 03:15, Saagar Jha > > wrote:
>> 
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jul 20, 2016, at 18:02, Ted F.A. van Gaalen via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi Nevin,
>>> 
>>> extension String
>>> {
>>> var count: Int
>>> {
>>> get
>>> {
>>> return self.characters.count
>>> }
>>> }
>>> 
>>> // Sigh... String subscriptors should be already builtin in the String
>>> 
>> 
>> Swift Strings use grapheme clusters, so subscripting doesn’t really work.
> ?? sorry Saagar, but it does! try this code in Swift Playground
> I mean that the subscritp functions implemented below could just as well be 
> builtin.
> Ted
>> 
>>> subscript (idx: Int) -> String
>>> {
>>> get
>>> {
>>> return self.substringWithRange(
>>> 
>>> self.startIndex.advancedBy(idx)..>> )
>>> }
>>> }
>>> 
>>> // range subscript [n1..n2] or [n1...n2]
>>> 
>>> 
>>> subscript (r: Range) -> String
>>> {
>>> get
>>> {
>>> return self.substringWithRange(
>>> 
>>> self.startIndex.advancedBy(r.startIndex)..>>   )
>>> }
>>>  }
>>> 
>>> //
>>> func hazPrefix(s: String) -> Bool
>>> {
>>> if self.isEmpty && s.isEmpty  // both are empty: match
>>> {
>>> return true
>>> }
>>> 
>>> if self.isEmpty || s.isEmpty ||
>>>(s.count > self.count)
>>> {
>>> return false
>>> }
>>> 
>>> var match = true
>>> 
>>> for i in 0..>> {
>>> if self[i] != s[i]
>>> {
>>> match = false
>>> break
>>> }
>>> }
>>> 
>>> return match
>>> }
>>> ///
>>> } // end String extensions.
>>> 
>>> 
>>> 
>>> let s = "abcdefghijklmnopqrstuvwxyz"
>>> let emptystr = ""
>>> let emptystr2 = ""
>>> 
>>> print( s.hazPrefix("abc") )   // true
>>> 
>>> print( s.hazPrefix("") )  // false
>>> print( s.hazPrefix("Led Zeppelin.") ) // false
>>> print( emptystr.hazPrefix("Swift") )  // false
>>> 
>>> print(emptystr.hazPrefix(emptystr) )  // true
>>> 
>>> 
>>> Please see further in-line comments below: 
>>> 
>>> Kind Regards,
>>> Ted
>>>  
>>> 
 On 21.07.2016, at 00:57, Nevin Brackett-Rozinsky 
 >>> > wrote:
 
 On Wed, Jul 20, 2016 at 6:32 PM, Ted F.A. van Gaalen via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 Hi,
 
 Mathematical correct or not: 
 
 in case of 
  s1.hasPrefix(s2)
  (or any other containment test method) 
 
 s1 and s2 are just plain simple instances of String,
 nothing more nothing less. 
 
 Which is interpreted by me as: 
 “test if String s1 starts with String s2”
 
 
 …which means, “Do the first n characters of s1 match s2, where n is the 
 length of s2?”
>>> Yes,. and of course  s1.count   <= s2.count. 
 
 When s2 is the empty string, n is 0.
>>> 
 
 What are the first 0 characters of s1? Clearly the empty string, since 
 that is the only string with 0 characters.
 
 Do the first 0 characters of s1 match s2? Well they are both the empty 
 string, and ""=="" is true, so…
 
 That would be a resounding “Yes!”
>>> how  dumb (for “”.hasPrefix(“”) ), my mistake. (handled correctly imho in 
>>> code example above)
>>> however, that is a matter of definition:
>>> should “search for nothing in nothing” return “true” ??
>> 
>> Yes. For example, if you’re searching for “a” in the String “a”, you’d 
>> return true. Same thing for search for a nothing in a nothing-if the object 
>> is what you’re searching for, you can say it contains it.
>> 
>>> 
>>> Again, Strings to me are just character arrays…
>>>  
 
 Nevin
 
 
  
 which, to me,  implies that one will never find an occurrence
 of an empty string within another string,
 for the very simple reason that an empty string
 does not exist within another string. **
 Ergo: “false” is the right evaluation when s2.isEmpty.
 
 ** In my mental model, a String is just an array of 0...n characters,
   like it is in most languages, very straightforward.
 
  (returning false) This is exactly the reason why NSString does that, 
 for more than 20 years, why change it?
 
 

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

To use the parameters, the function would have to check for nil anyways, right 
(or risk a crash at runtime)? If the parameter is changed from an IUO to an 
Optional, the check for nil simply becomes a shadowing with guard.

Saagar Jha



> On Jul 20, 2016, at 21:10, Chris Lattner  wrote:
> 
> 
>> On Jul 20, 2016, at 5:24 PM, Saagar Jha > > wrote:
>> 
>> Sorry for the last email…I didn’t see your response.
>> 
>> I realize that disallowing IUOs in parameters (but not as properties) is 
>> inconsistent, but IUOs for properties make sense: they must be set during 
>> initialization, but sometimes this isn’t possible. IUOs make it possible to 
>> use the property just as any other non-Optional one, provided the property 
>> is set before it is used (see the proposal). This kind of guarantee doesn’t 
>> work for function parameters and return values. 
>> 
>> As for IUOs for non-audited methods; why can’t they just all use Optional 
>> parameters? It should have the same behavior as before, since you can pass 
>> in both an Optional as well as a non-Optional even today.
> 
> Because an override of an unaudited method has to *use* the parameters.
> 
> -Chris

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

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Saagar Jha via swift-evolution]

Saagar Jha



> On Jul 20, 2016, at 18:02, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Hi Nevin,
> 
> extension String
> {
> var count: Int
> {
> get
> {
> return self.characters.count
> }
> }
> 
> // Sigh... String subscriptors should be already builtin in the String
> 

Swift Strings use grapheme clusters, so subscripting doesn’t really work.

> subscript (idx: Int) -> String
> {
> get
> {
> return self.substringWithRange(
> 
> self.startIndex.advancedBy(idx).. )
> }
> }
> 
> // range subscript [n1..n2] or [n1...n2]
> 
> 
> subscript (r: Range) -> String
> {
> get
> {
> return self.substringWithRange(
> 
> self.startIndex.advancedBy(r.startIndex)..   )
> }
>  }
> 
> //
> func hazPrefix(s: String) -> Bool
> {
> if self.isEmpty && s.isEmpty  // both are empty: match
> {
> return true
> }
> 
> if self.isEmpty || s.isEmpty ||
>(s.count > self.count)
> {
> return false
> }
> 
> var match = true
> 
> for i in 0.. {
> if self[i] != s[i]
> {
> match = false
> break
> }
> }
> 
> return match
> }
> ///
> } // end String extensions.
> 
> 
> 
> let s = "abcdefghijklmnopqrstuvwxyz"
> let emptystr = ""
> let emptystr2 = ""
> 
> print( s.hazPrefix("abc") )   // true
> 
> print( s.hazPrefix("") )  // false
> print( s.hazPrefix("Led Zeppelin.") ) // false
> print( emptystr.hazPrefix("Swift") )  // false
> 
> print(emptystr.hazPrefix(emptystr) )  // true
> 
> 
> Please see further in-line comments below: 
> 
> Kind Regards,
> Ted
>  
> 
>> On 21.07.2016, at 00:57, Nevin Brackett-Rozinsky 
>> mailto:nevin.brackettrozin...@gmail.com>> 
>> wrote:
>> 
>> On Wed, Jul 20, 2016 at 6:32 PM, Ted F.A. van Gaalen via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Hi,
>> 
>> Mathematical correct or not: 
>> 
>> in case of 
>>  s1.hasPrefix(s2)
>>  (or any other containment test method) 
>> 
>> s1 and s2 are just plain simple instances of String,
>> nothing more nothing less. 
>> 
>> Which is interpreted by me as: 
>> “test if String s1 starts with String s2”
>> 
>> 
>> …which means, “Do the first n characters of s1 match s2, where n is the 
>> length of s2?”
> Yes,. and of course  s1.count   <= s2.count. 
>> 
>> When s2 is the empty string, n is 0.
> 
>> 
>> What are the first 0 characters of s1? Clearly the empty string, since that 
>> is the only string with 0 characters.
>> 
>> Do the first 0 characters of s1 match s2? Well they are both the empty 
>> string, and ""=="" is true, so…
>> 
>> That would be a resounding “Yes!”
> how  dumb (for “”.hasPrefix(“”) ), my mistake. (handled correctly imho in 
> code example above)
> however, that is a matter of definition:
> should “search for nothing in nothing” return “true” ??

Yes. For example, if you’re searching for “a” in the String “a”, you’d return 
true. Same thing for search for a nothing in a nothing-if the object is what 
you’re searching for, you can say it contains it.

> 
> Again, Strings to me are just character arrays…
>  
>> 
>> Nevin
>> 
>> 
>>  
>> which, to me,  implies that one will never find an occurrence
>> of an empty string within another string,
>> for the very simple reason that an empty string
>> does not exist within another string. **
>> Ergo: “false” is the right evaluation when s2.isEmpty.
>> 
>> ** In my mental model, a String is just an array of 0...n characters,
>>   like it is in most languages, very straightforward.
>> 
>>  (returning false) This is exactly the reason why NSString does that, 
>> for more than 20 years, why change it?
>> 
>> AFAIK no one has complained about this for years, 
>> because imho it is logically sound. 
>> 
>> for a compiler this is very easy
>> all it has to do is to return False
>> when either s1 or s2 is empty.
>> 
>> 
>> Ted
>> 
>> 
>>> On 19.07.2016, at 23:11, Jacob Bandes-Storch >> > wrote:
>>> 
>>> Not that it's needed, but another +1 from me.
>>> 
>>> a.hasPrefix(p) should be true iff there exists some string x for which p+x 
>>> == a.  If p == "", then x := a satisfies this, so hasPrefix should return 
>>> true.
>>> 
>>> Jacob
>>> 
>>> On Tue, Jul 19, 2016 at 1:29 PM, Jaden Geller via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> Both `hasPrefix` and `hasSuffix` are analogous to the more general 
>>> `hasSubset` function, which would return `true` for the empty set.
>>> 
 On Jul 19, 2016, at 12:32 PM, Bianca via swift-e

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Sorry for the last email…I didn’t see your response.

I realize that disallowing IUOs in parameters (but not as properties) is 
inconsistent, but IUOs for properties make sense: they must be set during 
initialization, but sometimes this isn’t possible. IUOs make it possible to use 
the property just as any other non-Optional one, provided the property is set 
before it is used (see the proposal). This kind of guarantee doesn’t work for 
function parameters and return values. 

As for IUOs for non-audited methods; why can’t they just all use Optional 
parameters? It should have the same behavior as before, since you can pass in 
both an Optional as well as a non-Optional even today.

Saagar Jha



> On Jul 20, 2016, at 17:13, Chris Lattner  wrote:
> 
>> 
>> On Jul 20, 2016, at 12:52 PM, Chris Lattner > > wrote:
>> 
>> On Jul 19, 2016, at 3:46 PM, Saagar Jha > > wrote:
>>> 
>>> I have updated the proposal here 
>>> . Since 
>>> this is a potentially a source breaking change, I’d like this to be 
>>> considered for Swift 3; unless anyone has any issues with it, I’m going to 
>>> push this to swift-evolution.
>> 
>> Some comments:
>> - The syntax proposed would be *completely* unlike anything in Swift, and is 
>> semantically changing things unrelated to the type.
>> - This proposal doesn’t work, and overly punishes IUOs.
>> 
>> I recommend that we do not discuss this proposal, as it would not be a good 
>> use of community time.  Beyond the unworkability of this specific proposal, 
>> in my personal opinion, there is nothing wrong with the T! syntax.  Making 
>> it significantly more verbose would be a very *bad* thing for the intended 
>> use cases.
> 
> Hi Saagar,
> 
> I’m sorry for the response above, I apparently misunderstood your early 
> example to read it as putting the force unwrapping concept into the 
> “forceUnwrapping” parameter label.
> 
> I now see that your idea is to remove force unwrapping entirely for 
> parameters.  I am very concerned about this and think it would not be 
> accepted into Swift.  It makes the language less consistent (why can you do 
> it on a property, but not a parameter) and eliminates important use cases for 
> T!: overriding an non-nullability audited method.
> 
> -Chris

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

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Oh, no, they’re just external function parameter names that I put to try to 
make it more clear. Looks like it didn’t really work :)

Saagar Jha



> On Jul 20, 2016, at 17:19, William Jon Shipley  
> wrote:
> 
> Are “forceUnwrapping” and “withoutUnwrapping” special keywords here or are 
> they just there to try to explain what you’re doing? Because I was very 
> confused by them.
> 
> -Wil

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

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

(Comments inline)
Saagar Jha



> On Jul 20, 2016, at 16:47, Saagar Jha  wrote:
> 
> 
> 
> On Wed, Jul 20, 2016 at 12:52 PM Chris Lattner  <mailto:clatt...@apple.com>> wrote:
> On Jul 19, 2016, at 3:46 PM, Saagar Jha  <mailto:saagarjh...@gmail.com>> wrote:
>> 
>> I have updated the proposal here 
>> <https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453>. Since 
>> this is a potentially a source breaking change, I’d like this to be 
>> considered for Swift 3; unless anyone has any issues with it, I’m going to 
>> push this to swift-evolution.
> 

I know you don’t really want to discuss it, but since I don’t quite get what 
you mean, I was wondering if you could clarify a bit more why this proposal is 
inappropriate.

> Some comments:
> - The syntax proposed would be *completely* unlike anything in Swift, and is 
> semantically changing things unrelated to the type.

There is no new syntax proposed; it is simply a restriction on the current 
syntax of using IUOs in functions, which I feel encourages unsafe behavior. The 
“syntax change” is no more than changing something like this:

func triple(forceUnwrapping aNumber: Int!) -> Int? {
guard aNumber != nil else {
return nil
}
return aNumber * 3
}
to

func triple(withoutUnwrapping aNumber: Int?) -> Int? {
guard let aNumber = aNumber else { // simply transform the check
return nil
}
return aNumber * 3
}

There’s not much of a difference, except that at the it makes it easier to see 
that nil is properly handled at the call site.

> - This proposal doesn’t work, and overly punishes IUOs.

My goal is not to “punish” IUOs. I recognize that IUOs have valid uses, for 
example during initialization–and I want to leave this alone since this is the 
purpose of IUOs. My issue is with IUOs being “used as Optionals” in that they 
are allowed to have a nil value and checked for it (or not, with disastrous 
results). I’ve yet to see a function with an IUO parameter that couldn’t be 
rewritten to be clearer and more safe with a plain Optional parameter. Is there 
anything I’ve overlooked?

> 
> I recommend that we do not discuss this proposal, as it would not be a good 
> use of community time.  Beyond the unworkability of this specific proposal, 
> in my personal opinion, there is nothing wrong with the T! syntax.  Making it 
> significantly more verbose would be a very *bad* thing for the intended use 
> cases.

As before, this proposal is not an attack on IUOs and the T! syntax, it’s 
against their misuse as function parameters and return values. A significant 
increase in verbosity is obviously undesirable, but I don’t see how this 
proposal will cause an increase in length.

> 
> -Chris
> 
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jul 5, 2016, at 13:30, Saagar Jha >> <mailto:saagarjh...@gmail.com>> wrote:
>>> 
>>> Gave me a chuckle, but yeah, basically.
>>> 
>>> On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley 
>>> mailto:w...@delicious-monster.com>> wrote:
>>> On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>>> When I see an IUO property, I consider it a sort of “contract”–it’s 
>>>> basically saying something like “I can’t set this to a valid value right 
>>>> now, but by the time you use it I promise that it’s non nil”
>>> 
>>> You might say that an IUO is sort of an IOU?
>>> 
>>> -W
>>> -- 
>>> -Saagar Jha
>> 

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

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

I have updated the proposal here 
<https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453>. Since 
this is a potentially a source breaking change, I’d like this to be considered 
for Swift 3; unless anyone has any issues with it, I’m going to push this to 
swift-evolution.

Saagar Jha



> On Jul 5, 2016, at 13:30, Saagar Jha  wrote:
> 
> Gave me a chuckle, but yeah, basically.
> 
> On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley 
> mailto:w...@delicious-monster.com>> wrote:
> On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>> When I see an IUO property, I consider it a sort of “contract”–it’s 
>> basically saying something like “I can’t set this to a valid value right 
>> now, but by the time you use it I promise that it’s non nil”
> 
> You might say that an IUO is sort of an IOU?
> 
> -W
> -- 
> -Saagar Jha

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

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

[Saagar Jha via swift-evolution]

Was the problem with the ternary conditional operator that nothing could be
found to replace it? That doesn't seem to be the issue here.
On Mon, Jul 18, 2016 at 00:02 Jose Cheyo Jimenez via swift-evolution <
swift-evolution@swift.org> wrote:

> I think this proposal is not
>
>  ""better enough" for it to make sense to diverge from the precedent
> established by the C family of languages.”
>
> And I think the same would go for this
>
> “Swift is designed to feel like a member of the C family of languages.
> Switching keywords away from C precedent without strong motivation is a
> non-goal”
>
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
>
> I just don’t think we gain much by switching to curly braces.
>
> I made a similar argument about getting rid of the elvis operator ( ?: )
> because it used colons and question marks.
>
>
>
>
> On Jul 17, 2016, at 2:27 PM, G B via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think the discussion on this has run its course and it sounds like
> there’s mixed feelings, but it’s mostly a matter of opinion between
> consistency and “ugliness”.  As I understand it, the “socialization”
> process isn’t meant to reach consensus, but to hone the proposal (or
> abandon it if the feedback is overwhelmingly negative).  I think my last
> formulation is probably as well formed as I’ll get with the idea, I think
> there’s still mixed feedback, and a review is the way to settle the
> differences of opinion.
>
> I think a proposal like this is in scope for Swift 3, and this is probably
> the last reasonable opportunity to consider it for a while, is that correct?
>
> If so, I’ll put together a formal proposal.
>
> The general process is described here:
> https://github.com/apple/swift-evolution/blob/master/process.md
> but I just want to double check the process because I’m not terribly
> familiar with GitHub, pull requests, etc and want to avoid generating more
> noise than I need to:
>
>
> I need to clone the swift-evolution repo
> Create a local branch
> Copy the proposal template, and edit it for the proposal
> Push the branch (do I need special permissions for this, or can anyone
> push a branch?)
> Flag the branch for a pull request
>
> Presumably someone else along the line assigns it a number.
>
>
> Anything else I need to consider?
>
>
>
>
> On Jul 11, 2016, at 02:04 , James Froggatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> While I'm not keen on introducing braces, your comparison to property
> getters and setters is a good one. This is an inconsistency.
>
> To be honest, I wouldn't mind putting up with braces for a while, with the
> promise that we'll get a lightweight alternative to the switch statement,
> like the ternary operator is to if statements.
> I feel like I use switch much more often to initialise a variable, or
> return a value, than I do to branch program logic (especially working with
> with enums), and it already seems a very heavy construct in these cases.
>
>  Begin Message 
> Group: gmane.comp.lang.swift.evolution
> MsgID: <0c3ec993-9320-4f4c-b2aa-66967bedf...@gmail.com>
>
> The discussion so far has given me a chance to organize my thinking, so
> here’s a more complete train of thought.
>
> I get that people don’t like extra punctuation.  The commonly rejected
> proposals, however, make it clear that braces are here to stay and we
> should be designing the syntax right now with that in mind.  It took me a
> long time to get used to not using them in Python, now I’m getting used to
> using them again in Swift.  Swift has a long life ahead of it, and there
> are going to be plenty of places where the syntax is going to become
> inconsistent in the service of supporting new features.  Now is when we set
> the starting point though and try to set ourselves up in a way that
> requires a minimum of syntax goofs in the future.
>
>
> ―=Philosophy=―
>
> As philosophical backdrop, here’s the link on removing braces in the
> “commonly rejected proposals” section:
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html
>
> I’ll pull out two quotes from that post, one from Kevin Ballard:
> "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 another edited as suggested by Chris Lattner:
> "'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 is most familiar to programmers in the extended C family is a good
> idea."
>
>
> So, from that I take:
> 1) braces indicate scoping
> 2) conciseness isn’t an end in itself
> 3) we should err on the side of being Cish when no other arguments prevail.
>
>
>
>
> ―=In C `cases` Aren’t Scopes, in Swif

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Saagar Jha via swift-evolution]

Equatable, where the == operator is defined, will not let you compare two
things of a different type.
On Fri, Jul 15, 2016 at 10:02 Johannes Neubauer 
wrote:

>
> > Am 15.07.2016 um 18:41 schrieb Johannes Neubauer via swift-evolution <
> swift-evolution@swift.org>:
> >
> >
> >> Am 15.07.2016 um 18:29 schrieb Saagar Jha :
> >>
> >> Here's a value type that uses custom equality (at least, I think so):
> String. Since it uses extended grapheme clusters, internally two Strings
> may be composed of different Unicode scalars, but if they create the same
> Characters they are considered to be equal.
> >
> > Good point. But shouldn’t this be another type of equality then or do
> they behave exactly the same and are just implemented differently? Because
> if not, this seems to be introducing mixed-type comparisons like `5l == 5`
> or `Point2D(0, 0) == Point3D(0, 0, 0) which are bad since they make it
> impossible to guarantee reflexivity, symmetry, and transitivity. Swift does
> a hard job to enforce this from the programmer. If this is really intended,
> then there should be a fixed implementation for equality of value types,
> which can be overridden, but which leads to a warning (which has to be
> suppressed with some kind of annotation or so). Because, these custom
> implementations can do harm.
>
> And I would do the „standard equality“ upfront even if there is a custom
> implementation and if the „standard equality“ says `true`, the custom
> implementation is not asked. This would reduce the possibility of
> false-negatives.
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Saagar Jha via swift-evolution]

Here's a value type that uses custom equality (at least, I think so):
String. Since it uses extended grapheme clusters, internally two Strings
may be composed of different Unicode scalars, but if they create the same
Characters they are considered to be equal.

On Fri, Jul 15, 2016 at 09:12 Johannes Neubauer via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Am 15.07.2016 um 15:19 schrieb Shawn Erickson :
> >
> > Additional two "things" maybe considered equal in the chosen problem
> domain despite their identity (memory location, etc.) being different.
> Having the ability to supply custom hash and equality for types can be a
> useful tool in a developers toolbox. For example two pathways of code may
> create what is actually the same thing (say a reference to the same file on
> disk) then want to work with stdlib set and/or dictionary with the
> equivalent things being resolved correctly, etc.
> >
> > To remove custom equality will limit some designs and to force identity
> based equality with present similar problems on the other end of the
> spectrum.
>
> It is only for value types. For reference types, which have an identity,
> you are right, but it doesn’t hold for values.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] executing a string

[Saagar Jha via swift-evolution]

Here’s

how selectors in Swift work, based on this

proposal. Swift’s selectors are a lot safer than Objective-C’s.

> > > > > One of the major security flaws of Obj C is > > the ability to
convert a string into a selector, which > > permits using private methods
by constructing selectors > > at runtime long after the app store review
has been completed. > > Does Swift do away with that? I understand it
doesn't > > use selectors per se but is there an analogous mechanism? > > >
> >

--

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

On Thu, Jul 14, 2016 at 08:49 Ford Prefect via swift-evolution
swift-evolution@swift.org wrote:


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

Re: [swift-evolution] Change subscripts to use colons

[Saagar Jha via swift-evolution]

Feels like an abuse of subscripting IMHO. I'm fine with parametrized properties 
but the subscript doesn't quite fit in this case. 

Sent from my Apple Watch

On Jul 11, 2016, at 23:24, David Hart via swift-evolution 
 wrote:

> How about a proposal for named subscripts?
> 
> button.image[for: .normal] = image
> 
> defined using:
> 
> subscript image(for: UIControlState): UIImage? {
>   get { … }
>   set { … }
> }
> 
>> On 12 Jul 2016, at 00:29, Tim Vermeulen via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 12 Jul 2016, at 00:20, Jacob Bandes-Storch  wrote:
>>> 
>>> When would you want to use this instead of something like `button[imageFor: 
>>> .normal]` ?
>> 
>> All the time, basically. Primarily because IMO it doesn’t really make sense 
>> to make “image” part of the argument label for the control state - we just 
>> have to (using subscripts) because subscripts themselves can’t be named. I 
>> think most people would agree that
>> 
>> let image = button.image(for: .normal)
>> 
>> is more readable than
>> 
>> let image = button[imageFor: .normal]
>> 
>> and likewise, I would prefer
>> 
>> button.image(for: .normal) = image
>> 
>> over
>> 
>> button[imageFor: .normal] = image
>> 
>>> On Mon, Jul 11, 2016 at 3:00 PM, Tim Vermeulen via swift-evolution 
>>>  wrote:
 Slightly related to this, I would really love to have non-subscript 
 parameterized properties. It would allow us to write
 
 button.image(for: .normal) = image
 
 instead of
 
 button.setImage(image, for: .normal)
 
 The same can be achieved through subscripts, but it’s not always as nice. 
 It would bring subscripts and computed properties closer together, which 
 also seems to be the goal of your proposal. Perhaps the two ideas could be 
 combined?
 
 > Subscripts are a hybrid of properties and functions, since they have a 
 > parameter list, as well as getters and setters, so use of either symbol 
 > will be unusual in this case.
 > 
 > However, I think a colon is more suitable, since it implies the 
 > possibility to set the value.
 > 
 > 
 > In the future, if we add throwing getters/ setters:
 > 
 > subscript(_ position: Int) ->Element {
 > get {
 > return …
 > }
 > throwing set {
 > …
 > }
 > }
 > 
 > Should this require ‘throws ->Element’? Using a colon also removes this 
 > potentially confusing case.
 > 
 > 
 > 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Require "infix" for infix operator function declarations

[Saagar Jha via swift-evolution]

I wouldn’t go as far as to require it, but having it for optional use “for 
symmetry" seems fine to me.

> On Jul 11, 2016, at 21:03, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Currently, "infix" is not required/allowed on an operator function 
> definition, but "prefix" and "postfix" are:
> 
> prefix operator ^^ {}   // valid
> postfix operator ^^ {}  // valid
> infix operator ^^ {}// valid
> 
> prefix func ^^(operand: Int) {}  // valid
> postfix func ^^(operand: Int) {} // valid
> infix func ^^(lhs: Int, rhs: Int) {}   // error: 'infix' modifier is not 
> required or allowed on func declarations
> func ^^(lhs: Int, rhs: Int) {} // valid
> 
> It seems like this was removed because it can be inferred from the number of 
> arguments 
> (https://github.com/apple/swift/commit/3ad9c58c18f0331444114e2eae3e772e702c326f
>  
> ).
>   But IMO the inconsistency from other operator function decls/defs is 
> jarring.
> 
> How does everyone feel about reinstating the "infix" modifier on functoins? 
> (It was removed before the open-source release and the advent of 
> swift-evolution, so I thought it'd be worth a public review.)
> 
> Jacob
> ___
> 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] adding Obj-C syntax to Swift?

[Saagar Jha via swift-evolution]

Not quite sure what you mean. Swift is designed to be somewhat similar to C and 
C++; the “Rust-like” syntax is merely because Rust does it like C does.
> On Jul 11, 2016, at 20:00, Ford Prefect via swift-evolution 
>  wrote:
>
> Perhaps one of the most disliked aspects of Swift
> is the Rust-like syntax, which requires that each coder resign himself to
> grin-and-bear-it in order to obtain the benefits of Swift.
> Since "the writing is on the wall" that Objective C
> is in its last days at least as far as app writers go
> (maybe within Apple it will endure), is there any
> chance of sweetening the pill a bit by giving us
> back the more readable syntax of Objective C, in particular
> the method call syntax? It just made more sense to
> format a method call like Smalltalk.
> ___
> 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] Optional comparison operators

[Saagar Jha via swift-evolution]

Correct me if I’m wrong, but wouldn’t you have to unwrap every comparison then?

> On Jul 11, 2016, at 20:02, David Sweeris via swift-evolution 
>  wrote:
>
> Why not have them return a `Bool?`? If both arguments are non-nil, it can 
> return the results of the comparison, otherwise it can return nil.
>
> - Dave Sweeris
>
> On Jul 7, 2016, at 16:37, Jacob Bandes-Storch via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>
>> These operators cause some potential for confusion:
>>
>> public func <(lhs: T?, rhs: T?) -> Bool
>> public func >(lhs: T?, rhs: T?) -> Bool
>> public func <=(lhs: T?, rhs: T?) -> Bool
>> public func >=(lhs: T?, rhs: T?) -> Bool
>>
>> 1. The meaning of T? < T? is not immediately obvious (Why is nil < .some(x) 
>> for any x? Personally, my intuition says that Optional should only provide a 
>> partial order, with .none not being ordered w.r.t. .some(x).)
>>
>> 2. Even if the meaning is understood, it can be surprising when the (T?, T?) 
>> -> Bool version is used instead of (T, T) -> Bool.
>>
>> Prior discussion:
>> - http://thread.gmane.org/gmane.comp.lang.swift.devel/2089 
>> 
>> - http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095 
>> 
>> - rdar:// 16966712&22833869
>> - Replies to https://twitter.com/jtbandes/status/646914031433871364 
>> 
>>
>> In the swift-dev thread from May, Chris said:
>>
>> One of the ideas that Joe Pamer has been discussing is whether the implicit 
>> promotion from T to T? should be disabled when in an operator context.  
>> Doing so would fix problems like this, but making the code invalid.
>>
>>
>> A change like this would be source-breaking, so if the core team has 
>> recommendations for how to handle these issues, now is probably the time to 
>> get it done.
>>
>> Jacob
>> ___
>> 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] Addition of a standardError OutputStream

[Saagar Jha via swift-evolution]

Thanks, I’ll write it up.
> On Jul 11, 2016, at 11:20, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Sun Jul 10 2016, Saagar Jha  wrote:
> 
>> What is the process for smaller issues like these? I’m guessing that
>> this doesn’t need a proposal; where should it go? On bugs.swift.org
>> ?
> 
> If it adds an API, it needs a proposal.  Doesn't necessarily have to be
> a big proposal, and the review period can be short, but we don't add
> APIs without the evolution process.
> 
> Thanks,
> Dave
> 
> -- 
> Dave
> 
> ___
> 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] Extending Swift Literals

[Saagar Jha via swift-evolution]

Not completely sold on this one. First, the literal part is already pretty much 
implied, and I'd prefer dropping it as it feels too "heavyweight". The other, 
more serious issue was already partially touched upon by Xiaodi, that a lot of 
these are basically String representations. The Bezier path is an extreme 
example. 

Sent from my Apple Watch

On Jul 10, 2016, at 20:48, Erica Sadun via swift-evolution 
 wrote:

> This is purely additive and would not be eligible for Swift 3. 
> gist: https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c
> 
> -- E
> 
> Extending Swift Literals
> Proposal: TBD
> Author: Erica Sadun
> Status: TBD
> Review manager: TBD
> Introduction
> 
> This proposal expands Swift's language literals to include common 
> cross-platform concepts that need not require.
> 
> Motivation
> 
> A Swift literal represents a fixed value in source code. A literal can be a 
> string, a number (for example an integer), a compound value (such as an 
> array), or one of several predefined "playground" literals including colors, 
> resource file paths, and resource images.
> 
> Swift literals do not have types. They are universal representations that are 
> evaluated and their types inferred from the context in which they are used. 
> Because their nature is typeless, the same color literal can initialize 
> UIColor, NSColor, and SKColor instances. The type cannot be inferred from the 
> source without the context of its destination.
> 
> let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 
> 0.4035313427, alpha: 1)
> Detailed Design
> 
> Namespace redesign
> Kind  Literal Parameters
> Color `#literal.color(red:, green:, blue:, alpha:)`   floating point values
> Image `#literal.image(resourceName:)` String with resource name
> File  `#literal.file(resourceName:)`  String with resource name
> General
> Kind  Literal Parameters
> Sound `#literal.audio(resourceName:)` String with resource name
> URL   `#literal.url(string:)`, `#literal.url(filePath:)`  String with 
> resource location
> Font  `#literal.font(face:, size:)`   string, floating point
> Date  `#literal.date(timeInterval:)`  floating point offset from Unix epoch
> Unicode   `#literal.unicode(name:)`   Official unicode name, e.g. 
> `#literal.unicode(name:"DOG FACE")`
> Geometry
> Kind  Literal Parameters
> Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, 
> `#literal.point(x:, y:, z:, w:)`floating point values
> Vector`#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, 
> `#literal.vector(dx:, dy:, dz:, dw:)`floating point
> Size  `#literal.size(width:, height:)`, `#literal.size(width:, height:, 
> depth:)`  floating point
> Rect  `#literal.rect(x:, y:, width:, height:)`floating point
> Affine Transform  `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, 
> `#literal.affineTransform(translateX:, translateY:)`, 
> `#literal.affineTransform(scaleY:, scaleY:)`, 
> `#literal.affineTransform(rotation:)`, floating point
> Bezier Path   `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 
> 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")`String with SVG 
> path notation
> Not included:
> 
> Attributed Strings: I would like to see a way to define attributed strings 
> (using some system like CSS/HTML) but could not think up a simple 
> representation similar to the others mentioned in the preceding table.
> 
> JSON Literals: Again, probably too complex and possibly not worth their 
> weight. If they could exist, they'd have to be imported via a resource or URL 
> and transformed to a local type.
> 
> Impact on Existing Code
> 
> This proposal is purely additive.
> 
> Alternatives Considered
> 
> Using distinct literal names without subsuming them into a namespaced 
> umbrella.
> ___
> 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] Addition of a standardError OutputStream

[Saagar Jha via swift-evolution]

What is the process for smaller issues like these? I’m guessing that this 
doesn’t need a proposal; where should it go? On bugs.swift.org 
<http://bugs.swift.org/>?

> On Jul 8, 2016, at 16:33, Erica Sadun  wrote:
> 
> Right now it's more like "foo".write(to: &stream) but I agree that having to 
> implement
> a custom stream is kind of irritating for stderr and stdout.
> 
> import Cocoa
> 
> var str = "Hello, playground"
> 
> struct StderrStream: OutputStream {
> static var shared = StderrStream()
> func write(_ string: String) { fputs(string, stderr) }
> }
> 
> str.write(to: &StderrStream.shared)
> 
> -- E
> 
> 
>> On Jul 8, 2016, at 4:41 PM, Saagar Jha via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Currently, it’s rather annoying to print to standard error, requiring either 
>> something low-level like fputs. I was wondering if a standardError 
>> OutputStream could be added to the standard library, so we could write 
>> something like print(“foo”, &standardError).
>> 
>> -- 
>> -Saagar Jha
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

[swift-evolution] Addition of a standardError OutputStream

[Saagar Jha via swift-evolution]

Currently, it’s rather annoying to print to standard error, requiring
either something low-level like fputs. I was wondering if a standardError
OutputStream could be added to the standard library, so we could write
something like print(“foo”, &standardError).
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing Variadic Parameters.

[Saagar Jha via swift-evolution]

On Wed, Jul 6, 2016 at 11:38 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> It's a late answer… but I wanted to be a good citizen and checked if the
> topic has been discussed before; so, it seems that is not the case ;-)
>
> In short, I agree:
> Variadic parameters are somewhat cool, and I think I was exited when I've
> seen them in C the first time… but I afair, I never created a variadic
> function in production code, and I think I just used them for the first
> time in Swift (I checked wether print is variadic…)
> As of today, string interpolation has several advantages over old-style
> string-formatting, and I can't remember any other method in one of the
> established libraries that uses this feature:
> Explicitly creating an array is just two additional characters, which
> doesn't matter in a long list (which imho shouldn't be crammed into the
> function call anyways), and when there are only a few parameters, you can
> mimic variadics with Optionals defaulted to nil — and who knows what the
> long-awaited hygienic macros might do to the importance of variadic
> parameters.
>
> Additionally, variadic parameters compete with trailing closures, which
> for me would always win the struggle for the last parameter ;-)
>

Actually, you don’t have to make a variadic parameter last…print doesn’t.


>
> As I said, I can't remember a single use case in Swift — and I already
> utilized quite a lot of the "strange" techniques (currying, tuple splat,
> complicated combinations of generics & protocols…).
> So for me, the answer to the question "would I add this feature to Swift
> if it wasn't there?" is a clear no…
>
> Tino
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

[Saagar Jha via swift-evolution]

Most source breaking changes will be made in Swift 3. From now on code
should be mostly backwards compatible.

On Wed, Jul 6, 2016 at 11:28 AM Ted F.A. van Gaalen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi there
>
> From the perspective from many active programmers
> that use Swift (not objective C anymore) I am  not
> very happy by having to change
> program source all the time:
>
> Therefore after Swift 3.0 is released I’d recommend kindly:
>
>
> Freeze Swift For Some Time!
> Do Not Change AnyThing For At Least 2 Years.
> (Yes you’ve read that correctly: two years.)
>
> Still there? OK, read on:
>
> In the mean time, you’ll have the great opportunity
> to fine-tune compiler and run time systems, to eliminate
> the few bugs there and make it blazingly fast!
>
> In two (or more) years,  there are enough Real Users (programmers)
> that by then will have enough practical experience with Swift, which
> might play a more solid role in improving Swift, and of course,
> are extremely happy with Swift, and that it is not changed
> all the time, So that they can concentrate on writing cool,
> reliable and decent programs, instead of revising it all
> the time!
>
> After such time, and much more intensive and practical usage,
> it becomes clear, what is good in Swift and what is not.
> What happens now, for instance, is that some base their “statistics” of
> which
> language elements etc. are frequently used or not, merely upon scanning
> a codebase of the relatively few (compared with e.g. ObjC, Java or C#)
> programmers
> that use Swift now
>
> Imho, Swift has not yet been in use long enough. It needs a prolonged time
> because now, most users have relatively little experience using Swift,
> thus the way they program now is not really representative with what one
> really can do
> with this powerful language, compared to experienced (years, not months)
> programmers in other languages.
> Still a lot has to be discovered, has to settle and form good mental
> pictures in
> programmer’s minds. It is all going a bit too fast, I think.
>
>
> Please (if you did’t already) realize that already many source
> code all over the world is written in Swift therefore it is very, very
> important that backwards compatibility should be preserved as much
> as possible. because  backwards-breaking-changes are a disaster
> to companies/individuals that have already hundreds or thousands
> of programs written in Swift.
>
> For comparison, until recently I did also programming projects on IBM
> mainframes for banks, insurance companies etc. The systems they use
> consists
> (per company) of literally thousands of Cobol and/or PL/1 programs written
> in all the years from ca 1970 until now. Still, one can take a program
> written
> in 1970 which compiles and runs flawlessly without any modification!
> All is backward compatible. If you would break backward
> compatibility in this domain you would probably be kicked of the planet..
>
>
> But even if we remain in macOS or iOS development, a huge amount of source
> code has been written in Objective C. Everyone would scream hell if you
> took
> out or change language elements..
> So please don’t. (it’s unnecessary)
>
>
> When Swift arrived, to me, it had already everything I need, not really
> missing anything.
> Of course, a programming language -like all things in life- is never
> perfect.
>
> To me it was also perfectly OK that Swift wasn’t open source, because
> those that
> have made Swift did a very good job. So one could even start thinking, why
> open source Swift? Why not leave it to Apple?
> But I guess I won’t make many friends asking this..
> And I also realize that many good ideas comes from open source.
>
>
> To me, Swift 2.2 and also 3.0  is fine.
> so, after that:
> you don’t have to change a thing.
> it works and has everything I need
> and is fast and stable.
> stop removing things.
> thanks.
>
>
> Kind Regards from beautiful Speyer.de in Germany
>
> TedvG
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Gave me a chuckle, but yeah, basically.

On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley <
w...@delicious-monster.com> wrote:

> On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> When I see an IUO property, I consider it a sort of “contract”–it’s
> basically saying something like “I can’t set this to a valid value right
> now, but by the time you use it I promise that it’s non nil”
>
>
> You might say that an IUO is sort of an IOU?
>
> -W
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Sorry, but I’m going to use your use case as an example…hope you don’t take
it personally :)

Basically, your use of IUOs is exactly what I’m trying to avoid. IUOs may
have their uses, but in my mind, they don’t (in my mind) indicate “This
argument should not be nil on most occasions, but may be under some
circumstances.” I think of it as “this can occasionally be nil, but if you
shouldn’t have to check for it since I guarantee it will have a value
whenever you try to use it”. If you can’t make this guarantee, then you
should be using a plain Optional instead to make it explicit that the value
you’re trying to use can be nil.

Interpretation of IUO aside, your approach has other issues, for both the
author and the user. As an author, putting an IUO in the function signature
makes it possible to passing in nil, but does not *require* a check to
compile. Basically, what I’m saying is that with an Optional the compiler
*forces* you to check for nil before you try to use a variable shadowing
with a guard (which I don’t really see as easier than explicitly checking
for nil; they’re basically the same number of characters, and this one
looks more Swifty™ to me anyways):

guard let url = url else {
return
}

whereas with IUOs you can easily forget the check and the compiler won’t
warn you. This way, it makes it both explicit as well as safe.

Your function also appears unsafe for users, as well. Let’s assume I was
using your code for my project as a framework, and I came across your
function. Everything’s perfect, it does what I want, until I come across a
URL! parameter. As a user, I cannot trust that you have implemented a check
for nil (maybe you forgot) and a runtime crash would be unacceptable
behavior. Thus, I’m obliged to add my own check for nil before passing in
my URL?, which completely negates the benefits of the IUO you have.


On Thu, Jun 30, 2016 at 9:15 PM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> I find it useful when dealing with (NS)URLs. I have a project that deals
> with URLs an awful lot and it would be incredible pain to deal to check if
> each URL is nonnil at call site.
>
> What I do instead is use IUO arguments in methods where I pass the URLs
> to. The IUO nicely indicates "This argument should not be nil on most
> occasions, but may be under some circumstances." The only thing I need to
> do at the top of the method is guard url != nil else  { return }.
>
> Sure, I could do this with optional + shadowing original argument var with
> guard let url = url else { return }, but I find it easier this way.
>
> > On Jun 30, 2016, at 5:55 PM, J.E. Schotsman via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > The only reason I can think of writing a function with a force-unwrapped
> parameter is overriding an API function with such a signature, as Chris
> mentioned.
> >
> > If the function actually doesn’t accept nil you might feel obliged to
> start the function with something like
> >
> > precondition( IUO argument != nil, “this method cannot handle nil”)
> >
> > in order to at least provide a message rather than just crashing.
> >
> > As for consistency and symmetry I don’t think the current practice meets
> these criteria.
> > In your own code an IUO means “only use if you are sure it’s non-nil”
> whereas in imported APIs it means “enter nil at your own risk”.
> > If the unwrap shorthand `if let x!` would be accepted it would mean “if
> unwrap succeeds use as if it’s an IUO instead of an ordinary optional”.
> > That would make three shades of weirdness. I like it.
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

[Saagar Jha via swift-evolution]

+1 since it makes it easy to get the number of possible enum values, but I
thought I'd tell you: there's no "Wind" type in Pokémon. It's "Flying".
On Sun, Jul 3, 2016 at 18:36 Gabriel Lanata via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello, this has been proposed multiple times before in different ways.
>
> Link to detailed proposal draft:
>
> https://github.com/gabriellanata/swift-evolution/blob/master/proposals/-allow-enumerating-cases-in-enumerations.md
>
> It is currently not possible to enumerate through all the possible cases
> of an enumeration object without adding a hardcoded value or recurring to
> unsafe workarounds. The proposal is to add a method of obtaining an array
> or set of all the possible cases natively for enumerations without
> associated values.
>
> The proposed solution is to implement a native `.cases` static var for
> all enumerations without associated values. This would provide a strict
> type-safe way of enumerating though the possible cases without risking
> runtime errors. The resulting code is a lot cleaner and less prone to
> errors caused by forgetting to update the hardcoded values when modifying
> cases.
>
> Resulting code:
>
>enum PokemonType {
>case Fire, Grass, Water, Wind
>}
>for pokemonType in PokemonType.cases {
>// Do stuff
>}
>PokemonType.cases.count // Returns 4
>
>
> ---
> Gabriel
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Now that I think of it, IUOs for function returns have a similar problem.
When I see an IUO property, I consider it a sort of “contract”–it’s
basically saying something like “I can’t set this to a valid value right
now, but by the time you use it I promise that it’s non nil”. That’s why
IUOs make sense as properties and @IBOutlets, since they’re nil during
initialization, but when you need them they have a value (assuming you’ve
hooked up your outlets properly). The problem with using IUOs in functions
as parameters or return types is that this sort of promise doesn’t hold up;
the function could act on the value immediately and saying something like
“it might be nil right now, but I’ll change it” doesn’t work since you have
no control of what the function does with it. Similarly with a return
value, there is no way to guarantee the setting of an IUO before it’s used.
If there’s any doubt that the value is possibly nil, a regular Optional
should be used.

A lot of the time this just turns out for an excuse for programmers to
shoehorn an Optional without a check; save for imported APIs I haven’t seen
someone use an IUO as a function parameter if they’re not trying to get
around compiler complaints.


On Wed, Jun 29, 2016 at 5:45 PM Chris Lattner  wrote:

> On Jun 28, 2016, at 10:04 PM, Saagar Jha  wrote:
>
> Yep, that’s what I meant. I should probably go back and re-write the
> proposal if it’s not clear.
>
> BTW, when does the window for proposals close? Is this in the scope for
> Swift 3?
>
>
> Ok, I missed that.
>
> I still dont’ understand why it is a good thing though.  IUO arguments
> exist not just for calls, but for declarations.  It is pretty common to
> implement an override of a method that has IUO’s.  Likewise, disallowing
> them for parameters, but allowing them for properties and return values
> just seems inconsistent and asymmetrical.
>
> IUO is an important part of the Swift model.  I think that the changes
> we’ve already made go a long way to making it behave predictably and limit
> their scope.  Syntactically limiting where they can occur just makes Swift
> irregular, for no apparent (to me) gain.
>
> -Chris
>
>
>
>
> On Tue, Jun 28, 2016 at 9:54 PM David Waite 
> wrote:
>
>> Hi Saagar,
>>
>> If I understand your proposal correctly, you are suggesting that we
>> remove T! and just force people to use T? or T.  This is a commonly
>> rejected proposal (though not on the list yet) that frequently comes up.
>> The problem with your proposal is that you don’t provide any solutions to
>> the problems that T! is currently solving: that of two-phase initialization
>> and importing of APIs that have not been nullability audited.  It isn’t
>> pragmatic to handle these cases as T?
>>
>> -Chris
>>
>>
>> Chris,
>>
>> I believe he only is speaking to removing the ability to use IUOs as
>> function parameters, not as properties (for 2-phase init) or return values
>> (for unaudited API). The question would be what the impact would be of
>> unaudited API being imported as accepting an explicit optional rather than
>> IUO.
>>
>> -DW
>>
>>
>> Remove implicitly unwrapped optionals as function parameters
>>
>>- Proposal: SE-
>>- Author: Swift Developer 
>>- Status: *Awaiting review*
>>- Review manager: TBD
>>
>> Introduction
>>
>> Swift, in contrast with Objective-C, makes a distinction between values
>> that may be nil and values that can never be nil through its use of
>> Optionals. Due to the fact that Objective-C does not make this distinction,
>> Objective-C functions that do not use the Nullability
>>  annotations are imported
>> with parameters of the implicitly unwrapped optional type. Unfortunately,
>> this allows users to write their own Swift code that looks like this:
>>
>> func foo(bar: Int!) {
>> //…
>> }
>>
>> Due to the confusion this may cause, we would like to propose the *removal
>> of implicitly unwrapped optionals as function parameters*. Discussion on
>> this topic may be found here
>> .
>> Motivation
>>
>> Implicitly unwrapped optionals are currently allowed in function
>> declarations. Consider the following function:
>>
>> func triple(forceUnwrapping aNumber: Int) -> Int {
>> return aNumber * 3
>> }
>>
>> let possiblyNil = Int("foo")
>> triple(forceUnwrapping: possiblyNil)
>>
>> possiblyNil is an Int?; thus, this example will not compile due to
>> triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift
>> beginner writing code that looks like this to "fix" the problem:
>>
>> func triple(forceUnwrapping aNumber: Int!) -> Int {
>> return aNumber * 3
>> }
>>
>> let possiblyNil = Int("foo")
>> triple(forceUnwrapping: possiblyNil)
>>
>> While this version compiles, it crashes due to the force unwrapping of a
>> nil value. Unfortunately, the compiler "hides" this fact by making it
>> seem like it's accep

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Yep, that’s what I meant. I should probably go back and re-write the
proposal if it’s not clear.

BTW, when does the window for proposals close? Is this in the scope for
Swift 3?


On Tue, Jun 28, 2016 at 9:54 PM David Waite 
wrote:

> Hi Saagar,
>
> If I understand your proposal correctly, you are suggesting that we remove
> T! and just force people to use T? or T.  This is a commonly rejected
> proposal (though not on the list yet) that frequently comes up.  The
> problem with your proposal is that you don’t provide any solutions to the
> problems that T! is currently solving: that of two-phase initialization and
> importing of APIs that have not been nullability audited.  It isn’t
> pragmatic to handle these cases as T?
>
> -Chris
>
>
> Chris,
>
> I believe he only is speaking to removing the ability to use IUOs as
> function parameters, not as properties (for 2-phase init) or return values
> (for unaudited API). The question would be what the impact would be of
> unaudited API being imported as accepting an explicit optional rather than
> IUO.
>
> -DW
>
>
> Remove implicitly unwrapped optionals as function parameters
>
>- Proposal: SE-
>- Author: Swift Developer 
>- Status: *Awaiting review*
>- Review manager: TBD
>
> Introduction
>
> Swift, in contrast with Objective-C, makes a distinction between values
> that may be nil and values that can never be nil through its use of
> Optionals. Due to the fact that Objective-C does not make this distinction,
> Objective-C functions that do not use the Nullability
>  annotations are imported
> with parameters of the implicitly unwrapped optional type. Unfortunately,
> this allows users to write their own Swift code that looks like this:
>
> func foo(bar: Int!) {
> //…
> }
>
> Due to the confusion this may cause, we would like to propose the *removal
> of implicitly unwrapped optionals as function parameters*. Discussion on
> this topic may be found here
> .
> Motivation
>
> Implicitly unwrapped optionals are currently allowed in function
> declarations. Consider the following function:
>
> func triple(forceUnwrapping aNumber: Int) -> Int {
> return aNumber * 3
> }
>
> let possiblyNil = Int("foo")
> triple(forceUnwrapping: possiblyNil)
>
> possiblyNil is an Int?; thus, this example will not compile due to
> triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift
> beginner writing code that looks like this to "fix" the problem:
>
> func triple(forceUnwrapping aNumber: Int!) -> Int {
> return aNumber * 3
> }
>
> let possiblyNil = Int("foo")
> triple(forceUnwrapping: possiblyNil)
>
> While this version compiles, it crashes due to the force unwrapping of a
> nil value. Unfortunately, the compiler "hides" this fact by making it
> seem like it's acceptable to pass in nil–it doesn't make the forced
> unwrapping *explicit*.
> Proposed solution
>
> The safest solution, in this case, is to prevent the use of implicitly
> unrwapped optionals in function signatures. By forcing users to write
>
> func triple(forceUnwrapping aNumber: Int) -> Int {
> return aNumber * 3
> }
>
> or
>
> func triple(forceUnwrapping aNumber: Int?) -> Int {
> return aNumber * 3
> }
>
> the compiler will complain, reminding users that they should probably
> attempt to safely unwrap the optional before using it.
> Detailed design
>
> The proposal will prevent the use of implicitly unwrapped optionals in
> function signatures for both Swift code as well as imported Objective-C
> code. As non-annotated Objective-C functions are currently imported as
> implicitly unwrapped, they will be converted to optionals as a preliminary
> step. Non-audited frameworks can be audited in the future so that they can
> be tagged with _Nonnull if necessary.
> Impact on existing code
>
> This is a proposal is a source breaking change, but it should be easily
> mitigated using a migrator. Existing functions with implicitly unwrapped
> optionals can be changed to optional; users can easily shadow variables
> with a guard or change their function to non-optional.
> Alternatives consideredImporting Objective-C functions as-is, but
> disallowing implictly unwrapped optionals in Swift code
>
> This reduces the burden on existing frameworks and adding Nullability
> annotations, but creates a sort of disconnect between Objective-C and Swift
> in that it prevents Swift developers from writing functions with implicitly
> unwrapped optionals.
> Doing nothing
>
> Obviously, this has the benefit of keeping the current behavior and not
> requiring a migrator. However, I believe that the unsafe behavior that this
> encourages is not worth keeping.
>
>
> On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko 
> wrote:
>
>> +1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a
>> carryover from Java. They show up in method signatures 

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Alright, I’ve written it up a proposal; you can find it here
. This
is my first proposal (and anyways I’ve been told that I can be unclear), so
if you guys see anything that should be changed feel free to let me know.
Here it is inline:
Remove implicitly unwrapped optionals as function parameters

   - Proposal: SE-
   
   - Author: Swift Developer 
   - Status: *Awaiting review*
   - Review manager: TBD

Introduction

Swift, in contrast with Objective-C, makes a distinction between values
that may be nil and values that can never be nil through its use of
Optionals. Due to the fact that Objective-C does not make this distinction,
Objective-C functions that do not use the Nullability
 annotations are imported
with parameters of the implicitly unwrapped optional type. Unfortunately,
this allows users to write their own Swift code that looks like this:

func foo(bar: Int!) {
//…
}

Due to the confusion this may cause, we would like to propose the *removal
of implicitly unwrapped optionals as function parameters*. Discussion on
this topic may be found here
.
Motivation

Implicitly unwrapped optionals are currently allowed in function
declarations. Consider the following function:

func triple(forceUnwrapping aNumber: Int) -> Int {
return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)

possiblyNil is an Int?; thus, this example will not compile due to
triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift
beginner writing code that looks like this to "fix" the problem:

func triple(forceUnwrapping aNumber: Int!) -> Int {
return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)

While this version compiles, it crashes due to the force unwrapping of a nil
value. Unfortunately, the compiler "hides" this fact by making it seem like
it's acceptable to pass in nil–it doesn't make the forced unwrapping
*explicit*.
Proposed solution

The safest solution, in this case, is to prevent the use of implicitly
unrwapped optionals in function signatures. By forcing users to write

func triple(forceUnwrapping aNumber: Int) -> Int {
return aNumber * 3
}

or

func triple(forceUnwrapping aNumber: Int?) -> Int {
return aNumber * 3
}

the compiler will complain, reminding users that they should probably
attempt to safely unwrap the optional before using it.
Detailed design

The proposal will prevent the use of implicitly unwrapped optionals in
function signatures for both Swift code as well as imported Objective-C
code. As non-annotated Objective-C functions are currently imported as
implicitly unwrapped, they will be converted to optionals as a preliminary
step. Non-audited frameworks can be audited in the future so that they can
be tagged with _Nonnull if necessary.
Impact on existing code

This is a proposal is a source breaking change, but it should be easily
mitigated using a migrator. Existing functions with implicitly unwrapped
optionals can be changed to optional; users can easily shadow variables
with a guard or change their function to non-optional.
Alternatives considered Importing Objective-C functions as-is, but
disallowing implictly unwrapped optionals in Swift code

This reduces the burden on existing frameworks and adding Nullability
annotations, but creates a sort of disconnect between Objective-C and Swift
in that it prevents Swift developers from writing functions with implicitly
unwrapped optionals.
Doing nothing

Obviously, this has the benefit of keeping the current behavior and not
requiring a migrator. However, I believe that the unsafe behavior that this
encourages is not worth keeping.


On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko 
wrote:

> +1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a
> carryover from Java. They show up in method signatures from
> non-nullable-annotated Java, but you can't define a new method that takes
> e.g. an Int!.
>
> The limited scope of this proposal is ideal in my opinion since we see
> areas where IUOs are clearly useful (ViewControllers for instance) but
> defining new functions that take implicitly unwrapped optionals makes no
> sense. If you need to pass a IUO at the call site, you can define the
> function taking a non-optional value and pass the IUO to that. There is no
> use case I can think of for having it in method/function signatures.
>
> RE: language inconsistencies, there is no such issue in practice in Kotlin
> where there is also inconsistency in the same vein. I see it simply as a
> compromise that achieves the goal of keeping a useful feature but
> discouraging its overuse by forbidding its use in places where its use
> could confuse and snowball down the line into teaching developers worse
> code quality.
>
> On Mon, Jun 27,

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Saagar Jha via swift-evolution]

Seems fine to me. One addition though: some sort of round(withPrecision:
Int)
On Mon, Jun 27, 2016 at 12:23 Stephen Canon via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 27, 2016, at 12:34 PM, Karl  wrote:
>
>
> On 27 Jun 2016, at 16:23, Stephen Canon  wrote:
>
>
> On Jun 25, 2016, at 05:06, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31
>
>
> Karl, thanks for writing this up.  It should be extended to include not
> only floor( ) and ceiling( ), but also:
>
> /// Returns the integral value closest to `self` whose magnitude is not
> greater than that of `self`.
> func truncate( ) -> Self
>
> /// Returns the integral value closest to `self`.  If two integrers are
> equally close, the even one
> /// is returned.
> //  NOTE: The name of this function requires bike-shedding.  I’ve chosen a
> deliberately poor
> //  name as a straw-man.
> func roundToNearestTiesToEven( ) -> Self
>
> /// Returns the integral value closest to `self`.  If two integrers are
> equally close, the one with
> /// greater magnitude is returned.
> //  NOTE: The name of this function requires bike-shedding.  I’ve chosen a
> deliberately poor
> //  name as a straw-man.
> func roundToNearestTiesAway( ) -> Self
>
> and mutating versions of those.
>
>
> I was trying to add these, but working out the names of the mutating
> functions is difficult. How is truncate different to floor if it returns an
> integral value and can never round up?
>
>
> Perhaps for the other functions, we could have a general `round` function
> with a tiebreak-enum parameter (it would be great if we could embed enums
> in protocols, but I’m not sure if that’s even on the roadmap):
>
> enum FloatingPointRoundingStrategy {   // or something to that effect
> case preferEven
> case preferGreatest
> }
>
> func rounded(inTiebreak: FloatingPointRoundingStrategy) -> Self
>
> I think `(4.5).rounded(inTiebreak: .preferGreatest) == 5.0` looks quite
> nice.
>
>
> Yes, something along these lines might work, though
> `FloatingPointRoundingStrategy` isn’t quite right; after all,
> round-towards-infinity (aka ceiling) is also a rounding strategy.
>
> One option (which I don’t totally love, but which simplifies the API
> surface quite a bit, and avoids adding more form constructions) would
> be to fold all the rounding rules into a single member function (very
> strawman):
>
> /// Describes a rule for rounding to an integral value.
> enum RoundingRule {
> /// The result is the closest representable value greater than or equal to
> the source.
> case upwards
> /// The result is the closest representable value less than or equal to
> the source.
> case downwards
> /// The result is the closest representable value whose magnitude is less
> than or equal to that of the source.
> case towardZero
> /// The result is the closest representable value; if two values are
> equally close, the even one is chosen.
> case toNearestTiesToEven
> /// The result is the closest representable value; if two values are
> equally close, the one with greater magnitude is chosen.
> case toNearestTiesAway
> }
>
> /// Rounds to an integral value according to the specified rounding rule.
> mutating func round(_ rule: RoundingRule = toNearestTiesAway)
>
> func rounded(_ rule: RoundingRule = toNearestTiesAway) -> Self
>
> That gives us e.g.:
>
> let x = -2.5
> x.round(.upwards) // -2
> x.round(.downwards) // -3
> x.round(.towardZero) // -2
> x.round(.toNearestTiesToEven) // -2
> x.round() // -3
>
> We might also provide free functions that implement the most common
> operations under the familiar libc names (I realize that free-functions are
> not broadly considered “swifty”, but they may be appropriate here; we would
> effectively simply be moving these free functions from Darwin/Glibc into
> the stdlib, and making them available for all FloatingPoint types).
>
> func ceil(_ x: T) -> T {
> return x.rounded(.upwards)
> }
>
> func floor(_ x: T) -> T {
> return x.rounded(.downwards)
> }
>
> func trunc(_ x: T) -> T {
> return x.rounded(.towardZero)
> }
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Saagar Jha via swift-evolution]

On Mon, Jun 27, 2016 at 9:34 AM Karl via swift-evolution <
swift-evolution@swift.org> wrote:

> On 27 Jun 2016, at 16:23, Stephen Canon  wrote:
>
>
> On Jun 25, 2016, at 05:06, Karl via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31
>
>
> Karl, thanks for writing this up.  It should be extended to include not
> only floor( ) and ceiling( ), but also:
>
> /// Returns the integral value closest to `self` whose magnitude is not
> greater than that of `self`.
> func truncate( ) -> Self
>
> /// Returns the integral value closest to `self`.  If two integrers are
> equally close, the even one
> /// is returned.
> //  NOTE: The name of this function requires bike-shedding.  I’ve chosen a
> deliberately poor
> //  name as a straw-man.
> func roundToNearestTiesToEven( ) -> Self
>
> /// Returns the integral value closest to `self`.  If two integrers are
> equally close, the one with
> /// greater magnitude is returned.
> //  NOTE: The name of this function requires bike-shedding.  I’ve chosen a
> deliberately poor
> //  name as a straw-man.
> func roundToNearestTiesAway( ) -> Self
>
> and mutating versions of those.
>
>
> I was trying to add these, but working out the names of the mutating
> functions is difficult. How is truncate different to floor if it returns an
> integral value and can never round up?
>
>
(-4.5).truncate == -4
(-4.5).roundedDown == -5


> Perhaps for the other functions, we could have a general `round` function
> with a tiebreak-enum parameter (it would be great if we could embed enums
> in protocols, but I’m not sure if that’s even on the roadmap):
>
> enum FloatingPointRoundingStrategy {   // or something to that effect
> case preferEven
> case preferGreatest
> }
>
> func rounded(inTiebreak: FloatingPointRoundingStrategy) -> Self
>
> I think `(4.5).rounded(inTiebreak: .preferGreatest) == 5.0` looks quite
> nice.
>
> Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Question] Grand Renaming and Delegate/Datasource protocols !

[Saagar Jha via swift-evolution]

I believe that renaming of Apple’s frameworks is not in the scope of
swift-evolution; I think you’re supposed to file a radar.

On Mon, Jun 27, 2016 at 9:54 AM Jerome ALVES via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi everyone,
>
> I can't find anything about Cocoa Delegate/Datasource protocol "Grand
> Renaming" for Swift 3
> Is something planned about this ?
>
> Because I find that actual names don't fit with Swift 3 API guidelines.
>
> For instance :
>
> func numberOfSectionsInTableView(_ *tableView*: UITableView) -> Int
> func tableView(_ *tableView*: UITableView, numberOfRowsInSection *section*
> : Int) -> Int
> func tableView(_ *tableView*: UITableView, cellForRowAtIndexPath
> *indexPath*: NSIndexPath) -> UITableViewCell
> func tableView(_ *tableView*: UITableView, moveRowAtIndexPath
> *sourceIndexPath*: NSIndexPath, toIndexPath *destinationIndexPath*:
> NSIndexPath)
>
> func tableView(_ *tableView*: UITableView, heightForRowAtIndexPath
> *indexPath*: NSIndexPath) -> CGFloat
> func tableView(_ *tableView*: UITableView, didSelectRowAtIndexPath
> *indexPath*: NSIndexPath)
> ...
>
> could be renamed to *something* like this :
>
> func numberOfSections(in *tableView*: UITableView) -> Int
> func numberOfRows(inSection *section*: Int, in *tableView*: UITableView)
> -> Int
> func cellForRow(at *indexPath*: NSIndexPath, in *tableView*: UITableView)
> -> UITableViewCell
> func moveRow(at *sourceIndexPath*: NSIndexPath, to *destinationIndexPath*
> : NSIndexPath, in *tableView*: UITableView)
>
> func heightForRow(at *indexPath*: NSIndexPath, in *tableView*: UITableView)
> -> CGFloat
> func didSelectRow(at *indexPath*: NSIndexPath, in *tableView*: UITableView
> )
> ...
>
>
>
> Kind regards,
>
> Jérôme Alves
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

I think you’re mistaking the scope of the proposal. It’s simply removing
IUOs in *function signatures*, not throughout the language.

On Mon, Jun 27, 2016 at 11:31 AM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> There are many useful cases for IUO in Swift - mostly when you have
> variables that cannot be calculated at the point of calling super.init(),
> but are guaranteed to be filled during initialization - i.e. during the
> lifetime of the object, the value is nonnil, but may be nil for a short
> period of time.
>
> Or @IBOutlets. Making all @IBOutlets optionals would make the code either
> riddled with ! or shadowed locally re-declared instance members.
>
>
> > On Jun 27, 2016, at 8:12 PM, Jean-Daniel Dupas 
> wrote:
> >
> > Maybe we can prohibit it in Swift function declaration, and allow it
> only when importing native code.
> >
> > As David, I don’t see any compelling reason to allow such construct in
> Swift.
> >
> >> Le 27 juin 2016 à 10:39, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >>
> >> When you import ObjC code that has no nullability annotation, IUO make
> sense since:
> >>
> >> - they can be checked against nil
> >> - typically, most values in APIs are nonnull (looking at Foundation,
> for example, which is why Apple has the NS_ASSUME_NONNULL_BEGIN to mark
> entire regions as nonnull, yet there is no NS_ASSUME_NULL_BEGIN)
> >>
> >> Importing them as optionals would make it really hard to work with the
> code - whenever you get a value, it's an optional, even in cases where it
> makes no sense and adding ! to unwrap the optional is not a great solution.
> And the other solution is to use guards everywhere.
> >>
> >> IMHO the IUO is a nice (temporary) solution for using un-annotated code
> until it is. But the "pressure" should be applied on the ObjC code.
> >>
> >>> On Jun 27, 2016, at 10:03 AM, David Rönnqvist <
> david.ronnqv...@gmail.com> wrote:
> >>>
> >>> I don’t know about the chances of getting approved, but I think this
> is something worth discussing.
> >>>
> >>> It might just be my ignorance, but I can’t think of a good reason why
> a function argument would be force unwrapped. Either it’s non-null and the
> caller is expected to unwrap it or it’s nullable and the method is expected
> to handle the nil value. So I’m positive to that part of the proposal.
> >>>
> >>> As to what we should do with the generated interfaces of Objective-C
> code that hasn’t been annotated with nullability, I think that needs input
> from more people to find the preferred solution.
> >>>
> >>> Once that’s been discussed some more, I’d be willing to write up a
> formal proposal if you don’t feel like it (assuming the discussion leads
> somewhere).
> >>>
> >>> - David
> >>>
> >>>
>  On 27 Jun 2016, at 06:28, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  See https://github.com/apple/swift-evolution/blob/master/process.md
> - you would need to make an official proposal and submit it as pull
> request. But given the reaction here, it's unlikely to get approved.
> 
>  Also, the ObjC code without nullability is getting fairly rare - all
> Apple's frameworks are with nullability information (as far as I've
> checked) in macOS 10.12, iOS 10. Third party libraries should be updated to
> use nullability (and most libraries that are maintained already do).
> 
> 
> > On Jun 25, 2016, at 5:13 PM, Spromicky via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > So, its proposal is dead, or what we must to do to force it to
> swift-evolution repo on GitHub?
> >
> >> Hello, everyone!
> >>
> >> I wanna propose to you to remove force unwrapping in fuction
> signature for swift code. That no sense in clear swift code. If we wanna
> use some optional value as function param, that is not optional, we must
> unwrap it before function call.
> >> People who new in swift look at how they old Obj-C code (without
> nullability modifiers) translate in to swift:
> >>
> >> Obj-C:
> >> - (void)foo:(NSInteger)bar {
> >> //...
> >> }
> >>
> >> Swift transaliton:
> >> func foo(bar: Int!) {
> >> //...
> >> }
> >>
> >> And think that force unwrapping in signature is good practice. And
> start write functions in clear swift code like this:
> >>
> >> func newFoo(bar: Int!) {
> >> //...
> >> }
> >>
> >> and use it like this:
> >>
> >> let bar: Int? = 1
> >> newFoo(bar)
> >>
> >> And it really work, and they does not think that this can crash in
> case if `bar` will be `nil`.
> >> But in clear swift we wanna work with parametrs in function that
> clearly or optional, or not.
> >>
> >> func newFoo(bar: Int) {
> >> //...
> >> }
> >>
> >> or
> >>
> >> func newFoo(bar: Int?) {
> >> //...
> >> }
> >>
> >> When we write a new function we know

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

I don’t even see the purpose of allowing it in Objective-C code that
doesn’t have an annotation. If you can check it against nil, just shadow an
optional with a guard…it’s basically the same code and it’s a lot more
clear on what’s happening.

On Mon, Jun 27, 2016 at 11:12 AM Jean-Daniel Dupas via swift-evolution <
swift-evolution@swift.org> wrote:

> Maybe we can prohibit it in Swift function declaration, and allow it only
> when importing native code.
>
> As David, I don’t see any compelling reason to allow such construct in
> Swift.
>
> > Le 27 juin 2016 à 10:39, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >
> > When you import ObjC code that has no nullability annotation, IUO make
> sense since:
> >
> > - they can be checked against nil
> > - typically, most values in APIs are nonnull (looking at Foundation, for
> example, which is why Apple has the NS_ASSUME_NONNULL_BEGIN to mark entire
> regions as nonnull, yet there is no NS_ASSUME_NULL_BEGIN)
> >
> > Importing them as optionals would make it really hard to work with the
> code - whenever you get a value, it's an optional, even in cases where it
> makes no sense and adding ! to unwrap the optional is not a great solution.
> And the other solution is to use guards everywhere.
> >
> > IMHO the IUO is a nice (temporary) solution for using un-annotated code
> until it is. But the "pressure" should be applied on the ObjC code.
> >
> >> On Jun 27, 2016, at 10:03 AM, David Rönnqvist <
> david.ronnqv...@gmail.com> wrote:
> >>
> >> I don’t know about the chances of getting approved, but I think this is
> something worth discussing.
> >>
> >> It might just be my ignorance, but I can’t think of a good reason why a
> function argument would be force unwrapped. Either it’s non-null and the
> caller is expected to unwrap it or it’s nullable and the method is expected
> to handle the nil value. So I’m positive to that part of the proposal.
> >>
> >> As to what we should do with the generated interfaces of Objective-C
> code that hasn’t been annotated with nullability, I think that needs input
> from more people to find the preferred solution.
> >>
> >> Once that’s been discussed some more, I’d be willing to write up a
> formal proposal if you don’t feel like it (assuming the discussion leads
> somewhere).
> >>
> >> - David
> >>
> >>
> >>> On 27 Jun 2016, at 06:28, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> See https://github.com/apple/swift-evolution/blob/master/process.md -
> you would need to make an official proposal and submit it as pull request.
> But given the reaction here, it's unlikely to get approved.
> >>>
> >>> Also, the ObjC code without nullability is getting fairly rare - all
> Apple's frameworks are with nullability information (as far as I've
> checked) in macOS 10.12, iOS 10. Third party libraries should be updated to
> use nullability (and most libraries that are maintained already do).
> >>>
> >>>
>  On Jun 25, 2016, at 5:13 PM, Spromicky via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  So, its proposal is dead, or what we must to do to force it to
> swift-evolution repo on GitHub?
> 
> > Hello, everyone!
> >
> > I wanna propose to you to remove force unwrapping in fuction
> signature for swift code. That no sense in clear swift code. If we wanna
> use some optional value as function param, that is not optional, we must
> unwrap it before function call.
> > People who new in swift look at how they old Obj-C code (without
> nullability modifiers) translate in to swift:
> >
> > Obj-C:
> > - (void)foo:(NSInteger)bar {
> > //...
> > }
> >
> > Swift transaliton:
> > func foo(bar: Int!) {
> > //...
> > }
> >
> > And think that force unwrapping in signature is good practice. And
> start write functions in clear swift code like this:
> >
> > func newFoo(bar: Int!) {
> > //...
> > }
> >
> > and use it like this:
> >
> > let bar: Int? = 1
> > newFoo(bar)
> >
> > And it really work, and they does not think that this can crash in
> case if `bar` will be `nil`.
> > But in clear swift we wanna work with parametrs in function that
> clearly or optional, or not.
> >
> > func newFoo(bar: Int) {
> > //...
> > }
> >
> > or
> >
> > func newFoo(bar: Int?) {
> > //...
> > }
> >
> > When we write a new function we know what we need in this case and
> use optional params or not.
> >
> > So my proposal is remove force unwrapping(`!`) from function
> signatures, cause it have no sense, and that confuse new users.
> >
> >
> >
>  ___
>  swift-evolution mailing list
>  swift-evolution@swift.org
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>> ___
> >>> swift-evolutio

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Saagar Jha via swift-evolution]

It’s leaving a lot of Linux users out to dry; a better option may be a sort
of hybrid approach with a “middleman” tool that does the translation, which
people could simply add as a build step if they needed translation.

On Sun, Jun 26, 2016 at 11:08 PM Charlie Monroe 
wrote:

> Sure, but if you want to have translated identifiers, there's really no
> other (better) option unless you want to create ABI incompatible code
> (given that Swift 4 has a finalized ABI) that only runs on your localized
> system.
>
> On Jun 27, 2016, at 7:59 AM, Saagar Jha  wrote:
>
> The problem with depending on the IDE is that not everyone is using
> Xcode…or even a modern IDE. There are those that are using basic text
> editors, which must be considered as well.
>
> On Sun, Jun 26, 2016 at 9:25 PM Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jun 25, 2016, at 7:12 AM, David Sweeris  wrote:
>> >
>> >
>> >> On Jun 24, 2016, at 23:13, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >> BTW how far along with programming do you think you'd get without the
>> knowledge of English? All libraries, SDKs use English identifiers. The
>> documentation is in English. For one to lear programming without actually
>> knowing any English would require the language to have localizable
>> identifiers. Can you imagine those? Given how much time is put here to
>> standardize the naming of a few methods in the standard library, how would
>> it look in other languages?
>> >
>> > Speaking of which, hypothetically, if we wanted to support translations
>> of Swift itself (and the standard library), would it be better to have the
>> compiler figure out how to make object files work across languages, or
>> would it be better for the on-disk file to always be in the "canonical"
>> language and have the IDE do the translation?
>>
>> Historically, these languages were 100% translated and required localized
>> compiler support (we're talking about BASIC, Pascal) since back then IDE
>> support was quite poor. Nowadays, on-the-fly translation by the IDE would
>> probably work out the best.
>>
>> > I'm *not* proposing we do this... Just thinking about what would need
>> to be done and how hard it would be.
>> >
>> > - Dave Sweeris
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> -Saagar Jha
>
>
> --
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Saagar Jha via swift-evolution]

The problem with depending on the IDE is that not everyone is using
Xcode…or even a modern IDE. There are those that are using basic text
editors, which must be considered as well.

On Sun, Jun 26, 2016 at 9:25 PM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 25, 2016, at 7:12 AM, David Sweeris  wrote:
> >
> >
> >> On Jun 24, 2016, at 23:13, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> BTW how far along with programming do you think you'd get without the
> knowledge of English? All libraries, SDKs use English identifiers. The
> documentation is in English. For one to lear programming without actually
> knowing any English would require the language to have localizable
> identifiers. Can you imagine those? Given how much time is put here to
> standardize the naming of a few methods in the standard library, how would
> it look in other languages?
> >
> > Speaking of which, hypothetically, if we wanted to support translations
> of Swift itself (and the standard library), would it be better to have the
> compiler figure out how to make object files work across languages, or
> would it be better for the on-disk file to always be in the "canonical"
> language and have the IDE do the translation?
>
> Historically, these languages were 100% translated and required localized
> compiler support (we're talking about BASIC, Pascal) since back then IDE
> support was quite poor. Nowadays, on-the-fly translation by the IDE would
> probably work out the best.
>
> > I'm *not* proposing we do this... Just thinking about what would need to
> be done and how hard it would be.
> >
> > - Dave Sweeris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

[Saagar Jha via swift-evolution]

+1. I had this same problem when using map with enumerated-both $1 and
$0.offset worked. I can see how this can be confusing to beginners.


On Sat, Jun 25, 2016 at 8:36 AM Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> I believe this should be done for Swift 3.0 release as this is a *source
> breaking change* and IMO it is very important to remove the inconsistency
> mentioned below.
>
> We removed tuple splatting on caller side and IMO we must complete this job
> to delete the implicit connection between tuple and list of parameters in
> closures/functions.
>
>
> Currently we have these "features" :
> 
>
> 1. Single tuple as parameter is allowed when list of parameters are
> required:
>
> let ft1 : (Int,Int) -> Void = { x in print(x.0, x.1)}
>
> (but this causes crash:
> let ft2 : (Int,Int) -> Void = { x in print(x) }
> )
>
> Opinion: this should not be allowed. Parameter list is required.
> `(Int,Int) -> Void` and `((Int,Int)) -> Void` are two different types.
>
>
> 2. Parameter list in closure is allowed when single tuple parameter is
> required:
>
> typealias IntInt = (Int,Int)
> typealias IntIntToVoid = (IntInt) -> Void
>
> let tuple : IntInt = (1,2)
>
> func foo(block: IntIntToVoid) { block(tuple) }
>
> foo { x, y in print(x,y)}
> foo { (x, y) in print(x, y)}
>
> Opinion: this should not be allowed. Tuple parameter is required.
> `((Int,Int)) -> Void` and `(Int,Int) -> Void` are two different types.
> Swift should require this syntax to assign tuple parameter's sub-values to
> variables in closure: `{ ((x, y)) in ..}`
>
>
> 3. Inconsistent (and just wrong) function type when a list of parameters
> required(not tuple) :
>
> typealias t1 = (Int, Int) -> Int // clearly here are list of parameters
> typealias t2 = ((Int, Int)) -> Int // clearly here is a tuple parameter
>
> print(t1.self) // Prints ((Int, Int)) -> Int  why?
> print(t2.self) // Prints ((Int, Int)) -> Int
> print(t1.self == t2.self) // true
>
> Opinion: `(Int,Int) -> Void` and `((Int,Int)) -> Void` should be two
> different separate types that can not be implicitly converted to each
> other. Swift's typesystem should separate these types.
>
>
> 4. If the type is the same, why behavior differs :
>
> let add_list:  (Int, Int) -> Int = (+)
> let add_tuple: ((Int, Int)) -> Int = (+)
>
> print(add_list.dynamicType == add_tuple.dynamicType) // true
>
> print( add_list(1,2) )
> //print( add_list((1,2)) ) // missing argument for parameter #2 in call
>
> //print( add_tuple(1,2) ) // extra argument in call
> print( add_tuple((1,2)) )
>
>
> Proposal:
> ===
>
> 1. Separate function types with parameter list and a tuple parameter. They
> should be two separate types.
>
> 2. Require this syntax to assign tuple parameter's sub-values to variables
> in func/closure: `{ ((x, y)) in ..}`, otherwise (i.e. if `{ (x, y) in ..`)
> treat function/closure as having list of parameters.
>
> 3. Disallow implicit conversion between function/closure with a list of
> parameters and function/closure where single tuple is required.
> This will stop confusion and make the language consistent how it deal with
> tuples and list of parameters in func/closure.
>
> 4. It seems like we should keep the ability to explicitly convert one to
> another as some(many?) code can depend on this current behavior and so we
> need a way to convert old code to new.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

[Saagar Jha via swift-evolution]

Any? or AnyObject?; have your dictionary be something like [String:
AnyObject?].

On Sun, Jun 26, 2016 at 3:00 PM Michael Peternell via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Am 26.06.2016 um 23:03 schrieb Jean-Daniel Dupas via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Optional are definitely the best way to represent null when parsing JSON.
> >
> >> Le 26 juin 2016 à 22:35, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >>
> >> Just one question: If I have functions
> >>
> >> json_encode(j: JSON) -> String
> >> and
> >> json_decode(j: String) -> JSON throws
> >
> > If the string is valid JSON, it return .some() optional, if ti is empty,
> it returns .none() optional, and if it is invalid, it throws.
>
> again, `.none()` is not fully specified. So your answer isn't really an
> answer to my question. There is
>
> let null1: String? = nil
> let null2: Int? = nil
> let null3: Any? = nil
>
> and null1, null2 and null3 are three different concrete values. You are
> making it too easy for yourself when you just say `.none()`, without
> specifying the type you are referring to.
>
> Also, `let x = nil` does not even compile, for exactly this reason. So
> again, how do you want to represent a JSON null in Swift?
>
> let json_null: ... = ... // ???
> let myJSONdict = ["a":2, "b":json_null]
>
> -Michael
>
> >
> >> what should be the type of JSON? What should '{"a":2,"b":null}' decode
> to?
> >
> > Dictionary
> >
> >> What should the type of the JSON null value be in Swift?
> >
> > Optional.none()
> >
> >> I think String and String? and String??? are wrong in this case.
> >>
> >> I'm not saying that I'm convinced that NSNull() is the best way to
> represent null in this case. I just want to explain the use case that I was
> thinking of.
> >
> > I hardly can think of a better use case than parsing JSON to demonstrate
> than Optional are a far better solution to represent a null value than
> NSNull.
> >
> >> -Michael
> >>
> >>> Am 26.06.2016 um 19:53 schrieb David Rönnqvist via swift-evolution <
> swift-evolution@swift.org>:
> >>>
> >>> I'm not convinced that Swift needs more than on way of representing
> the lack of a value. As far as I've understood (and remember), NSNull main
> reason to exist is that it's an actual object and won't for example
> terminate array literals. From what I've observed of people who are new to
> Objective-C, NSNull is a big surprise, both its general existence but also
> when to expect it (read check for NSNull to make sure one doesn't crash)
> and when not to.
> >>>
> >>> The way I've imagined that the same problem would be solved in Swift
> is with an optional, optional value. That is: if a field in a response can
> either be set or not, that's an optional. If that field can either contain
> a value or the explicit lack of a value that's another optional:
> >>>
> >>> let nickname: String?? = "Little Bobby Tables"
> >>>
> >>> As I see it, this is both safer (requiring that the inner nil value is
> dealt with), serves as a documentation of when an explicit missing value is
> expected and when it's not, and is more consistent.
> >>>
> >>> I would still expect a newcomer to wonder why there is two question
> marks in some places, but I'd imagine that that explanation would feel more
> logical.
> >>>
> >>> And it's (still) possible (at least in the latest Swift Playground) to
> safely unwrap both levels:
> >>>
> >>> if case let name?? = nickname { }
> >>>
> >>> - David
> >>>
> >>> Sent from my iPad
> >>>
> >>> On 24 Jun 2016, at 11:32, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> > Not really. What is the type of Optional.none? `let empty =
> Optional.none` does not compile, it says "Generic parameter 'Wrapped' could
> not be inferred". NSNull() is a unique concrete value, and it's compatible
> with Objective C, NSObject and AnyObject. We could of course use
> `Optional.none`, but someone else may use `Optional.none`
> instead. The extra type information is just misleading in this case.
> 
>  If you want a single, unique value, use `()`.
> 
>  But I'm not sure why you wouldn't just make this member an
> Optional in the first place. Is there some reason that wouldn't be
> suitable?
> 
>  --
>  Brent Royal-Gordon
>  Architechies
> 
>  ___
>  swift-evolution mailing list
>  swift-evolution@swift.org
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > ___
> > swift-evoluti

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Saagar Jha via swift-evolution]

%, at least to me, suggests distant evaluation; i.e. parameter passing at
the end. $ seems more like an in-place evaluation, like how bash does it.

On Tue, Jun 21, 2016 at 2:14 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> That said, I think it's nice that \, #, $, and @ are all used in unique
> scenarios. What about going a little classical with %?
> On Tue, Jun 21, 2016 at 16:10 Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> on Tue Jun 21 2016, Kenny Wyland  wrote:
>>
>> > Hi all,
>> >
>> > I'm new to the list and I just searched through the archives as best I
>> > could to see if someone else had already brought this up, but I didn't
>> find
>> > anything. Forgive me if this horse has been beaten.
>> >
>> > I find that typing \(var) is very disruptive to my typing flow. The
>> more I
>> > code in Swift, the more I like it, but every time I'm coding and then
>> have
>> > to hiccup while typing \ then ( causes me to be annoyed. I know, it's
>> > minor, but it isn't a key combination that flows quickly.
>> >
>> > I would much rather have $() or perhaps ${} (like Groovy lang) or
>> perhaps
>> > @() to go along with other uses of @ throughout the language.
>> >
>> > A shifted key, like $ or @, followed by another shifted key like (,
>> allows
>> > for a much faster flow and they are much closer to the home keys than \
>> > which is nearly as far from home keys as possible (and awkward).
>>
>> I'm forced to agree that \ is quite awkward for something that may be
>> used so pervasively, and $ would likely meet more peoples' expectations.
>>
>> --
>> Dave
>>
>> ___
>> 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
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] remove(at: Set)

[Saagar Jha via swift-evolution]

This isn’t actually that complex, especially if you ditch the “C-style” for
loop algorithm and switch it to, as you mentioned, “filtering code”. filter,
enumerated (to get indices), and map (to go back to elements) are more than
up to the task. Plus, this is much more efficient.

var myArray = [0, 1, 2]
let indices: Set = [0, 1]
myArray = myArray.enumerated().filter {
return !indices.contains($0.offset)
}.map {
return $0.element // to get the elements back
}
print(myArray) // prints “[2]"

Adding it to the standard library might be useful, but it’s not as hard as
it looks.


On Sat, Jun 18, 2016 at 9:09 PM Karl via swift-evolution <
swift-evolution@swift.org> wrote:

> So like most good pitches, this one comes about because of a bug I
> recently fixed which seems common and subtle enough that I think it would
> be nice to include in the standard library.
>
> Removing a collection of elements at once from a collection. You might
> want to do this in some kind of advanced filtering code. In my case, our
> code was merging adjacent elements in-place, and storing a list of indexes
> that were no longer required because they were now part of a merged
> element, and then we cleaned up the duplicates by removing those indexes.
>
> A näive implementation might look like this:
>
> for index in indexesToRemove {
> myArray.remove(at: index)
> }
>
> However, as the array is mutated, those indexes won’t make sense any more.
> You’ll end up with invalid results - for example, if you have the array
> [0,1,2] and indexesToRemove is [0,1], your resulting array will actually be
> [1] (not [2], as expected). Actually removing a batch of indexes is subtly
> more complex. Here’s my generic implementation:
>
> extension RangeReplaceableCollection where Index:Hashable,
> Self:BidirectionalIndexable {
>
> mutating func remove(at indexes: Set) {
> var removed : IndexDistance = 0
> for idx in indexes.sorted() {
> remove(at: index(idx, offsetBy: -removed))
> removed = removed.advanced(by: 1)
> }
> }
> }
>
> I think it would be nice to have this in the standard library. I think
> it’s a reasonably common problem and it’d be nice to make it easier for
> people.
>
> Karl
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why hard-code octet-sized bytes?

[Saagar Jha via swift-evolution]

I'm not quite sure what you mean. Swift has a type called Int8 that
represents numbers from -128 to 127 using 8 bits. I don't see how this
"excludes" computers.

On Fri, Jun 17, 2016 at 13:01 Daryle Walker via swift-evolution <
swift-evolution@swift.org> wrote:

> When I first looked into Swift, I noticed that the base type was called
> “UInt8” (and “Int8”) and not something like “Byte.”  I know modern
> computers have followed the bog standard 8/16/32(/64) architecture for
> decades, but why hard code it into the language/library?  Why should 36-bit
> processors with 9-bit bytes, or processors that start at 16 bits, be
> excluded right off the bat?  Did you guys see a problem with how
> (Objective-)C(++) had to define its base types in a mushy way to
> accommodate the possibility non-octet bytes?
>
> BTW, is there an equivalent of CHAR_BIT, the number of bits per byte, in
> the library?  Or are we supposed to hard code an “8”?
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Compiler Warning on Unextended Classes

[Saagar Jha via swift-evolution]

I think that linters are the best way to handle this. It’s not really a
code smell that should always be taken care of (which would indicate that
the compiler should warn about it), and as such should be relegated to the
linter.

On Thu, Jun 16, 2016 at 10:08 AM Rehat Kathuria via swift-evolution <
swift-evolution@swift.org> wrote:

> Agree with Sean that this shouldn’t apply to classes declared public; I
> also don’t think the "default by final” discussion ever came to a consensus.
>
> As for linters, my understanding of them is that they’re inclined to
> style-guides as opposed to architectural suggestions.The declaration of a
> class being final isn’t one that’s dependant on style, rather architecture.
>
>
> On 16 Jun 2016, at 17:57, Xiaodi Wu  wrote:
>
> On Thu, Jun 16, 2016 at 11:39 AM, L. Mihalkovic via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Likely a lint level feature, no?
>
>
> Agreed. Sounds like a linter feature.
>
>
>> > On Jun 16, 2016, at 6:27 PM, Sean Heber via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I would think this would not apply to public classes.
>> >
>> > There has also been discussion in the past about making final the
>> default - I don’t remember if that ever resolved into some kind of
>> consensus or not, though.
>> >
>> > l8r
>> > Sean
>> >
>> >
>> >> On Jun 16, 2016, at 11:23 AM, Saagar Jha via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >> Correct me if I’m wrong, but if you’re writing some kind of framework
>> and your class is not final but never subclassed, you wouldn’t want the
>> warning, even if you’d like to allow users to subclass it?
>> >>
>> >>
>> >>
>> >> On Thu, Jun 16, 2016 at 9:02 AM Rehat Kathuria via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >> I’d like the compiler to present a warning when a class not declared
>> as final is never subclassed. Thoughts?
>> >> ___
>> >> swift-evolution mailing list
>> >> swift-evolution@swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >> --
>> >> -Saagar Jha
>> >> ___
>> >> 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
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Compiler Warning on Unextended Classes

[Saagar Jha via swift-evolution]

Correct me if I’m wrong, but if you’re writing some kind of framework and
your class is not final but never subclassed, you wouldn’t want the
warning, even if you’d like to allow users to subclass it?


On Thu, Jun 16, 2016 at 9:02 AM Rehat Kathuria via swift-evolution <
swift-evolution@swift.org> wrote:

> I’d like the compiler to present a warning when a class not declared as
> final is never subclassed. Thoughts?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Nil coalescing operator precedence

[Saagar Jha via swift-evolution]

On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu  wrote:

> On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha  wrote:
>
>> Yes. They’re all operators we know about already, and the same argument
>> applies. Just like you wouldn’t change + to have a higher precedence than
>> *, bitwise operators already have their own, uniform precedences. I can’t
>> see any reason not to have one, other than confusion from those who aren’t
>> completely sure how they function-in which case they’re better of taking a
>> look at the docs (or Quick Help, as another thread suggests) to learn how
>> they work.
>>
>
> FYI, the relative precedence of arithmetic and bitwise operators is not
> the same across languages in the C family. Here, Swift diverges from C and
> resembles Go. I raised this point some time ago and was told in no
> uncertain terms by the core team that it was intentional and that they were
> satisfied with the result.
>

Is the core team talking only for bitwise operators or all of them?


>
>
>>
>> On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин 
>> wrote:
>>
>>> What do you think about arithmetic and bitwise operators? Arithmetic and
>>> casting? Should they have defined precedence?
>>>
>>> - Anton
>>>
>>> 2016-06-15 21:17 GMT+03:00 Saagar Jha :
>>>
 We’ve talked about how expressions like `a + b * c / d` aren’t
 ambiguous because they are borrowed, in this case from math. The same thing
 applies to the ternary conditional: `a ? b : c + x + y`-it too is borrowed
 (from the C-type languages) and behaves likewise. There is no need for
 parentheses-the only people who will think this is ambiguous is those who
 haven’t been introduced to it before. IMHO, requiring parentheses would be
 *more* ambiguous because you’re breaking precedent, people already
 know how it should work, without parentheses. Forcing them to use it breaks
 their prior knowledge. We don’t need to hand-hold people who *know* how
 it works. For those who don’t know, it’s a simple matter of reading it up
 (which they would be doing anyways to learn about it!)

 As for nil coalescing, it’s visually similar to the ternary operator
 and as such has similar behavior. Having a reminder in the Swift guide
 about its precedence should be enough, once users have learned it they
 don’t need to be reminded every time they use it through a warning.


 On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:

> Maybe wise to wait to see if that proposal is accepted. FWIW, my last
> interaction with the core team on operator precedence suggested that they
> believed that they had arrived at the correct relative precedence values
> and were not receptive to changing them.
> On Wed, Jun 15, 2016 at 12:54 Антон Жилин 
> wrote:
>
>> I wonder if it's worth it to start a new thread right now.
>> We could start discussing, what precedence relationships between
>> opeartors should be, even *before* that proposal is accepted.
>> If it's rejected though, that discussion is going to trash bin.
>>
>> - Anton
>>
>> 2016-06-15 19:52 GMT+03:00 Антон Жилин :
>>
>>> Back to associativity, I see nothing wrong with what  a ?? b ?? c
>>>  does. Analogous constructions are found in Ruby, for example. Right
>>> associativity exists so that we can do lazy evaluation, computing 
>>> fallback
>>> values only when required. Nothing terrible, again.
>>>
>>> - Anton
>>>
>>> 2016-06-15 19:15 GMT+03:00 Xiaodi Wu :
>>>


 On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution <
 swift-evolution@swift.org> wrote:

> >  If precedence between two operators is undefined, we cannot omit
> > parentheses.
>
> Hm.. Probably the initial problem could be solved with this? I.e.
> if we'll have *no* defined precedence between math operators and 
> between ??
> and between ?: (and probably something else?)  ?
>

 Sorry, I don't see it. The initial question was about chaining of
 ?? operators. That's a problem with expectations about associativity 
 and
 not about precedence, right?


>
> As for rules of precedence, I think it is really not important
> what precedence will be assigned for ??/?: as in any case IMO most 
> devs
> will not remember this for sure in situation when one need to 
> write/read
> such complex expression.
>
> For me, probably I have some extreme opinion: if we have a mix of
> operators from different domains (math and ?? for example) we need
> parentheses to exclude any kind of ambiguity.
>
> On 15.06.2016 17:53, Антон Жилин wrote:
>
>> Nice points, I also think that unless operato

Re: [swift-evolution] Nil coalescing operator precedence

[Saagar Jha via swift-evolution]

Yes. They’re all operators we know about already, and the same argument
applies. Just like you wouldn’t change + to have a higher precedence than
*, bitwise operators already have their own, uniform precedences. I can’t
see any reason not to have one, other than confusion from those who aren’t
completely sure how they function-in which case they’re better of taking a
look at the docs (or Quick Help, as another thread suggests) to learn how
they work.

On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин  wrote:

> What do you think about arithmetic and bitwise operators? Arithmetic and
> casting? Should they have defined precedence?
>
> - Anton
>
> 2016-06-15 21:17 GMT+03:00 Saagar Jha :
>
>> We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous
>> because they are borrowed, in this case from math. The same thing applies
>> to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from
>> the C-type languages) and behaves likewise. There is no need for
>> parentheses-the only people who will think this is ambiguous is those who
>> haven’t been introduced to it before. IMHO, requiring parentheses would be
>> *more* ambiguous because you’re breaking precedent, people already know
>> how it should work, without parentheses. Forcing them to use it breaks
>> their prior knowledge. We don’t need to hand-hold people who *know* how
>> it works. For those who don’t know, it’s a simple matter of reading it up
>> (which they would be doing anyways to learn about it!)
>>
>> As for nil coalescing, it’s visually similar to the ternary operator and
>> as such has similar behavior. Having a reminder in the Swift guide about
>> its precedence should be enough, once users have learned it they don’t need
>> to be reminded every time they use it through a warning.
>>
>>
>> On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Maybe wise to wait to see if that proposal is accepted. FWIW, my last
>>> interaction with the core team on operator precedence suggested that they
>>> believed that they had arrived at the correct relative precedence values
>>> and were not receptive to changing them.
>>> On Wed, Jun 15, 2016 at 12:54 Антон Жилин 
>>> wrote:
>>>
 I wonder if it's worth it to start a new thread right now.
 We could start discussing, what precedence relationships between
 opeartors should be, even *before* that proposal is accepted.
 If it's rejected though, that discussion is going to trash bin.

 - Anton

 2016-06-15 19:52 GMT+03:00 Антон Жилин :

> Back to associativity, I see nothing wrong with what  a ?? b ?? c
>  does. Analogous constructions are found in Ruby, for example. Right
> associativity exists so that we can do lazy evaluation, computing fallback
> values only when required. Nothing terrible, again.
>
> - Anton
>
> 2016-06-15 19:15 GMT+03:00 Xiaodi Wu :
>
>>
>>
>> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> >  If precedence between two operators is undefined, we cannot omit
>>> > parentheses.
>>>
>>> Hm.. Probably the initial problem could be solved with this? I.e. if
>>> we'll have *no* defined precedence between math operators and between ??
>>> and between ?: (and probably something else?)  ?
>>>
>>
>> Sorry, I don't see it. The initial question was about chaining of ??
>> operators. That's a problem with expectations about associativity and not
>> about precedence, right?
>>
>>
>>>
>>> As for rules of precedence, I think it is really not important what
>>> precedence will be assigned for ??/?: as in any case IMO most devs will 
>>> not
>>> remember this for sure in situation when one need to write/read such
>>> complex expression.
>>>
>>> For me, probably I have some extreme opinion: if we have a mix of
>>> operators from different domains (math and ?? for example) we need
>>> parentheses to exclude any kind of ambiguity.
>>>
>>> On 15.06.2016 17:53, Антон Жилин wrote:
>>>
 Nice points, I also think that unless operators are from the same
 domain,
 more parentheses is better.
 Other than that, what rules do we need? I can name these:
 1. Assignment operators have lower precedence than most operators
 2. Arithmetics has higher precedence than comparative and logical
 operators. I don't think that ?? belongs to arithmetics, it's more
 like
 control flow.
 3. Unary operators obviously have higher precedence than everything

 I didn't read se-0077 in details, so have no opinion. Probably you
> can
>
 describe main ideas of it here in two words.
 Replace numeric precedence with precedence relationships between
 pairs of
 operators. If

Re: [swift-evolution] Nil coalescing operator precedence

[Saagar Jha via swift-evolution]

We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous
because they are borrowed, in this case from math. The same thing applies
to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from
the C-type languages) and behaves likewise. There is no need for
parentheses-the only people who will think this is ambiguous is those who
haven’t been introduced to it before. IMHO, requiring parentheses would be
*more* ambiguous because you’re breaking precedent, people already know how
it should work, without parentheses. Forcing them to use it breaks their
prior knowledge. We don’t need to hand-hold people who *know* how it works.
For those who don’t know, it’s a simple matter of reading it up (which they
would be doing anyways to learn about it!)

As for nil coalescing, it’s visually similar to the ternary operator and as
such has similar behavior. Having a reminder in the Swift guide about its
precedence should be enough, once users have learned it they don’t need to
be reminded every time they use it through a warning.

On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Maybe wise to wait to see if that proposal is accepted. FWIW, my last
> interaction with the core team on operator precedence suggested that they
> believed that they had arrived at the correct relative precedence values
> and were not receptive to changing them.
> On Wed, Jun 15, 2016 at 12:54 Антон Жилин  wrote:
>
>> I wonder if it's worth it to start a new thread right now.
>> We could start discussing, what precedence relationships between
>> opeartors should be, even *before* that proposal is accepted.
>> If it's rejected though, that discussion is going to trash bin.
>>
>> - Anton
>>
>> 2016-06-15 19:52 GMT+03:00 Антон Жилин :
>>
>>> Back to associativity, I see nothing wrong with what  a ?? b ?? c  does.
>>> Analogous constructions are found in Ruby, for example. Right associativity
>>> exists so that we can do lazy evaluation, computing fallback values only
>>> when required. Nothing terrible, again.
>>>
>>> - Anton
>>>
>>> 2016-06-15 19:15 GMT+03:00 Xiaodi Wu :
>>>


 On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution <
 swift-evolution@swift.org> wrote:

> >  If precedence between two operators is undefined, we cannot omit
> > parentheses.
>
> Hm.. Probably the initial problem could be solved with this? I.e. if
> we'll have *no* defined precedence between math operators and between ??
> and between ?: (and probably something else?)  ?
>

 Sorry, I don't see it. The initial question was about chaining of ??
 operators. That's a problem with expectations about associativity and not
 about precedence, right?


>
> As for rules of precedence, I think it is really not important what
> precedence will be assigned for ??/?: as in any case IMO most devs will 
> not
> remember this for sure in situation when one need to write/read such
> complex expression.
>
> For me, probably I have some extreme opinion: if we have a mix of
> operators from different domains (math and ?? for example) we need
> parentheses to exclude any kind of ambiguity.
>
> On 15.06.2016 17:53, Антон Жилин wrote:
>
>> Nice points, I also think that unless operators are from the same
>> domain,
>> more parentheses is better.
>> Other than that, what rules do we need? I can name these:
>> 1. Assignment operators have lower precedence than most operators
>> 2. Arithmetics has higher precedence than comparative and logical
>> operators. I don't think that ?? belongs to arithmetics, it's more
>> like
>> control flow.
>> 3. Unary operators obviously have higher precedence than everything
>>
>> I didn't read se-0077 in details, so have no opinion. Probably you can
>>>
>> describe main ideas of it here in two words.
>> Replace numeric precedence with precedence relationships between
>> pairs of
>> operators. If precedence between two operators is undefined, we
>> cannot omit
>> parentheses.
>>
>> My thought was basically: "parentheses between some operators must be
>> enforced by the language" <=> "SE-0077 is needed"
>>
>> - Anton
>>
>> 2016-06-15 17:17 GMT+03:00 Vladimir.S > >:
>>
>>
>>
>> On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:
>>
>> `b + c * d / e` is not, obviously.
>>
>>
>> obviously, for math operators it seems like we don't need any
>> clarifications
>>
>> `a ? b : c + x + y` -- I'd also say not, because, well, it's
>> ternary
>> operator, the special case that everyone should know
>> (otherwise it
>> looks
>> like a mess with ? and : operators).
>>
>>
>> Yes, it's ternary opera