Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 14 Sep 2017, at 20:10, Ben Rimmington  wrote:
> 
> 
>> On 14 Sep 2017, at 15:31, Haravikk wrote:
>> 
>>> On 14 Sep 2017, at 02:12, Xiaodi Wu wrote:
>>> 
 On Wed, Sep 13, 2017 at 09:13 Haravikk wrote:
 
 I mean because not once have you summarised what these alleged 
 "considerations" were; if they exist then you should be able do so, yet 
 all I am hearing is "it was considered", which frankly is not an argument 
 at all as it is entirely without substance.
>>> 
>>> Of course it is not an argument at all. It is a factual statement. The 
>>> objections which you mentioned were also mentioned prior to a decision 
>>> about SE-0185. The community and the core team had an opportunity to view 
>>> those objections. After that time, a decision was made, having considered 
>>> all the stated pros and cons which included the ones that you are now 
>>> repeating. What "considerations" are you looking for?
>> 
>> Ones with proof that they were ever made! Once again you are stating that 
>> these issues were "considered", yet you show not a single shred of proof 
>> that that was the case. You're asking me to take you at your word but I have 
>> no reason to trust that the problem has been as carefully considered as you 
>> claim.
>> I was involved in one such discussion and the response from the core team 
>> was frankly pitiful; they did not provide any justification whatsoever.
> 
> Chris Lattner already said that the core team discussed your concerns:
> 
> 
> 
> 
> 
> The original idea was for most types to be *implicitly* equatable and 
> hashable:
> 
> 
> 
> The accepted proposal, with *explicit* declaration of conformance, is a good 
> compromise.
> 
> Instead of discussing hypothetical issues with SE-0185, we can wait for Swift 
> 4.1 beta.

And as I pointed out this "consideration" was pathetic; he interjected once 
with a flawed argument and was never seen again. The core team has utterly 
failed to justify their decision. It does not prove "consideration"; there are 
no reasoned points, alternatives are never discussed, it is a dictate not a 
discussion.

But fuck it, I no longer care; it is clear to me now that Swift Evolution 
serves no purpose if the core team cannot or will not listen, and on that basis 
if I cannot trust the core team I cannot trust Swift as a language, and will 
not be using it going forward, as the direction it is taking frankly undermines 
any optimism I once had for it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 14 Sep 2017, at 02:12, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>> On Wed, Sep 13, 2017 at 09:13 Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> I mean because not once have you summarised what these alleged 
>> "considerations" were; if they exist then you should be able do so, yet all 
>> I am hearing is "it was considered", which frankly is not an argument at all 
>> as it is entirely without substance.
> 
> Of course it is not an argument at all. It is a factual statement. The 
> objections which you mentioned were also mentioned prior to a decision about 
> SE-0185. The community and the core team had an opportunity to view those 
> objections. After that time, a decision was made, having considered all the 
> stated pros and cons which included the ones that you are now repeating. What 
> "considerations" are you looking for?

Ones with proof that they were ever made! Once again you are stating that these 
issues were "considered", yet you show not a single shred of proof that that 
was the case. You're asking me to take you at your word but I have no reason to 
trust that the problem has been as carefully considered as you claim.
I was involved in one such discussion and the response from the core team was 
frankly pitiful; they did not provide any justification whatsoever.


But since it's clear that you have no intention of ever responding 
substantively I will not dignify your messages with any further responses as it 
is nothing more than a waste of my time; you hypocritically accuse me of 
repetition, while you also ignore direct questions and any point that doesn't 
fit your "shut up about this" viewpoint. If that is all you have to say then 
you've said it a dozen times over, so kindly stop doing so.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 13 Sep 2017, at 03:26, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Tue, Sep 12, 2017 at 11:43 AM, Haravikk via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> On 12 Sep 2017, at 12:08, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>>> On Mon, Sep 11, 2017 at 06:03 Haravikk via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> See, this is another flawed assumption; you are assuming that omitting a 
>>> custom implementation of == is always intentional rather than an oversight, 
>>> which is not guaranteed. This is one of my gripes with the retroactive 
>>> change to Equatable, as it is currently impossible to omit an 
>>> implementation.
>> 
>> Again, this applies equally to the addition of _any_ default implementation. 
>> And again, such changes don’t even require Swift Evolution approval.
> 
> So what? Because the Swift Evolution process is currently deficient we should 
> just give up on discussing problems with features and the language altogether?
> 
> I don't claim that it's a deficiency; I claim it's reflective of Swift's 
> opinionated take on default implementations. Are you, after all, saying that 
> you have a problem with the addition of _any_ default implementation to an 
> existing protocol? If so, this conversation isn't about synthesis/reflection 
> at all.

No, and you should know that by now. I suggest actually reading some of what I 
have written as I am sick of repeating myself.

>>>>> And precisely what kind of "evidence" am I expected to give? This is a 
>>>>> set of features that do not exist yet, I am trying to argue in favour of 
>>>>> an explicit end-developer centric opt-in rather than an implicit protocol 
>>>>> designer centric one. Yet no-one seems interested in the merits of 
>>>>> allowing developers to choose what they want, rather than having implicit 
>>>>> behaviours appear potentially unexpectedly.
>>>> 
>>>> Both options were examined for Codable and for Equatable/Hashable. The 
>>>> community and core team decided to prefer the current design. At this 
>>>> point, new insights that arise which could not be anticipated at the time 
>>>> of review could prompt revision. However, so far, you have presented 
>>>> arguments already considered during review.
>>> 
>>> And so far all I have heard about this is how it was "decided"; no-one 
>>> seems interested in showing how any of these concerns were addressed (if at 
>>> all), so as far as I can tell they were not, or they were wilfully ignored.
>> 
>> They were addressed by being considered.
> 
> And yet no-one can apparently summarise what those "considerations" might be, 
> suggesting that they were either not considered at all, or that the 
> "consideration" was so weak that no-one is willing to step forward to defend 
> it. Either way it is not sufficient by any reasonable measure.
> 
> If I were to run over your foot in my car, would you be happy to accept that 
> I "considered" it first?
> 
> How do you mean? People wrote in with their opinions. Then, taking into 
> account the community's response, the proposal was approved.

I mean because not once have you summarised what these alleged "considerations" 
were; if they exist then you should be able do so, yet all I am hearing is "it 
was considered", which frankly is not an argument at all as it is entirely 
without substance.

If it was genuinely considered then someone should be able to say what points 
were considered and what conclusions were reached and why. And even if there 
was an earlier decision, that doesn't necessarily make it right. We are 
discussing it now, and it is clear that any decision that has been made has 
been made poorly at best.

And if you're talking about the discussion on Equatable/Hashable specifically, 
I'm afraid your memory of the "considerations" is radically different to mine; 
as the concerns I raised were essentially ignored, as not a single person gave 
a justification more substantial than "but, but Codable!" which frankly isn't a 
justification at all.

>>>>> Therefore, your argument reduces to one about which default 
>>>>> implementations generally ought or ought not to be provided--that is, 
>>>>> that they ought to be provided only when their correctness can be 
>>>>> guaranteed for all (rather than almost all) possible confo

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 12 Sep 2017, at 16:29, Tony Allevato via swift-evolution 
>  wrote:
> 
> Since your game involves the specific question of a property that should not 
> be considered for Equatable synthesis, and since SE-0185 explicitly calls out 
> the notion of transient properties as a future direction to solve that 
> specific problem, then my solution is "I declare the property as transient."
> 
> Surely this is an acceptable solution? It achieves the goal you set, and more 
> concisely/quickly than the ways you proposed in that post. It doesn't require 
> me to go fishing through code; the act of adding the property and making it 
> transient is completely localized to one place (it's one line!). If there's a 
> synthesized implementation of Equatable, then the property gets ignored as 
> desired. If there's a handwritten implementation, then the new property is 
> already ignored because it wasn't there to begin with, but the transient 
> declaration still provides valuable information to the reader of the code 
> about the intention.
> 
> If the rebuttal to that is going to be "a developer may not know about 
> transient", then where do we draw the line at expecting users to know how to 
> use the features their language? It's a significant leap to go from 
> "developers might do the wrong thing" to "so this specific approach is the 
> only right way to fix it."

I think that it's reasonable to assume that the protocol would inform 
developers of the use of transient, but this comes back to the original topic 
of this thread; if the developer didn't ask for the synthesised behaviour then 
is it reasonable to assume they'll have properly marked their properties as 
transient?

My argument would (perhaps unsurprisingly) be no; a default implementation that 
can make use of attributes is IMO something that a developer should opt into 
explicitly as a convenient alternative to providing a full implementation 
themselves.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 12 Sep 2017, at 12:08, Xiaodi Wu <xiaodi...@gmail.com 
> <mailto:xiaodi...@gmail.com>> wrote:
> 
>> On Mon, Sep 11, 2017 at 06:03 Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> See, this is another flawed assumption; you are assuming that omitting a 
>> custom implementation of == is always intentional rather than an oversight, 
>> which is not guaranteed. This is one of my gripes with the retroactive 
>> change to Equatable, as it is currently impossible to omit an implementation.
> 
> Again, this applies equally to the addition of _any_ default implementation. 
> And again, such changes don’t even require Swift Evolution approval.

So what? Because the Swift Evolution process is currently deficient we should 
just give up on discussing problems with features and the language altogether?

>>>> And precisely what kind of "evidence" am I expected to give? This is a set 
>>>> of features that do not exist yet, I am trying to argue in favour of an 
>>>> explicit end-developer centric opt-in rather than an implicit protocol 
>>>> designer centric one. Yet no-one seems interested in the merits of 
>>>> allowing developers to choose what they want, rather than having implicit 
>>>> behaviours appear potentially unexpectedly.
>>> 
>>> Both options were examined for Codable and for Equatable/Hashable. The 
>>> community and core team decided to prefer the current design. At this 
>>> point, new insights that arise which could not be anticipated at the time 
>>> of review could prompt revision. However, so far, you have presented 
>>> arguments already considered during review.
>> 
>> And so far all I have heard about this is how it was "decided"; no-one seems 
>> interested in showing how any of these concerns were addressed (if at all), 
>> so as far as I can tell they were not, or they were wilfully ignored.
> 
> They were addressed by being considered.

And yet no-one can apparently summarise what those "considerations" might be, 
suggesting that they were either not considered at all, or that the 
"consideration" was so weak that no-one is willing to step forward to defend 
it. Either way it is not sufficient by any reasonable measure.

If I were to run over your foot in my car, would you be happy to accept that I 
"considered" it first?

>>>> Therefore, your argument reduces to one about which default 
>>>> implementations generally ought or ought not to be provided--that is, that 
>>>> they ought to be provided only when their correctness can be guaranteed 
>>>> for all (rather than almost all) possible conforming types. To which point 
>>>> I sketched a rebuttal above.
>>> 
>>> If a protocol defines something, and creates a default implementation based 
>>> only upon those definitions then it must by its very nature be correct. A 
>>> concrete type may later decided to go further, but that is a feature of the 
>>> concrete type, not a failure of the protocol itself which can function 
>>> correctly within the context it created. You want to talk evidence, yet 
>>> there has been no example given that proves otherwise; thus far only Itai 
>>> has attempted to do so, but I have already pointed out the flaws with that 
>>> example.
>>> 
>>> The simple fact is that a default implementation may either be flawed or 
>>> not within the context of the protocol itself; but a reflective or 
>>> synthetic implementation by its very nature goes beyond what the protocol 
>>> defines and so is automatically flawed because as it does not rely on the 
>>> end-developer to confirm correctness, not when provided implicitly at least.
>>> 
>>> Again, if it applies generally, it must apply specifically. What is 
>>> "automatically flawed" about the very reasonable synthesized default 
>>> implementation of ==?
>> 
>> It makes the assumption that every equatable property of a type is 
>> necessarily relevant to its equality.
> 
> No necessarily, only provisionally and rebuttably. If it’s not the case, 
> override the default.

So… entirely unlike standard default implementations which cannot 
"provisionally" assume something is relevant at all, thereby making them 
entirely different from synthesised/reflective implementations!

I'm sorry, but you keep trying to argue that they're the same, but then 
admitting that they're not. You can't have it both ways.

>> Consider for example if a type stores

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 9 Sep 2017, at 18:41, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> 
> On Sat, Sep 9, 2017 at 06:41 Haravikk via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> On 9 Sep 2017, at 09:33, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> 
>> On Sat, Sep 9, 2017 at 02:47 Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On 9 Sep 2017, at 02:02, Xiaodi Wu <xiaodi...@gmail.com 
>>> <mailto:xiaodi...@gmail.com>> wrote:
>>> 
>>> On Fri, Sep 8, 2017 at 4:00 PM, Itai Ferber via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>>> On Sep 8, 2017, at 12:46 AM, Haravikk via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> 
>>>>> On 7 Sep 2017, at 22:02, Itai Ferber <ifer...@apple.com 
>>>>> <mailto:ifer...@apple.com>> wrote:
>>>>> 
>>>>> protocol Fooable : Equatable { // Equatable is just a simple example
>>>>> var myFoo: Int { get }
>>>>> }
>>>>> 
>>>>> extension Fooable {
>>>>> static func ==(_ lhs: Self, _ rhs: Self) -> Bool {
>>>>> return lhs.myFoo == rhs.myFoo
>>>>> }
>>>>> }
>>>>> 
>>>>> struct X : Fooable {
>>>>> let myFoo: Int
>>>>> let myName: String
>>>>> // Whoops, forgot to give an implementation of ==
>>>>> }
>>>>> 
>>>>> print(X(myFoo: 42, myName: "Alice") == X(myFoo: 42, myName: "Bob")) // 
>>>>> true
>>>>> This property is necessary, but not sufficient to provide a correct 
>>>>> implementation. A default implementation might be able to assume 
>>>>> something about the types that it defines, but it does not necessarily 
>>>>> know enough.
>>>> 
>>>> Sorry but that's a bit of a contrived example; in this case the protocol 
>>>> should not implement the equality operator if more information may be 
>>>> required to define equality. It should only be implemented if the protocol 
>>>> is absolutely clear that .myFoo is the only part of a Fooable that can or 
>>>> should be compared as equatable, e.g- if a Fooable is a database record 
>>>> and .myFoo is a primary key, the data could differ but it would still be a 
>>>> reference to the same record.
>>>> 
>>>> To be clear, I'm not arguing that someone can't create a regular default 
>>>> implementation that also makes flawed assumptions, but that 
>>>> synthesised/reflective implementations by their very nature have to, as 
>>>> they cannot under every circumstance guarantee correctness when using 
>>>> parts of a concrete type that they know nothing about.
>>> 
>>> You can’t argue this both ways:
>>> If you’re arguing this on principle, that in order for synthesized 
>>> implementations to be correct, they must be able to — under every 
>>> circumstance — guarantee correctness, then you have to apply the same 
>>> reasoning to default protocol implementations. Given a default protocol 
>>> implementation, it is possible to come up with a (no matter how contrived) 
>>> case where the default implementation is wrong. Since you’re arguing this 
>>> on principle, you cannot reject contrived examples.
>>> If you are arguing this in practice, then you’re going to have to back up 
>>> your argument with evidence that synthesized examples are more often wrong 
>>> than default implementations. You can’t declare that synthesized 
>>> implementations are by nature incorrect but allow default implementations 
>>> to slide because in practice, many implementations are allowable. There’s a 
>>> reason why synthesis passed code review and was accepted: in the majority 
>>> of cases, synthesis was deemed to be beneficial, and would provide correct 
>>> behavior. If you are willing to say that yes, sometimes default 
>>> implementations are wrong but overall they’re correct, you’re going to have 
>>> to provide hard evidence to back up the opposite case for synthesized 
>>> implementations. You st

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 9 Sep 2017, at 09:33, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> 
> On Sat, Sep 9, 2017 at 02:47 Haravikk via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> On 9 Sep 2017, at 02:02, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> On Fri, Sep 8, 2017 at 4:00 PM, Itai Ferber via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Sep 8, 2017, at 12:46 AM, Haravikk via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>>> On 7 Sep 2017, at 22:02, Itai Ferber <ifer...@apple.com 
>>>> <mailto:ifer...@apple.com>> wrote:
>>>> 
>>>> protocol Fooable : Equatable { // Equatable is just a simple example
>>>> var myFoo: Int { get }
>>>> }
>>>> 
>>>> extension Fooable {
>>>> static func ==(_ lhs: Self, _ rhs: Self) -> Bool {
>>>> return lhs.myFoo == rhs.myFoo
>>>> }
>>>> }
>>>> 
>>>> struct X : Fooable {
>>>> let myFoo: Int
>>>> let myName: String
>>>> // Whoops, forgot to give an implementation of ==
>>>> }
>>>> 
>>>> print(X(myFoo: 42, myName: "Alice") == X(myFoo: 42, myName: "Bob")) // true
>>>> This property is necessary, but not sufficient to provide a correct 
>>>> implementation. A default implementation might be able to assume something 
>>>> about the types that it defines, but it does not necessarily know enough.
>>> 
>>> Sorry but that's a bit of a contrived example; in this case the protocol 
>>> should not implement the equality operator if more information may be 
>>> required to define equality. It should only be implemented if the protocol 
>>> is absolutely clear that .myFoo is the only part of a Fooable that can or 
>>> should be compared as equatable, e.g- if a Fooable is a database record and 
>>> .myFoo is a primary key, the data could differ but it would still be a 
>>> reference to the same record.
>>> 
>>> To be clear, I'm not arguing that someone can't create a regular default 
>>> implementation that also makes flawed assumptions, but that 
>>> synthesised/reflective implementations by their very nature have to, as 
>>> they cannot under every circumstance guarantee correctness when using parts 
>>> of a concrete type that they know nothing about.
>> 
>> You can’t argue this both ways:
>> If you’re arguing this on principle, that in order for synthesized 
>> implementations to be correct, they must be able to — under every 
>> circumstance — guarantee correctness, then you have to apply the same 
>> reasoning to default protocol implementations. Given a default protocol 
>> implementation, it is possible to come up with a (no matter how contrived) 
>> case where the default implementation is wrong. Since you’re arguing this on 
>> principle, you cannot reject contrived examples.
>> If you are arguing this in practice, then you’re going to have to back up 
>> your argument with evidence that synthesized examples are more often wrong 
>> than default implementations. You can’t declare that synthesized 
>> implementations are by nature incorrect but allow default implementations to 
>> slide because in practice, many implementations are allowable. There’s a 
>> reason why synthesis passed code review and was accepted: in the majority of 
>> cases, synthesis was deemed to be beneficial, and would provide correct 
>> behavior. If you are willing to say that yes, sometimes default 
>> implementations are wrong but overall they’re correct, you’re going to have 
>> to provide hard evidence to back up the opposite case for synthesized 
>> implementations. You stated in a previous email that "A 
>> synthesised/reflective implementation however may return a result that is 
>> simply incorrect, because it is based on assumptions made by the protocol 
>> developer, with no input from the developer of the concrete type. In this 
>> case the developer must override it in to provide correct behaviour." — if 
>> you can back this up with evidence (say, taking a survey of a large number 
>> of model types and see if in the majority of cases synthesized 
>> implementation would be incorrect) to provide a compelling argument, then 
>>

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 7 Sep 2017, at 19:36, Tony Allevato <tony.allev...@gmail.com> wrote:
> 
> 
> 
> On Thu, Sep 7, 2017 at 11:18 AM Haravikk via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> On 7 Sep 2017, at 18:53, Tony Allevato via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> On Thu, Sep 7, 2017 at 10:39 AM Gwendal Roué <gwendal.r...@gmail.com 
>> <mailto:gwendal.r...@gmail.com>> wrote:
>>> Le 7 sept. 2017 à 14:45, Tony Allevato <tony.allev...@gmail.com 
>>> <mailto:tony.allev...@gmail.com>> a écrit :
>>> 
>>> Right, let's make sure we're talking about the right thing here. Gwendal, 
>>> your issue isn't with synthesis in the form of Codable or the new additions 
>>> to Equatable/Hashable which are opt-in-by-conformance, it's with the 
>>> specific case of raw value enums or enums without associated values where 
>>> the synthesis is implicit with no way to opt-out. That's a big difference.
>> 
>> Yes.
>> 
>>> I can definitely see the latter being an issue if it were more widespread, 
>>> and I'd be supportive of those enums being required to declare their 
>>> conformance for consistency (though it would be source breaking).
>> 
>> Yes, unfortunately.
>> 
>> 
>>> However, I still haven't seen a real issue that has come up because of the 
>>> distinction being drawn here between default implementations vs. 
>>> implementations that can access other parts of the concrete type. It sounds 
>>> like this discussion is trying to protect against a hypothetical problem 
>>> that hasn't happened yet and may not happen; it would be helpful to show 
>>> some motivating real-world cases where this is indeed a severe problem.
>> 
>> Yes. I'm not talking about implementation itself. I know this has been the 
>> main topic until I have tried to bring in the topic of the consequences of 
>> non-avoidable synthesis (extra methods that may conflict with userland 
>> methods).
>> 
>> If you ask me for a real-world case, then I think I gave one. Let me 
>> rephrase it:
>> 
>> it's impossible to define a value-backed enum without getting free Equatable 
>> conformance. This free conformance is sometimes unwanted, and I gave the 
>> example of DSLs. Now this problem is not *severe*. It's more a blind spot in 
>> the language, and finally just an unwanted side-effect of a compiler 
>> convenience,
>> 
>> Again, this is not the issue that Haravikk is describing in this thread.
>> 
>> I'll clarify—your issue is specifically with the fact that enums with raw 
>> values and enums without associated values receive Equatable even without 
>> explicitly conforming to it, and therefore users have no way of opting out 
>> of it. This predates SE-0185, and I didn't propose making any changes to the 
>> conformance of those enums for source compatibility reasons, though I 
>> wouldn't be opposed to it because it makes them consistent across the board.
>> 
>> Haravikk's argument is about synthesized conformances like Codable and 
>> Equatable/Hashable in SE-0185, where the user must explicitly conform the 
>> type to those protocols. His claim is that that act of opting in is not 
>> sufficient and that it is still dangerous if those synthesized conformances 
>> can access members that are not also declared in the protocol. That's a 
>> completely separate issue to yours, and one that I hope he'll present more 
>> evidence of. Right now, requiring that you not only explicitly conform to 
>> the protocol but also explicitly request the synthesis feels like a solution 
>> without an actual problem, and is a situation we already have today with 
>> default method implementations.
> 
> The simplest real-world case is easy:
> 
>   struct Foo { var data:String }
>   extension Foo : Equatable {} // This currently produces an error, in 
> future it will not
> 
> 
> Why is this a problem? It's no different than if someone extended Foo to 
> conform to a protocol with a default implementation that was written in code.

I'm sorry but I have now explained why it isn't multiple times; a 
non-reflective default conformance can ONLY act upon methods and properties 
that the protocol itself has defined, meaning that it knows everything it needs 
to know in order to do whatever it wants to do with those methods and 
properties because it defined them.

Reflective/synthesised default implementations must by 

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 7 Sep 2017, at 00:11, Brent Royal-Gordon <br...@architechies.com> wrote:
> 
>> On Sep 5, 2017, at 1:02 PM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> This proposal idea is essentially for a new attribute @synthetic (name is up 
>> for debate). This attribute is required for any default implementation that 
>> includes reflective type compiler magic, use of the reflection API against 
>> `self` or, in future, any native Swift macros within the method (possibly 
>> limited to specific features, will depend on the macro language and its 
>> capabilities).
> 
> 
> "Use of the reflection API against `self`"? `String(describing:)` and 
> `String(reflecting:)` sometimes do that.
> 
> I see zero justification for having @synthetic cover all of these random 
> things, but not ordinary default implementations—they have the same amount of 
> dangerous implicitness.

Actually they don't; the problem here is that through reflection you are 
accessing and manipulating concrete types. A non-reflective default 
implementation only has access to what the protocol itself has defined. The 
synthetic alternatives are instead diving into parts of a concrete type that 
may have nothing to do with the protocol at all, and must therefore make 
assumptions that cannot be guaranteed to be correct, this is what makes them 
dangerous.

> On 6 Sep 2017, at 23:43, Nevin Brackett-Rozinsky 
> <nevin.brackettrozin...@gmail.com> wrote:
>> On Wed, Sep 6, 2017 at 5:42 PM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> the issue I'm trying to raise is that when those, and similar features, are 
>> used in synthesised behaviour (default implementations based upon the 
>> concrete type), that these behaviours should be opted into explicitly, 
>> otherwise they open up potential for all kinds of bugs, even when the 
>> assumptions being made about the concrete type are simple such as in the 
>> case for Equatable/Hashable. There's just too much potential for this kind 
>> of reflective protocol implementation to overreach; to me it feels very much 
>> like going into a restaurant and the waiter coming across and force-feeding 
>> me something I don't want instead of taking my order.
> 
> I might suggest that instead it is like you have gone into a pizza shop and 
> said, “I’d like a large veggie pizza please.” And they made you a pizza with 
> their standard dough and their standard sauce and their standard cheese and 
> their standard selection of vegetables.

Actually I don't think that's quite it either; to strain the analogy even 
further, I'd say it's more like going into a pizza shop and saying "I'd like a 
pizza" and the staff looking at you and deciding you look like a vegetarian and 
giving you a vegetarian pizza.

The crux of the issue here are the assumptions that are being made; for a 
standard default implementation there are no assumptions, because you're 
operating on the basis of methods and properties that you yourself have defined 
as the protocol creator that, where properly implemented, have precisely 
defined requirements, behaviours etc. When you're doing it with some form of 
compile-time or run-time reflection however you're messing around with parts of 
a concrete type that the protocol itself doesn't actually know anything about 
with any certainty.

It's the same reason that run-time reflection isn't something you should ever 
want to do, because while it might work with all of the types you test 
directly, if it supports arbitrary types (which it'd need to, or there'd be no 
point to reflecting) then there's always the risk of encountering a type where 
some part of it doesn't match the assumptions that you've made. Of course there 
are use-cases where this may not matter, e.g- if you're just dumping data from 
a type and don't really care if you're storing stuff that isn't important, but 
in other cases such as Equatable and Hashable it can make a difference, as it 
can drastically affect behaviour when those assumptions fail.

> On 7 Sep 2017, at 05:00, Andrew Thompson <mrwerdo...@me.com> wrote:
> Perhaps we could find a solution by meeting in the middle. Introduce a 
> compiler flag that will disable the automatic synthesis and revert to the old 
> behaviour (i.e. swiftc main.swift —disable-automatic-synthesis )

Thanks for the suggestion, but that's a bit too all-or-nothing; I realise I 
might seem very negative but to be clear, I do want these synthesised features, 
I just don't want them in their current form. What I want is for them to be 
explicitly opted into where I, as the developer, need

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 6 Sep 2017, at 16:26, Eagle Offshore <eagleoffsh...@mac.com> wrote:
>> On Sep 6, 2017, at 1:32 AM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> As a general rule I would argue that Mirrors should almost never be used for 
>> any purpose, except perhaps debugging; in production code they can lead to 
>> subtle and misleading problems, not to mention any performance impacts. Even 
>> for things like serialising types, it is not a desirable way to do it, and 
>> should only be used as a last resort because of missing features in Swift.
> 
> I'm just going to toss in that you and I apparently have diametrically 
> opposed needs and belief systems about what makes for a good programming 
> language.  I believe the exact opposite.
> 
> After 20+ years of Cocoa development, I rely on these features heavily and 
> consider any language that lacks them to be more or less "dead" where I 
> consider languages that have them to be "self aware" and "lively".
> 
> For instance, I think relying on the compiler to generate special code to 
> implement Codable rather than just exposing the meta facilities required to 
> do introspection is taking the long way around rather than the short cut.
> 
> So add my vote for powerful reflection capabilities.  

Sorry I think my remark was unclear; my comment there was specifically about 
the use of run-time reflection, which I believe usually indicates a failure of 
a language to provide other, more appropriate features (like Codable in fact). 
I'm not against the features where they make sense and are implemented in well, 
I was just pointing out that the use of run-time reflection in code is usually 
a sign of a last resort.

That's not really important though; the issue I'm trying to raise is that when 
those, and similar features, are used in synthesised behaviour (default 
implementations based upon the concrete type), that these behaviours should be 
opted into explicitly, otherwise they open up potential for all kinds of bugs, 
even when the assumptions being made about the concrete type are simple such as 
in the case for Equatable/Hashable. There's just too much potential for this 
kind of reflective protocol implementation to overreach; to me it feels very 
much like going into a restaurant and the waiter coming across and 
force-feeding me something I don't want instead of taking my order.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 6 Sep 2017, at 01:36, Robert Bennett <rltbenn...@icloud.com> wrote:
> 
> I take issue with the fact that this problem is no different from 
> accidentally gaining the default inheritance of *any* member required by a 
> protocol and implemented in an extension of that protocol. The fact that in 
> this case conformance is synthesized by the compiler instead of written in 
> source code somewhere is immaterial; in principle, nothing is (was?) stopping 
> the same default implementation from being implemented with a Mirror instead 
> of the current approach.

This is why I'm proposing that Mirrors of `self` should likewise require the 
new attribute; while I realise it may be possible to sneak self-reflection in 
somehow regardless by tricking the compiler, this should at least pick up the 
most obvious cases. A more complete solution could possibly just consider all 
use of reflection to be synthetic, requiring methods callable from protocol 
extensions (global functions, static methods etc.) to use the attribute as 
well, so that the compiler can detect any function call with `self` that could 
potentially result in reflective behaviour.

The issue here isn't that there might be other ways to do it (these can be 
addressed), it's that all methods of doing this should require developers to 
explicitly opt-in, otherwise it leads to potential bugs and/or unwanted 
behaviour. It's also IMO a gross overreach for protocols to begin with, and 
sets a dangerous precedent for a language that's supposed to be about safety 
and prevention of bugs, especially when in the case of Equatable and Hashable 
it will actually hide bugs that are currently caught.

As a general rule I would argue that Mirrors should almost never be used for 
any purpose, except perhaps debugging; in production code they can lead to 
subtle and misleading problems, not to mention any performance impacts. Even 
for things like serialising types, it is not a desirable way to do it, and 
should only be used as a last resort because of missing features in Swift.

> I still think that the role keyword proposal is the best solution to this 
> problem proposed so far. 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037484.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037484.html>
While I support the idea of these role keywords, they don't solve all of the 
same problems. Consider for example a missing protocol requirement; currently 
it is caught if a protocol cannot offer a default implementation for it, 
however, in the presence of synthetic behaviour it is possible that the 
requirement is met, but by a method that will not work as desired.

The main issue here is that we're talking about methods that appear like 
default implementations, but go well beyond what the protocol itself defines; 
when you start delving into concrete types from within a protocol you are 
making assumptions about that concrete type that simply cannot be guaranteed. 
Any mistake or omission by a developer could lead to behaviour they do not 
want, and that may not be easy to debug, and in the case of Equatable and 
Hashable is a potential bug that is currently impossible.

>> On Sep 5, 2017, at 4:02 PM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> Some of you will have seen my impassioned pleas on the synthesised 
>> Equatable/Hashable thread against implementing implicit synthesised 
>> behaviour on protocols that must, by necessity, make assumptions about a 
>> concrete type that could be incorrect.
>> 
>> For those that haven't, the concept of synthetic behaviour in discussion 
>> here is essentially any kind of default behaviour for a protocol that is 
>> automatically generated based upon the concrete type itself (rather than 
>> just what the protocol defines). Currently this refers to compiler magic as 
>> proposed for Codable, Equatable and Hashable, but also includes the 
>> reflection API and any future native macro support for Swift. Using any of 
>> these to implement default methods for protocols should IMO be made explicit 
>> to developers using any such protocol so that they can specifically opt-in 
>> to the behaviour only if they want to and understand what it does.
>> 
>> This proposal idea is essentially for a new attribute @synthetic (name is up 
>> for debate). This attribute is required for any default implementation that 
>> includes reflective type compiler magic, use of the reflection API against 
>> `self` or, in future, any native Swift macros within the method (possibly 
>> limited to specific features, will depend on the macro language and its 
>> capabilities). If a default method does not have this attribu

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

> On 6 Sep 2017, at 01:36, Robert Bennett <rltbenn...@icloud.com 
> <mailto:rltbenn...@icloud.com>> wrote:
> 
> I take issue with the fact that this problem is no different from 
> accidentally gaining the default inheritance of *any* member required by a 
> protocol and implemented in an extension of that protocol. The fact that in 
> this case conformance is synthesized by the compiler instead of written in 
> source code somewhere is immaterial; in principle, nothing is (was?) stopping 
> the same default implementation from being implemented with a Mirror instead 
> of the current approach.

This is why I'm proposing that Mirrors of `self` should likewise require the 
new attribute; while I realise it may be possible to sneak self-reflection in 
somehow regardless by tricking the compiler, this should at least pick up the 
most obvious cases. A more complete solution could possibly just consider all 
use of reflection to be synthetic, requiring methods callable from protocol 
extensions (global functions, static methods etc.) to use the attribute as 
well, so that the compiler can detect any function call with `self` that could 
potentially result in reflective behaviour.

The issue here isn't that there might be other ways to do it (these can be 
addressed), it's that all methods of doing this should require developers to 
explicitly opt-in, otherwise it leads to potential bugs and/or unwanted 
behaviour. It's also IMO a gross overreach for protocols to begin with, and 
sets a dangerous precedent for a language that's supposed to be about safety 
and prevention of bugs, especially when in the case of Equatable and Hashable 
it will actually hide bugs that are currently caught.

As a general rule I would argue that Mirrors should almost never be used for 
any purpose, except perhaps debugging; in production code they can lead to 
subtle and misleading problems, not to mention any performance impacts. Even 
for things like serialising types, it is not a desirable way to do it, and 
should only be used as a last resort because of missing features in Swift.

> I still think that the role keyword proposal is the best solution to this 
> problem proposed so far. 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037484.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037484.html>
While I support the idea of these role keywords, they don't solve all of the 
same problems. Consider for example a missing protocol requirement; currently 
it is caught if a protocol cannot offer a default implementation for it, 
however, in the presence of synthetic behaviour it is possible that the 
requirement is met, but by a method that will not work as desired.

The main issue here is that we're talking about methods that appear like 
default implementations, but go well beyond what the protocol itself defines; 
when you start delving into concrete types from within a protocol you are 
making assumptions about that concrete type that simply cannot be guaranteed. 
Any mistake or omission by a developer could lead to behaviour they do not 
want, and that may not be easy to debug, and in the case of Equatable and 
Hashable is a potential bug that is currently impossible.

>> On Sep 5, 2017, at 4:02 PM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> Some of you will have seen my impassioned pleas on the synthesised 
>> Equatable/Hashable thread against implementing implicit synthesised 
>> behaviour on protocols that must, by necessity, make assumptions about a 
>> concrete type that could be incorrect.
>> 
>> For those that haven't, the concept of synthetic behaviour in discussion 
>> here is essentially any kind of default behaviour for a protocol that is 
>> automatically generated based upon the concrete type itself (rather than 
>> just what the protocol defines). Currently this refers to compiler magic as 
>> proposed for Codable, Equatable and Hashable, but also includes the 
>> reflection API and any future native macro support for Swift. Using any of 
>> these to implement default methods for protocols should IMO be made explicit 
>> to developers using any such protocol so that they can specifically opt-in 
>> to the behaviour only if they want to and understand what it does.
>> 
>> This proposal idea is essentially for a new attribute @synthetic (name is up 
>> for debate). This attribute is required for any default implementation that 
>> includes reflective type compiler magic, use of the reflection API against 
>> `self` or, in future, any native Swift macros within the method (possibly 
>> limited to specific features, will depend on the macro language and its 
>> capabilities). I

[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Haravikk via swift-evolution]

Some of you will have seen my impassioned pleas on the synthesised 
Equatable/Hashable thread against implementing implicit synthesised behaviour 
on protocols that must, by necessity, make assumptions about a concrete type 
that could be incorrect.

For those that haven't, the concept of synthetic behaviour in discussion here 
is essentially any kind of default behaviour for a protocol that is 
automatically generated based upon the concrete type itself (rather than just 
what the protocol defines). Currently this refers to compiler magic as proposed 
for Codable, Equatable and Hashable, but also includes the reflection API and 
any future native macro support for Swift. Using any of these to implement 
default methods for protocols should IMO be made explicit to developers using 
any such protocol so that they can specifically opt-in to the behaviour only if 
they want to and understand what it does.

This proposal idea is essentially for a new attribute @synthetic (name is up 
for debate). This attribute is required for any default implementation that 
includes reflective type compiler magic, use of the reflection API against 
`self` or, in future, any native Swift macros within the method (possibly 
limited to specific features, will depend on the macro language and its 
capabilities). If a default method does not have this attribute, then the 
compiler will produce an error with the appropriate fix-it. For convenience 
this attribute can be applied to any extension block or even a protocol 
definition in order to mark all methods in that block/type as synthetic, though 
it's worth noting that doing so will prevent these default implementations from 
being provided if they don't actually need this attribute.

Basically the intention is that any protocol default implementation that 
requires more knowledge about the concrete type than merely what the protocol 
(and its parents) provide direct access to, must be marked as synthetic.

To use the synthetic behaviour of a protocol, developers must then use the 
@synthetic keyword when conforming to it, explicitly indicating that they want 
the extra behaviours rather than implementing the method(s) for themselves. To 
ignore the synthetic behaviour (and thus require some kind of manual 
implementation of methods as normal), simply omit the keyword:

struct Foo : @synthetic Equatable { var someData:String }
// Type fully conforms to Equatable using synthetic behaviour 
(equatable properties must be equal)
struct Foo : Equatable { var someData:String }
// Error due to unimplemented methods, but offers @synthetic as 
a fix-it if all unimplemented methods are @synthetic

It is possible that the attribute could be expanded to have parameters, 
allowing for synthetic conformance only on specific methods, but I'm unsure if 
that'd be the best way to do it, or how likely that is to be needed.

With this kind of explicit declaration it becomes obvious within code when a 
developer is specifically choosing to benefit from synthetic behaviour; this 
hopefully makes it more likely that a developer will fully consider what the 
implications of this may be, rather than doing it accidentally. The idea in 
part is to distinguish such types as having separate protocol and synthesised 
behaviour, where conformance without the @synthetic attribute specifically 
requires that all protocol requirements be met in full, and that any default 
behaviour is implemented only on the basis of the protocol itself, while adding 
@synthetic identifies that more invasive automated behaviour is 
permitted/requested.

At this stage I don't think there should be much of an impact for existing 
code; as far as I can tell it should only affect any protocols that happen to 
be using Mirror(reflecting: self) for some reason within a default 
implementation, which I can't imagine represents a huge subsection of existing 
code, and the fix is the simple addition of an attribute.


Anyway, this is basically just a rough dump of the ideas for how the 
synthesised Codable, Equatable and Hashable behaviours (and anything else 
anyone can think of) should be changed before Swift 4 is released. I'm hoping 
for feedback before I make a formal proposal as I don't have a lot of time at 
the moment, so am looking to do the more structured document once stuff has 
been hammered out a bit.

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

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 19 Aug 2017, at 19:46, Daryle Walker <dary...@mac.com> wrote:
> 
>> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de <mailto:2...@gmx.de>> 
>>> wrote:
>>>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>>> For me the whole point of a basic protocol is that it forces me to 
>>>> implement some requirements in order to conform; I can throw a bunch of 
>>>> protocols onto a type and know that it won't compile until I've finished 
>>>> it, developers get distracted, leave things unfinished to go back to 
>>>> later, make typos etc. etc. To me declaring a conformance is a declaration 
>>>> of "my type will meet the requirements for this make, sure I do it", not 
>>>> "please, please use some magic to do this for me"; there needs to be a 
>>>> clear difference between the two.
>>> 
>>> My conclusion isn't as pessimistic as yours, but I share your objections: 
>>> Mixing a normal feature (protocols) with compiler magic doesn't feel right 
>>> to me — wether it's Equatable, Hashable, Codable or Error.
>>> It's two different concepts with a shared name*, so I think even 
>>> AutoEquatable wouldn't be the right solution, and something like #Equatable 
>>> would be a much better indicator for what is happening.
>>> 
>>> Besides that specific concern, I can't fight the feeling that the evolution 
>>> process doesn't work well for proposals like this:
>>> It's a feature that many people just want to have as soon as possible, and 
>>> concerns regarding the long-term effects are more or less washed away with 
>>> eagerness.
>>> 
>>> - Tino
>>> 
>>> * for the same reason, I have big concerns whenever someone proposes to 
>>> blur the line between tuples and arrays
>> 
>> Agreed. To be clear though; in spite of my pessimism this is a feature that 
>> I do want, but I would rather not have it at all than have it implemented in 
>> a way that hides bugs and sets a horrible precedent for the future.
> 
> I tried to make a split thread for this, but would you object to synthesized 
> conformance if we had to explicitly add a command within the definition block 
> to trigger the synthesis? If we add strong type-aliases, we could reuse the 
> directive to copy an interface (method, inner type, property, or conformed-to 
> protocol) from the underlying type to the current type for synthesis too. The 
> only problem would be backward compatibility; once added, we would urge users 
> to explicitly list “publish Equatable” for synthesis, but what about code 
> that already uses the implicit version (since this feature will probably be 
> released for at least one Swift version by the time strong type-aliases 
> happen), do we force users to change their code?

I would rather no code at all use the implicit version; one of my points is 
that it's not something that's easily changed after the fact, which is why it 
needs to be done correctly now.

I'm open to any method that makes opting in to the synthesised conformance 
explicit; I still think a specifically named protocol is the simplest, but I'm 
not married to that as a solution; attributes, keywords etc. are all fine too, 
whatever is the easiest way to opt-in to the behaviour explicitly without 
ambiguity. I'm not 100% sure exactly what you mean by "add a command within the 
definition block", or is an attribute/keyword what you meant?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de> wrote:
>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>> For me the whole point of a basic protocol is that it forces me to implement 
>> some requirements in order to conform; I can throw a bunch of protocols onto 
>> a type and know that it won't compile until I've finished it, developers get 
>> distracted, leave things unfinished to go back to later, make typos etc. 
>> etc. To me declaring a conformance is a declaration of "my type will meet 
>> the requirements for this make, sure I do it", not "please, please use some 
>> magic to do this for me"; there needs to be a clear difference between the 
>> two.
> 
> My conclusion isn't as pessimistic as yours, but I share your objections: 
> Mixing a normal feature (protocols) with compiler magic doesn't feel right to 
> me — wether it's Equatable, Hashable, Codable or Error.
> It's two different concepts with a shared name*, so I think even 
> AutoEquatable wouldn't be the right solution, and something like #Equatable 
> would be a much better indicator for what is happening.
> 
> Besides that specific concern, I can't fight the feeling that the evolution 
> process doesn't work well for proposals like this:
> It's a feature that many people just want to have as soon as possible, and 
> concerns regarding the long-term effects are more or less washed away with 
> eagerness.
> 
> - Tino
> 
> * for the same reason, I have big concerns whenever someone proposes to blur 
> the line between tuples and arrays

Agreed. To be clear though; in spite of my pessimism this is a feature that I 
do want, but I would rather not have it at all than have it implemented in a 
way that hides bugs and sets a horrible precedent for the future.

I realise I may seem to be overreacting, but I really do feel that strongly 
about what I fully believe is a mistake. I understand people's enthusiasm for 
the feature, I do; I hate boilerplate as much as the next developer, but as you 
say, it's not a reason to rush forward, especially when this is not something 
that can be easily changed later.

That's a big part of the problem; the decisions here are not just about 
trimming boilerplate for Equatable/Hashable, it's also about the potential 
overreach of every synthesised feature now and in the future as well.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 18:04, Chris Lattner <clatt...@nondot.org> wrote:
>> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On 17 Aug 2017, at 11:42, Robert Bennett <rltbenn...@icloud.com 
>>> <mailto:rltbenn...@icloud.com>> wrote:
>>> 
>>> Chris mentions that the intent was to mimic a default implementation in a 
>>> constrained protocol extension, with one extension per type that doesn’t 
>>> define its own ==/hashValue while conforming to Equatable/Hashable. 
>>> Constrained extensions are allowed to use type information from the 
>>> constraint, so I don’t think there is an issue here.
>> 
>> And I disagree; this isn't a constraint extension either, not even close, 
>> we're talking here about automatic behaviour based upon variables the 
>> protocol knows literally nothing about, in a way that can result in new 
>> errors that are currently impossible (as you can't currently conform to 
>> Equatable without providing some kind of code to implement it).
> 
> I understand and recognize your concern.  Your points are apply equally to 
> the default implementation of the Codable protocols as well, and the core 
> team specifically discussed this.
> 
> Also, if I were to nitpick your argument a bit, it isn’t true that the 
> protocol knows “nothing" about the type anyway, because the protocol has 
> access to self.  The default implementation could conceptually use reflection 
> to access all the state in the type: we’re producing the same effect with 
> more efficient code.

Parts that the protocol specifically defines are fine, I've said as much; the 
part I object to is everything else as the issue here is that the protocol must 
make assumptions about the concrete type and I find that dangerous, especially 
on an existing protocol. I would argue that any default implementation using 
reflection to do the same is likewise flawed unless the behaviour is very 
carefully and very clearly defined as part of a contract that developers are 
explicitly opting in to.

But that's not what's happening here; Equatable is an existing and well 
understood protocol and you are proposing to change it arbitrarily to suddenly 
imply functionality that doesn't currently exist and which has the potential to 
introduce bugs.

I have seen not one shred of justification why this feature must be implicit 
through Equatable except that Codable does it, and frankly I don't find that 
even close to acceptable as a precedent at all as Codable is not preexisting, 
and personally I don't like it in Codable's case either, and wasn't aware of 
the discussion around it. But for Equatable we're talking about a preexisting 
protocol that will today catch 100% of missing conformance bugs, being changed 
such that that is no longer the case because of a default behaviour that will 
hide such bugs by making potentially flawed assumptions about a concrete type.

Frankly, setting a precedent for this kind of automated background reflective 
guesswork on basic protocols is a horrifying prospect to me, even more so if it 
is being introduced arbitrarily on existing protocols. At least with things 
like unit testing that reflect test methods the rules are clearly known from 
the outset (i.e- there's a clear naming convention for what is reflected, 
everything else is the developer's domain, you opt-in by following that naming 
convention), this is not the case here.

And what exactly is the burden from opting in explicitly? A different protocol 
name, a keyword or an attribute are not going to trouble developers, and will 
clarify exactly what they intended without hiding bugs. This is why I feel this 
hasn't been considered sufficiently at all, as no justification is given why 
"AutoEquatable" or whatever is somehow an unacceptable burden to clarify what a 
developer actually wanted.

For me the whole point of a basic protocol is that it forces me to implement 
some requirements in order to conform; I can throw a bunch of protocols onto a 
type and know that it won't compile until I've finished it, developers get 
distracted, leave things unfinished to go back to later, make typos etc. etc. 
To me declaring a conformance is a declaration of "my type will meet the 
requirements for this make, sure I do it", not "please, please use some magic 
to do this for me"; there needs to be a clear difference between the two.

This is an overreach, plain and simple. While it may seem small, I would 
frankly rather go back to coding everything in C++ than continue using Swift if 
this is to be the direction of travel, as there's a big a difference between 
convenience and trying to guess what a developer wanted. Cutting down on 
boilerplate is a fine 

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 11:42, Robert Bennett  wrote:
> 
> Chris mentions that the intent was to mimic a default implementation in a 
> constrained protocol extension, with one extension per type that doesn’t 
> define its own ==/hashValue while conforming to Equatable/Hashable. 
> Constrained extensions are allowed to use type information from the 
> constraint, so I don’t think there is an issue here.

And I disagree; this isn't a constraint extension either, not even close, we're 
talking here about automatic behaviour based upon variables the protocol knows 
literally nothing about, in a way that can result in new errors that are 
currently impossible (as you can't currently conform to Equatable without 
providing some kind of code to implement it).

It is no more comparable to a constrained extension than it is to a default 
implementation, as it is neither of these things; both of those are well 
defined by their very nature, this instead is utterly arbitrary. There is no 
justification that will make that any less true.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 10:38, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> This is a small pitch which I will abandon if there is not much appetite for 
> such improvement. ;)
> 
> I would like to propose an improvement to an initializer of all collection 
> types that provide: init(repeating repeatedValue: Element, count: Int).
> 
> This change is meant to support reference type initialization on each 
> iteration of the internal for-loop rather than copying the same references n 
> times.
> 
> The change would be really straightforward and should not break existing 
> code, except that the behavior would change for class types.
> 
> Instead of:
> 
> init(repeating repeatedValue: Element, count: Int)
> 
> let threeViews = Array(repeating: UIView(), count: 3) // contains 1 view 3 
> times
> we would have:
> 
> init(repeating repeatedValue: @autoclosure () -> Element, count: Int)
> 
> This simple change would allow us to construct an array of different objects 
> instead of an array with n references to the same object.
> 
> let threeViews = Array(repeating: UIView(), count: 3) // contains 3 different 
> view
I don't think that changing the existing initialiser is the way to do this, as 
it's not really clear here that the UIView() will be instantiated multiple 
times rather than the same reference copied multiple times. The copying 
behaviour is in fact desirable as it will be significantly faster, especially 
with very large arrays.

I think the better way to achieve this might be add some closure-based sequence 
that returns a closure's result N times, so we could do something like this:

let threeViews = Array(Repeat(count: 3) { return UIView() })

i.e- we would initialise Array from a sequence returning a new UIView three 
times. While we could also do an array initialiser with closure, using a 
separate type is probably the cleaner way to do this.

There is already a Repeater type, but this just does the same as the array 
initialiser already does, could be another type I've missed that might do what 
is needed, otherwise it seems to require types like AnyIterator with some 
counting code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution 
>  wrote:
> 
> How do unstable hash values play with Codable? If you encode and save a Set, 
> might you have problems interacting with it in the future? (This is more a 
> Codable question than Hashable, but I figure I might as well ask here) 

I'm not big on the specifics of Codable, but collections are usually a case 
where you need to be careful about how exactly you encode them; i.e- you 
usually only want to encode the length and the contents, not anything related 
to the way in which they are actually stored. This way it doesn't matter if the 
hashes change, as you recreate the Set like you're adding all the values for 
the first time; any collisions should then be resolved as normal (i.e- 
assigning into buckets of non-identical items with the same hash). Nothing in a 
Set should ever be overwritten on the basis of its hash alone. Otherwise, any 
code that requires a more stable hash value should be using something other 
than Hashable to generate it.

> On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution 
>  wrote:
> 

> The code synthesized is meant to feel like a default implementation that 
> you’re getting for free from a (constrained) extension on the protocol.  This 
> is why conformance to the protocol itself is all that is required, not 
> something like “AutoEquatable”.  


I still strongly feel that treating this like a default implementation is a 
mistake, especially in the case of Equatable; we are literally talking here 
about a feature that introduces the potential to hide bugs, and it is not the 
same as a default implementation, not at all as it uses details of the concrete 
type, rather than merely what is defined within the protocol itself, you are 
talking here about using parts of a type that are not clearly defined, to 
create an implementation that by its very nature must give accurate results.

I mean, the whole point of a protocol is to define what we as developers need 
to do in order to ensure correct behaviour; when we start talking about 
providing that behaviour automatically with behind the scenes magic that 
necessarily has to make assumptions about a type then you lose any ability to 
guarantee correctness. I feel so strongly that this is a mistake that I would 
rather never see this feature implemented than see it implemented in this way, 
and feel that this concern has been trivialised and ignored.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 10 Aug 2017, at 23:29, Brent Royal-Gordon  wrote:
> 
> If the only difference were whether the default implementation was generated 
> by a macro or not, would you still think auto-derivation should be marked 
> with a keyword?

Yes.

With or without a macro the issue here is still that the synthesised behaviour 
is generated based upon assumptions about a concrete type, whereas current 
default implementations are only based upon the methods/properties that are 
defined by the protocol itself, i.e- if the protocol is well-defined, and you 
implement it accordingly, then all a default implementation should be doing is 
correctly using the protocol. The problem with the synthesised behaviour is 
that it must necessarily make assumptions about parts of the concrete type that 
are not defined by the protocol and may in fact have nothing to do with it at 
all (e.g- could be properties implementing an entirely different protocol).

Whether or not this is generated by a macro is not the issue. If we assume 
macros will eventually replace features like this one, then I would still want 
a clear standard on how to distinguish between opting in to synthesised 
behaviour such as this.


To be clear as well; I didn't specifically request a keyword. In fact I'm 
leaning more towards separate protocols personally; i.e- if you just want to 
adopt the requirements you would conform to Equatable, but if you want to use 
the synthesised behaviour you would instead conform to AutoEquatable (or some 
similar naming convention). The important distinction here being that simply 
conforming to Equatable will still give you all the usual errors for failed 
requirements, at which point you can either fulfil them, or switch to 
AutoEquatable instead if you prefer.

This kind of standard would make sense for any protocol that wants to add 
default implementations that are "invasive", i.e- delve deeper into the 
concrete type than simply what the protocol itself defines as possible, i.e- 
behaviours that by their very nature must make assumptions about the concrete 
type. This might be fine for a protocol that is clearly defined as having such 
behaviour from the start, but personally I'd rather see a standard set that has 
it split off into a more specific protocol, such that we still have "pure" 
protocols which remain primarily as a set of requirements.

In other words, Equatable would contain all the basic requirements and the "non 
invasive" default implementations, while AutoEquatable would extend it with the 
macros/special behaviour that provides the synthesised defaults, allowing a 
developer to opt-in to them explicitly.

> On 10 Aug 2017, at 16:19, Tony Allevato  wrote:
> 
> I disagree that @transient is crucial for this feature to work—that feature 
> only applies to the set of types that contain volatile data, that volatile 
> data and all the other fields are all Equatable/Hashable, and the user wants 
> to synthesize Eq/Hash for a subset of its fields. I certainly agree that such 
> a set is non-empty, but I it's also small enough that it can be considered at 
> a later date.

I disagree with your reasons for disagreeing 

The problem is that synthesising the behaviour for such types right now will 
introduce a bug, and one that will not be exposed to developers except at 
runtime, which is something that makes me very uncomfortable. To be clear, my 
point is that a transient feature is a requirement now specifically because the 
proposal seeks to use conforming to Equatable as sufficient as an opt-in; if a 
more explicit opt-in were required then this would not be an issue, i.e- if a 
developer conforms to AutoEquatable instead of Equatable, then we can assume 
that they should know what that means, and should not do it unless they know 
their type contains no transient values.

With that kind of absolutely explicit opt-in then, yes, a @transient attribute 
or whatever can be deferred to a future feature. But with opt-in via Equatable 
conformance the lack of such a feature is much more pronounced. Though like I 
say, my preference is very much towards a more explicit opt-in, rather than an 
attribute/keyword that developers may not realise they need to use with regular 
Equatable (remember, not everyone will know that Equatable is gaining this new 
behaviour).

> I sympathize with these concerns, and a great deal of thought and discussion 
> was done around the best way to surface this feature in the last couple of 
> mailing list threads about this topic. But at the time this proposal and its 
> implementation were written, the synthesis for Codable had already been 
> implemented and this proposal adopts the same synthesis conditions that were 
> used by Codable. Core team members expressed that the implementation for 
> Eq/Hash should follow those existing practices as closely as possible; I 
> agreed that consistency is important so that we don't have to 

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 10 Aug 2017, at 10:32, Martin Waitz <t...@admingilde.org> wrote:
> 
> Hi Haravikk,
> 
> Am 2017-08-10 11:07, schrieb Haravikk via swift-evolution:
>> I don't feel that conforming to
>> Equatable/Hashable is sufficient as an opt-in. Consider for example
>> someone who declares their type as Equatable/Hashable, then sets to
>> work on the details of their type, forgetting to implement the actual
>> equatable/hashable behaviour they want.
> 
> This is no different than a default implementation of the protocol.
> In fact, the proposal just adds something like this:
> 
>extension Struct<A, B, ...>: Equatable where A: Equatable, B: Equatable, 
> ... {
>static func ==(lhs: Self, rhs: Self) -> Bool { /* insert 
> implementation here */ }
>}
> 
> We don't require/support some special keywords for other protocols with 
> default implementation either,
> so I see no reason to add them here.
> 
> Your concerns are orthogonal to this proposal and should be discussed 
> independently.

I disagree.

This is not the same as a default protocol implementation, as a default 
implementation can only act upon properties/methods that are clearly defined by 
the protocol itself. This feature by comparison is an automatic implementation 
that by design must make assumptions about the contents of a concrete type.

Consider a type that contains some kind of "volatile" data, i.e- properties 
that are not necessarily crucial to the type, and so should not be considered 
during equality. If I make a mistake and end up using the synthesised test for 
equality, then two values that should be identified as equal, will not be 
equated as such because the synthesised option cannot account for 
implementation details that it has no awareness of.

This has come up in discussion in the past, where I argued for some means of 
marking values to prevent them from being included in the synthesised 
method(s). This is covered in alternatives as "transient" values, but I 
disagree with the conclusion that this can simply be added later, as it is IMO 
crucial to the way this feature would work. Even if there were a @transient 
attribute or whatever from the start, I'd still prefer to set this within the 
context of having explicitly asked for Equatable/Hashable to be synthesised, 
and without such a feature it only makes it more crucial that the opt-in occur 
in a manner more explicit than conforming to Equatable/Hashable.

My disagreement pretty much boils down to the fact that I do not feel that 
opting in simply by conforming is sufficient given that the desired behaviour 
is assumed; I strongly feel that a more explicit declaration of "I specifically 
want to use this automatic behaviour" is required, either via attribute or 
conforming to a more explicit protocol.

I actually like the fact that conforming to Equatable requires me to implement 
==, as it ensures that I do-so, and prefer that that behaviour remain, as it 
forces me to do something about it. Even with synthesised behaviour as an 
option, it should be exactly that, an option; i.e- when my conformance to 
Equatable fails, I can choose either to implement ==, or opt-in to an automatic 
substitute.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 10 Aug 2017, at 00:08, Chris Lattner via swift-evolution 
>  wrote:
> 
>   • What is your evaluation of the proposal?

Generally positive, but I don't feel that conforming to Equatable/Hashable is 
sufficient as an opt-in. Consider for example someone who declares their type 
as Equatable/Hashable, then sets to work on the details of their type, 
forgetting to implement the actual equatable/hashable behaviour they want.

I would suggest either that there be a keyword/attribute to indicate when the 
synthesised solution be used, or that there be alternate protocols such as 
AutoEquatable and AutoHashable; the idea being that the more explicit 
declaration results in the synthesised behaviour, or produces errors if it 
isn't possible or if a custom implementation is provided. An advantage of these 
methods is that the synthesis could potentially then be allowed for extensions 
(unless there's some other reason they aren't?), since they're absolutely 
explicit in what they want.

I'm just wary of these being implemented automatically cases where someone 
forgets to do it themselves, or if they accidentally define the requirements 
incorrectly (e.g- they provide a hash_value property instead of hashValue). I 
think for this to count as opt-in behaviour the developer should be 
specifically opting in to synthesised implementations, rather than just 
declaring conformance as normal and having it kick-in in certain circumstances.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

While it's a somewhat minor problem, it does commonly involve a lot of 
boiler-plate where it can also be easy to introduce mistakes. So I do feel a 
change is warranted.

>   • Does this proposal fit well with the feel and direction of Swift?

Other than the means of opting in I'd say so, yes.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick re-read of the proposal, otherwise been following discussion for a while.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Change 'for in' expression to for [] { (item) in ... }

[Haravikk via swift-evolution]

> On 28 Jul 2017, at 17:19, Kwanghoon Choi via swift-evolution 
>  wrote:
> 
> Hello
> 
> I found someone easy mistake using for in loop statement.
> 
> Ex)
> var i = 0
> for i in 0..<10 { }
> print(i)
> 
> And this user expected print(i) is “10”
> 
> Many experienced swift developers doesn’t misunderstand like this. But always 
> someone is new comers, and I think this expression make misunderstand easy 
> too.
> 
> So why not like this?
> 
> var I = 0
> for 0..<10 { (i) in … }
> 
> I think this is more understandable for loop expression. 
> 
> Best Regards
> 
> - Jay Choi

While I sympathise with the intent, I think this is the wrong solution; it 
would be better to work towards eliminating some of the more common uses of 
shadowing (e.g- let x = x conditional binding) so that we could justify adding 
potentially accidental shadowing as a warning instead. Either that or just add 
shadowing as a warning by default, and maybe make a few exceptions where none 
will be raised.

Personally I avoid single character variable names except where they are part 
of a formula or such; makes for more verbose code, but that's not necessarily a 
bad thing, as it's usually clearer exactly what the variables are for as a 
result, at least when I can think of a good name.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

[Haravikk via swift-evolution]

> On 21 Jul 2017, at 21:04, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> This is a thread to formally _review_ certain changes, not a thread to “talk 
> about” revisions generally.

To review means to assess or reconsider; even if a new review is only triggered 
by specific changes, the proposal still needs to be considered as a whole, and 
I think it's perfectly fine to revisit earlier points, especially if a person's 
thoughts on those points is part of their assessment of the proposal.

If people have issues with a proposal that a new revision still doesn't 
address, then I think it's perfectly fair to repeat them, as what was true of 
the previous version remains true in such cases.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ability to derive a class from a struct or other value type

[Haravikk via swift-evolution]

> On 23 Jun 2017, at 16:20, Mike Kluev  wrote:
> 
> on Fri Jun 23 05:26:11 CDT 2017 Haravikk swift-evolution at haravikk.me 
>  wrote:
> 
> > Not sure what you mean by added indirection here, the following seems 
> > perfectly straightforward to me:
> > 
> > protocol Foo {
> > var someValue:Int { get set }
> > func a() -> Any?
> > }
> > 
> > extension Foo {
> > func a() -> Any? { return self.someValue }
> > }
> > 
> > struct ValueSemantics:Foo { var someValue:Int }
> > class ReferenceSemantics:Foo {
> > var someValue:Int { return nil }
> > }
> > 
> > There is no added access overhead here, the only difference is that the 
> > protocol itself leaves it up to 
> > implementations whether someValue is stored or computed.
> 
> in real cases there would be more variables:
> 
> //
> protocol P1 {   // #noise
> var var1: Int { get set }   // #noise
> var var2: Int { get set }   // #noise
> // ...  // #noise x 100
> var var100: Int { get set } // #noise
> 
> func foo1() -> Int  // #noise
> func foo2() -> Int  // #noise
> // ...  // #noise x 100
> func foo100() -> Int// #noise
> }
> 
> extension P1 {  // #noise
> func foo1() -> Int { return var1 * 2 }
> func foo2() -> Int { return var2 * 2 }
> // ...
> func foo100() -> Int { return var100 * 2 }
> }
> 
> struct S1: P1 {
> var var1: Int   // #noise
> var var2: Int   // #noise
> // ...  // #noise x 100
> var var100: Int // #noise
> }
> 
> class C1: P1 {
> var var1: Int = 0   // #noise
> var var2: Int = 0   // #noise
> // ...  // #noise x 100
> var var100: Int = 0 // #noise
> }
> //
> 
> 
> lots of noise and violations of DRY. you may try to mitigate it by putting 
> all those storage into another struct, that was the indirection i was 
> thinking about:

Maybe, but the whole point of the protocol is that it's a contract, it's up to 
the implementing types how the properties are actually stored (if at all); in 
that respect it's not noise, as it's necessary.

The shorthand you're proposing is effectively masquerading delegation as 
extension; I'm not sure making it look like extension is the right way to go, 
but delegation is absolutely something I support, just not in this style.

Currently there is a lot of boilerplate around things like type-erased 
wrappers, where you might get a class that looks like:

class MyWrapper:Foo {
struct foo:S

func someMethodOfFoo() { foo.someMethodOfFoo() }
func someOtherMethodOfFoo() { foo.someOtherMethodOfFoo() }
}

It's the same basic problem, except that I don't necessarily want everything to 
be implemented by my enclosed struct. This is why I'd prefer a solution that's 
more explicit about the fact that there's delegation going on, and more 
flexible about how things are delegated. This is what I mean:

protocol Foo {
var someValue:Int { get set }
func someMethod() -> Int
}

struct ValueType:Foo {
var someValue:Int
func someMethod() { return self.someValue }
}

class ReferenceType:Foo {
var foo:ValueType implements Foo // This is the important bit
}

It's got one extra step, but is explicit that there's delegation involved, and 
without suggesting some kind of hierarchy that doesn't exist. In this case 
ValueType needn't even conform to Foo at all, just as long it has properties 
and methods that are a match; in this way we could potentially conform to Foo 
using multiple delegates that each implement a little bit of the protocol.

Another possible syntax is:

class ReferenceType:Foo {
delegate(Foo) var foo:ValueType
}

This may be slightly better as it explicitly references to delegation, but it's 
the same idea; in the brackets you put one or more types, or members of types, 
that the property is a delegate for.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ability to derive a class from a struct or other value type

[Haravikk via swift-evolution]

> On 22 Jun 2017, at 22:28, Mike Kluev via swift-evolution 
>  wrote:
> 
> On Wed, 21 Jun 2017 15:04:46 David Moore  > wrote:
> 
> > This would be a bit counter-intutivie in my opinion, and it’s already 
> > possible 
> > with the language today. First of all, structs in Swift cannot be built 
> > upon. 
> > Rather, I believe the intention is to use protocols for such a task. That’s 
> > what 
> > the new Swift String and Substring structs do. The following code example 
> > demonstrates the intended behavior, without any additional language 
> > improvements.
> > 
> > protocol Foo {
> > func a() -> Any?
> > }
> > 
> > extension Foo {
> > func a() -> Any? {
> > return nil
> > }
> > }
> > 
> > struct ValueSemantics: Foo {}
> > 
> > class ReferenceSemantics: Foo {}
> 
> while you can use protocols, and protocol extensions specifically, to share 
> implementation there are two obvious problems with this "workaround":
> 
> 1) protocol extensions' based implementation is very limited as you have no 
> storage around. e.g. start with a normal struct method that accesses an 
> instant variable and try to refactor it into a protocol extension... in other 
> words try doing anything useful other than "return nil" above, anything that 
> requires instance variable access. you'll have to be creative in your 
> protocol implementation, e.g. have a "var storage { get set }" as part of the 
> protocol and implement that "var storage" inside your struct (and class), and 
> in case of "struct" it would be strange as the struct itself is (already) the 
> storage, so you would introduce another level of indirection for no good 
> reason other than to satisfy this workaround, which is not nice to begin with 
> and has to be thought upfront (see below)

Not sure what you mean by added indirection here, the following seems perfectly 
straightforward to me:

protocol Foo {
var someValue:Int { get set }
func a() -> Any?
}

extension Foo {
func a() -> Any? { return self.someValue }
}

struct ValueSemantics:Foo { var someValue:Int }
class ReferenceSemantics:Foo {
var someValue:Int { return nil }
}

There is no added access overhead here, the only difference is that the 
protocol itself leaves it up to implementations whether someValue is stored or 
computed.

> 2) the proposed method works with value types that are already available 
> (e.g. the OS structs or third party ones) - something you can not change but 
> still want to wrap into a reference type.

This sounds to me more like delegation support that's required, which is 
something that I would like to see for reducing boilerplate. But I'd prefer to 
see something like:

struct Foo:SomeProtocol { var someValue:Int }
class Bar:SomeProtocol, SomeOtherProtocol {
var foo:Foo implements SomeProtocol, 
SomeOtherProtocol.someMethod
// Implements all of SomeProtocol, some of 
SomeOtherProtocol
}

Note that's not a specific proposal for syntax, the important point here is 
that I'm explicitly linking my stored property foo to implementation of a 
protocol, telling the compiler to automatically use foo's properties/methods to 
conform to SomeProtocol by default (but leaving me free to customise).

I don't think that masking the behaviour behind something that looks like 
extension is a good idea, for this reason I prefer explicit delegation. But 
like I say, I'm not 100% on my preferred syntax for it, I just think it should 
be its own, distinct feature rather than potentially fooling people into 
thinking they're extending a struct.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] In-line scope designators

[Haravikk via swift-evolution]

> On 19 Jun 2017, at 21:40, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Jun 19, 2017, at 11:45, Robert Bennett via swift-evolution 
>>  wrote:
>> 
>> +1 for member variables, -1 for member functions. Functions take up too much 
>> vertical space to make this convenient; 
> 
> Yeah, I think that really only made sense in the world of header files, where 
> function declarations were only one line each.
> 
> Off the top of my head, I wouldn't oppose it for non-computed properties, 
> though.

Wouldn't a load of restrictions make it more complex to implement? I would say 
that if the feature was to be implemented it should just work for everything; 
this makes it a lot simpler to implement and just leaves it up to developers to 
decide where it is most appropriate to use it.

After all, very simple computed properties, lazy values and other functions can 
be written on a single line if you really want to do it, so it seems like this 
feature would be just as useful for those as well.

I'd probably keep them limited to type declarations though; i.e- not in 
extensions, since they can already declare visibility (except extensions for 
conformance, which imply a visibility).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution 
> > wrote:
> Sorry, initially sent off-list:
> 
> I think this proposal is a great idea. But I would vote for the alternative 
> of only having default and implicitly deducing extend when default is not 
> specified:
> 
> This wouldn't work with the fundamental design decision that these are 
> optional keywords, which IMO is absolutely key.

Hmm, I'm inclined to agree with David that only the default keyword really 
seems like it's necessary, and that extend can be implied.

My preference would be to just add the default keyword, and have breaches 
treated as warnings using the current behaviour, which we can eliminate and 
elevate to an error in future once people have had a chance to change their 
code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 11 Jun 2017, at 22:13, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> I agree, this makes focusing on the right types of changes much easier and 
> helps us avoid turning Swift into an incoherent conglomeration of random 
> use-cases (*cough*, C#, *cough*).
> Now, the question is: when will be the time to officially push the factory 
> initializers proposal and which stage should it be targeting?

I think there's definitely a need for greater clarity; we could really do with 
better announcements on the list itself as to when the new phase begins and 
exactly what is in-scope, it also needs to be put more clearly on the 
swift-evolution repository.

Thing is; people are going to have ideas when they have them, and want to 
discuss them right away. I've been caught out numerous times with proposals 
that are almost immediately rejected as out of scope, and still have no idea 
when I'm supposed to resubmit them.

To be honest it's demoralising, as I find myself apathetic towards my own ideas 
as I have no idea when to revisit them, and by the time I do I've largely lost 
interest and moved on to other things.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

[Haravikk via swift-evolution]

> On 10 Jun 2017, at 13:33, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> _Every_ addition to the basic syntax of the language is, by definition, high 
> cost. The bar for additions to the standard library is already very high; the 
> bar for additions to control flow syntax would be extraordinarily high.
> 
> The proposed use case here is far from the original topic of repeat {} while, 
> which is unique because the condition lexically follows the loop.
> 
> For those loops in Swift where it is possible to declare variables in the 
> condition, these live in a magical middle scope that is intuitive to use but 
> also an exception to the rule of thumb that scopes are surrounded by braces. 
> As I wrote earlier, it is possible to manually create an analogous scope by 
> surrounding any loop with do {}. Any addition to the language would have to 
> be vastly superior to this currently possible alternative, and I seriously 
> doubt it is possible to invent such a thing because anything shorter than the 
> four letters in “do {}” would also obscure the existence of the middle scope 
> being created.

The problem with nesting within do {} blocks is that it actually makes the 
problem worse; the main benefit of being able to declare the variables more 
conveniently is to eliminate common boiler-plate around loops. Creating them 
with a limited scope is a useful bonus (and further reduces clutter/name 
pollution).

On the issue of tackling boilerplate, consider something like the following:

// Remove the first 100+ units of items and store the names in an array
var theNames:[String] = []
do {
var theTotal = 0
while let eachItem = theIterator.next() {
theNames.append(eachItem.name)
theTotal += eachItem.value
if theTotal >= 100 { break }
}
}

With the ability to specify throwaway variables more easily, I'm sticking with 
my using syntax here:

var theNames:[String] = []
while let eachItem = theIterator.next() using (var theTotal = 0) where 
(theTotal < 100) {
theNames.append(eachItem.name)
theTotal += eachItem.value
}

Depending upon your preference on how to structure the using and where parts 
this is shorter and easier.


In terms of purely creating throwaway variables, it could be condensed a bit 
further if we stole anonymous variables from the closure syntax like so:

var theNames:[String] = []
while let eachItem = theIterator.next() using $0 = 0 where $0 < 100 { // $0 is 
created for this block only
theNames.append(eachItem.name)
$0 += eachItem.value
}

In other words, we'd treat $0 = 0 as a shorthand for var foo = 0 on the basis 
that it's being used for a limited scope (i.e- it's always an initialisation 
within the using clause, rather than an assignment). This should be consistent 
with closures on the basis that closures have implicitly created the variables 
for you.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

[Haravikk via swift-evolution]

Not sure if my e-mail didn't go through or if discussion just fizzled out; one 
other benefit if we ever move to a proper message board is we might gain the 
ability to bump topics. Anyway, I'll resend my message just in case:



Just to add my thoughts, as I like the idea of adding the variables to the 
start somehow, but was wondering if might make sense to have a keyword such as 
"using", but allow it on all block statements, like-so:

// Original use-case of repeat … while
repeat using (var i = 0) {
// Do something
} while (i < 20)

// for … in demonstrating combination of using and where
for eachItem in theItems using (var i = 0) where (i < 20) {
// Do something either until theItems run out or i reaches 20
}

// Standard while loop
while let eachItem = it.next() using (var i = 0) where (i < 20) {
// As above, but with an iterator and a while loop and 
conditional binding to also stop on nil
}

// Closure with its own captured variable
let myClosure:(Int) -> Int = using (var i = 0) { i += 1; return i * $0 }

// If statements as well
if somethingIsTrue() using (var i = 0) where (i < 20) {
// Do something
}

// Or even a do block; while it does nothing functionally new, I quite 
like it aesthetically
do using (var i = 0) {
// Do something
}

Unifying principle here is that anything created in the using clause belongs to 
the loop, conditional branch etc. only, but exists outside the block itself 
(thus persisting in the case of loops and closures). I quite like the possible 
interaction with where clauses here as a means to avoid simple inner 
conditionals as well.

Basically the two clauses can work nicely together to avoid some common inner 
and outer boilerplate, as well as reducing pollution from throwaway variables.

Only one I'm a bit iffy on is the closure; I'm trying to avoid declaring the 
captured variable externally, but I'm not convinced that having using on its 
own is clear enough?

Anyway, just an idea!

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[Haravikk via swift-evolution]

> On 2 Jun 2017, at 07:38, Robert Bennett <rltbenn...@icloud.com> wrote:
> 
> My favorite proposal so far is one that was posted a while ago, [Int * 4]. I 
> think that this syntax looks pretty Swifty. There isn't an oddball subscript 
> operator like with Int[4], and there isn't a need to allow generics to 
> support values as parameters. It's clear that [Int * 4] will be array-like 
> and contain four Ints. For multidimensional arrays we could use [Int * 
> (2,3)]. For an array of tuples, [(x: Int, y: Int) * 4]. I'm not sure why 
> nested static arrays would be needed when multidimentionality is provided out 
> of the box, but presumably the syntax would support them; you would just need 
> to subscript the arrays one at a time instead of with a single subscript 
> operator, e.g., a[i][j] instead of a[i, j].
> 
> I'm imagining this syntax working like [T] does now as a shorthand for 
> Array, although I'm not sure what [Int * 4] should be short for 
> (StaticArray<Int, 4>? Vector4? ...). Constructors for static arrays 
> would be called using [Int * 4](args). I'm thinking the constructors would be 
> [T * 4](filledWith: T), [T * 4](filledBy: (Int)->T), and an initializer 
> taking a Sequence that fails in some manner on a dimension mismatch.

Even with that syntax I'd say there should be a means of handling it in a 
general purpose way.

For example, let's say you defined that syntax as an operator:

func * (lhs: T.self, rhs: Int) -> (type: T.self, size:Int) { return 
(type: lhs, size: rhs) }

Now you have an explicit tuple describing what it is you want to do, which the 
compiler can now pass to a type during compilation to do with as it pleases. In 
this case it would pass to some FixedArray type which can use the type and size 
to optimise itself. Not sure on the specifics of how just yet, but point being 
to try to make this a part of the language that others can use, rather than 
simply being some form of compiler magic.

My reasoning being that it may be useful to have other type operators in 
future, and/or other types able to take and use the same information.


For example, I briefly discussed once the possibility of a Float variant whose 
compatibility would be limited by its target precision, and use ± as an 
operator so that I could define for example:

var a:Float±0.1 = 0.5
var b:Float±0.5 = 5.0
a = b // error; precision mismatch (b's precision is too low to 
guarantee accuracy)
b = a // this is fine, as a is "more precise" than b


Now put aside whether that idea is actually useful or not; my point is that I'd 
like support for fixed-size arrays to be general purpose, as there are other 
possible uses for the same basic capabilities (i.e- type variables).

The key thing really is that we need some way for the compiler to recognise 
that a type is being refined somehow, and compile it separately as appropriate. 
I mentioned generics style variable passing because to me this is the most 
logical way to pass information into a type, not because I want it to be the 
default syntax at the call site; I fully support other shorthands for the 
actual passing of data, the key for me is being able to leverage the same kind 
of type-refining capabilities in my own types, rather than this whole thing 
just being focused solely on fixed-sized arrays implemented with compiler magic.

> On Jun 1, 2017, at 7:36 AM, Haravikk via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> Just wanted to add my two-cents to this discussion, but in terms of syntax I 
>> think that the basic method for specifying size should be with some kind of 
>> type variables, like so:
>> 
>>  struct MyFixedArray<T, size:Int> { … }
>> 
>> The idea being that we can then use size as a variable anywhere within the 
>> code for MyFixedArray, but unlike other variables it is determined at 
>> compile time, so should be optimised accordingly. As with generics, setting 
>> a type variable effectively creates a variant type so for example, a 
>> MyFixedArray<Int, size:3> and a MyFixedArray<Int, size:4> would no longer be 
>> directly compatible as they may differ internally.
>> 
>> This would be useful not just for fixed arrays, but other possibly type 
>> variations as well. Ideally it should be possible to specify a default value 
>> for type variables; while this wouldn't be useful for fixed arrays, it may 
>> be useful for other type variants.
>> 
>> To better suit the specific use-case of arrays, we could also add some 
>> useful attributes or keywords, for example, reusing subscript could give us:
>> 
>> struct MyFixedArray<T, subscript size:Int> { … }
>> let foo:MyFixedArray[4

Re: [swift-evolution] Yet another fixed-size array spitball session

[Haravikk via swift-evolution]

Just wanted to add my two-cents to this discussion, but in terms of syntax I 
think that the basic method for specifying size should be with some kind of 
type variables, like so:

struct MyFixedArray { … }

The idea being that we can then use size as a variable anywhere within the code 
for MyFixedArray, but unlike other variables it is determined at compile time, 
so should be optimised accordingly. As with generics, setting a type variable 
effectively creates a variant type so for example, a MyFixedArray 
and a MyFixedArray would no longer be directly compatible as they 
may differ internally.

This would be useful not just for fixed arrays, but other possibly type 
variations as well. Ideally it should be possible to specify a default value 
for type variables; while this wouldn't be useful for fixed arrays, it may be 
useful for other type variants.

To better suit the specific use-case of arrays, we could also add some useful 
attributes or keywords, for example, reusing subscript could give us:

struct MyFixedArray { … }
let foo:MyFixedArray[4] = [1, 2, 3, 4] // with T being inferred, this is a 
shorthand for specifying a size of 4

Type variables could also be usable with generics, like-so:

// only accept fixed arrays of same or smaller size:
func myMethod(values:FA) where FA:FixedArray, FA.size <= Self.size { … } 

These are the kind of general purpose capabilities I'd like to see at some 
point, as the usefulness extends beyond just fixed-size arrays.



However, on the  subject of fixed-size arrays specifically, one other 
possibility to explore is the concept of Tuple repetition and subscripting. For 
example, it would be interesting if we could do things like:

var foo:(Int)[4] = 0 // Initialises four Ints, all set initially to zero
for i in 0 ..< 4 { foo[i] = i } // values are no 0, 1, 2, 3

This can be especially interesting when you get into more complex tuples like 
so:

var bar:(x:Int, y:Int)[10] = (x: 0, y: 0) // Initialises 10 pairs of 
Ints, all initially set to zero
for i in 0 ..< 10 { bar[i].x = i; bar[i].y = i } // here we need to use 
.x and .y to access the values of each pair

Of course this would have the same performance characteristics as standard 
tuples, but it's an interesting means for creating quick, fixed-size arrays in 
a flexible way. Part of the idea here is that by subscripting tuples, we avoid 
the need for a general subscript on all types, keeping that available for 
use-cases like the above.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Haravikk via swift-evolution]

> On 26 May 2017, at 20:35, Robert Bennett via swift-evolution 
>  wrote:
> 
> On the contrary I think the solution can absolutely be to break other code. 
> Allowing no parentheses is not a very useful shorthand -- it only saves two 
> characters -- and with SE-0110 actually obscures the logic. Always requiring 
> parentheses makes it clear that "{ (arg) in ..." can be replaced with "{ 
> ((key, value)) in ..." when arg is a 2-tuple; the outer parentheses denote an 
> argument list, and anything inside them is the argument, consistent with 
> other parts of the language. Allowing "{ arg in ..." but not "{ (key, value) 
> in ..." is sure to leave some people scratching their heads because "{ arg in 
> ..." suggests that it is arguments that are passed to closures (as is the 
> case with functions) and not tuples. The correctness of "{ arg in ..." relies 
> too heavily on the equivalence between a 1-tuple and a single element, an 
> equivalence that does not hold for higher arities.
> 
> I'm not *too* strongly wed to this, though. I care much more strongly about 
> allowing  "{ ((key, value)) in ..." than prohibiting  "{ arg in ...". I only 
> brought up the latter to try to improve the consistency of the language and 
> to make clear that  "{ ((key, value)) in ..." is the correct way of achieving 
> the old style "{ (key, value) in …"

I seem to recall arguing the same with SE-0110, and still hold the same belief; 
requiring the parenthesis avoids a lot of ambiguity when dealing with tuples, 
and it's an easy migration to make (Xcode can just add parenthesis to all 
closures). For code that isn't migrated, syntax errors should crop up naturally 
anywhere the arguments and closure type no longer match.

I still absolutely believe it's the right call; while closures aren't defined 
quite the same as functions, that's no reason not to have *some* consistency. 
There's possibly an argument to make for omitting the brackets on a simple, 
single parameter closure, but other than that I think it's better to be 
explicit in all cases.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Implicit truncation

[Haravikk via swift-evolution]

This is getting too muddled, so I'm going to summarise thusly; I believe the 
principle the OP raised is sound, that any initialiser performing a lossy 
conversion from another type should be clear that this happening, and that a 
label can do that best, as it makes the conversion self-documenting at the 
call-site.

Consider for example; with type-inference it's not always obvious what the type 
of a variable is, and an unlabelled initialiser does nothing to help, like-so:

var someValue = someMethod()
…
var someInt = Int(someValue)

At a glance it's not all obvious what is happening to someValue here; in fact 
I'd argue that this looks like a lossless conversion, requiring you to find out 
that someMethod() returns a Float before you can know for sure what's really 
going on. Whereas the following is more clear:

var someValue = someMethod()
…
var someInt = Int(truncating: someValue)

It may not communicate everything that's happening, but at least now it's clear 
at a glance that something is happening, and the term truncating suggests that 
something is being lost/removed from someValue.

Now I don't really care if truncating is the best term for it or not, though I 
do still think it is and won't change my mind on that; the key thing here is 
that it's providing that extra safety to developers by making it clear that an 
important conversion is taking place, and this to me is more consistent with 
other initialisers on Int etc. where distinctions are made between types that 
can and cannot be represented exactly.

I'm not saying it should be limited to floats either; I think any initialiser 
that cannot, or may not, represent the passed value accurately should be 
labelled for clarity. So passing an Int16 into Int32(_:) would be fine for 
example, but the reverse should not be.

It's not just an issue of new developers; experienced ones make mistakes too, 
or forget to consider whether the conversion will impact their code. A label 
helps, though I still think forcing a decision on rounding is even better, as 
both prevent a developer from simply throwing in a value in a way that may be a 
mistake.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Implicit truncation

[Haravikk via swift-evolution]

> On 22 May 2017, at 21:16, Xiaodi Wu  wrote:
> 
> 
> On Mon, May 22, 2017 at 10:39 Haravikk  > wrote:
>> On 22 May 2017, at 15:51, Xiaodi Wu > > wrote:
>> 
>> If we're to speak of intuition for new developers who've never used a 
>> programming language, who are falling back to what they know about 
>> mathematics, then quite literally a decimal point _is_ about division by ten.
> 
> I don't think this necessarily follows; the issue here is that the 
> constructor isn't explicit enough that it is simply lopping off the 
> fractional part. My own experience of maths as taught in school, to go from a 
> decimal to an integer I would expect to round,
> 
> You would also expect that 3 / 4 in integer math gives you 1. With integer 
> division, however, 3 / 4 == 0. By definition the decimal point separates an 
> integer from a fractional part, so the behaviors are inextricably linked. To 
> test this out in practice, I asked the first person with no programming 
> experience I just encountered today.
> 
> I said: "Let me teach you one fact about integers in a programming language. 
> When two integers are divided, the integer result has the fractional part 
> discarded; for example, 3/4 computes to 0. What would you expect to be the 
> result of converting 0.75 to an integer?"
> 
> He answered immediately: "I would have expected that 3/4 gives you 1, but 
> since 3/4 gives you 0, I'd expect 0.75 to convert to 0."

These are two different case; Int(3) / Int(4) is a division of integer values 
with an integer result, there's no intermediate floating point value that needs 
to be coerced back into an Int. The issue here is converse of a Float/Double to 
an Integer, it's a different operation.

3.0 / 4.0 = 0.75 is a property of Float
3 / 4 = 0 is a property of Int

What's under discussion here is conversion between the two, they're not really 
comparable cases.

> Discarding the fractional part of a floating point value is a bit pattern 
> operation only in the sense that any operation on any data is a bit pattern 
> operation. It is clearly not, however, an operation truncating a bit pattern.
> 
> as the conversion is simplistically taking the significand, dropping it into 
> an Int then shifting by the exponent.
> 
> That's not correct. If you shift the significand or the significand bit 
> pattern of pi by its exponent, you don't get 3.

I think you're misunderstanding me. If you think of it in base 10 terms 1.2345 
is equivalent to 12345 x 10-4; when you convert that to an Int it effectively 
becomes 12345 shifted four places to the right, leaving you with 1. In that 
sense it's a truncation of the bit-pattern as you're chopping part of it off, 
or at the very least are manipulating it.

Regardless it's also very literally a truncation since you're specifically 
truncating any fraction part, it's simply the most correct term to use; frankly 
I find restricting that to bit-pattern truncation to be entirely arbitrary and 
unhelpful. The types involved should make it clear whether the value is being 
made narrower or not. Int64 -> Int32 is a form of truncation, but so to is 
Float -> Int; in both cases the target can't represent all values of the 
source, so something will be lost.

>>  func init(rounding:Float, _ strategy: FloatingPointRoundingRule) { … }
>> 
>> Again, here, as an addition to the API, this fails the six criteria of Ben 
>> Cohen, as it is strictly duplicative of `T(value.rounded(strategy))`.
> 
> Maybe, but init(rounding:) is explicit that something is being done to the 
> value, at which point there's no obvious harm in clarifying what (or allowing 
> full freedom). While avoiding redundancy is good as a general rule, it 
> doesn't mean there can't be any at all if there's some benefit to it; in this 
> case clarity of exactly what kind of rounding is taking place to the 
> Float/Double value.
> 
> The bar for adding new API to the standard library is *far* higher than "some 
> benefit"; `Int(value.rounded(.up))` is the approved spelling for which you 
> are proposing a second spelling that does the same thing.

The main benefit is that the constructor I proposed would actually require the 
developer to do this, what you're showing is entirely optional; i.e- any value 
can be passed without consideration of the rounding that is occurring, or that 
it may not be as desired. With a label the constructor at least would remind 
the developer that rounding is occurring (i.e- the value may not be as passed). 
Going further and requiring them to provide a rounding strategy would also 
force them to consider what method of rounding should actually be used, 
eliminating any confusion entirely. What you're demonstrating there does not 
provide any of these protections against mistakes, as you can omit the rounding 
operation without any warning, and end up with a 

Re: [swift-evolution] Implicit truncation

[Haravikk via swift-evolution]

> On 22 May 2017, at 15:51, Xiaodi Wu  wrote:
> 
> If we're to speak of intuition for new developers who've never used a 
> programming language, who are falling back to what they know about 
> mathematics, then quite literally a decimal point _is_ about division by ten.

I don't think this necessarily follows; the issue here is that the constructor 
isn't explicit enough that it is simply lopping off the fractional part. My own 
experience of maths as taught in school, to go from a decimal to an integer I 
would expect to round, so I think it's reasonable that Swift should be clear. 
While it is reflected in the documentation, a good choice of label would allow 
it to be explicit at the point of use, without requiring a look up each time 
there is uncertainty.

>   func init(truncating:Float) { … }
> 
> Again, this particular naming suggestion has been discussed as part of the 
> review of integer protocols and not adopted. The rationale was that the term 
> "truncating" is intended to be left for bit patterns only. The term in Swift 
> is exclusively "rounded toward zero."

As I understand it truncation is a term of art from C at least (rounding toward 
zero is the trunc function I believe?), it also makes sense given that what's 
happening is that the fractional part is being discarded, regardless of how how 
high it may be. init(roundTowardZero:Float) seems like it would be very 
unwieldy by comparison just because truncating is arbitrarily reserved for bit 
operations.

Also, when it comes down to it, discarding the fractional part of a float is a 
bit-pattern operation of a sort, as the conversion is simplistically taking the 
significand, dropping it into an Int then shifting by the exponent.

>   func init(rounding:Float, _ strategy: FloatingPointRoundingRule) { … }
> 
> Again, here, as an addition to the API, this fails the six criteria of Ben 
> Cohen, as it is strictly duplicative of `T(value.rounded(strategy))`.

Maybe, but init(rounding:) is explicit that something is being done to the 
value, at which point there's no obvious harm in clarifying what (or allowing 
full freedom). While avoiding redundancy is good as a general rule, it doesn't 
mean there can't be any at all if there's some benefit to it; in this case 
clarity of exactly what kind of rounding is taking place to the Float/Double 
value.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Implicit truncation

[Haravikk via swift-evolution]

> On 22 May 2017, at 15:09, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Let's be clear: it _is_ rounded, just toward zero. It is consistent with the 
> behavior of integer division. I would guess that your students also 
> repeatedly struggle with the result that `2 / 3 == 0`? If so, they have not 
> been taught some important fundamentals of integer arithmetic. If not, then 
> it should be natural that `Int(2 / 3 as Double == Int(2 / 3 as UInt)`.

Just to add my thoughts; but while I agree that it's important developers learn 
the intricacies of Int vs. Float, I don't think this is quite the same issue as 
divisions.

If you're asking for an Int then you should have some idea that you're asking 
for a whole number only, and so that follows on to division as Ints simply 
cannot handle fractions.

However, for conversion from Float there's an expectation that some rounding 
must occur, the problem is that it's not as expected; while you or I would 
expect it to be this way with familiarity of other languages, for someone new 
to the language this isn't always going to be the case. While it's reasonable 
to expect new developers to know what an Int is, I think it's unreasonable for 
them also to remember what the default rounding strategy of an implicitly 
rounding constructor is.


For this reason I tend to agree with the principle that the Int(_:Float) 
constructor should probably be labelled more intuitively, personally I'd like 
to see:

func init(truncating:Float) { … }
func init(rounding:Float, _ strategy: FloatingPointRoundingRule) { … }

Here the init(truncating:) constructor is just a convenience form of 
init(rounding:) with a strategy of .towardZero, which I believe is consistent 
with the current behaviour. It's also easily swapped in anywhere that 
init(_:Float) etc. are currently used.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

I have to admit I've become confused by what exactly this proposal is trying to 
fix as there's a lot of talk about removing labels entirely or something? I'm 
very wary about that.

> On 5 May 2017, at 03:14, Robert Widmann via swift-evolution 
>  wrote:
> 
> let a = (x: 1, y: 2)
> var b: (y: Int, x: Int)
> b = a
However, for this specific case above I do agree that a warning should be 
added, as the implicit behaviour here could all too easily be a mistake. I 
would prefer instead the developers either manually reorder the values, and 
perhaps that an operator be added to explicitly perform automatic reordering. 
Perhaps a tilde? Like so:

let a = (x: 1, y: 2)
var b: (y:Int, x:Int)

b = a // warning
b = (x: a.x, y: a.y) // explicit, manual reordering
b = ~a // implicit, automatic reordering by label matching (still 
warns/errors on type mismatch)

As for any other changes however, I think these should be addressed in their 
own proposals as I think discussion is getting too broad and confusing IMO.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

[Haravikk via swift-evolution]

> On 25 Apr 2017, at 17:47, Douglas Gregor <dgre...@apple.com> wrote:
> 
>> 
>> On Apr 25, 2017, at 9:20 AM, Tony Allevato <tony.allev...@gmail.com 
>> <mailto:tony.allev...@gmail.com>> wrote:
>> 
>> 
>> On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> While it's good that this was accepted I still feel there could be some more 
>> discussion about whether the operators should be prefix/postfix or instead 
>> involve a more explicit declaration of one-sidedness.
>> 
>> I still would very much prefer that the operator declarations were binary 
>> and take Void as a second argument, this way there is very explicit 
>> indication that one-sidedness was requested, rather than potentially 
>> accidental; assuming many subscripts and methods that take currently closed 
>> ranges will be updated to also take one-sided ranges, the distinction is 
>> very important as a omitting one of the values could represent a mistake, 
>> and result in one-sided behaviour with unintended consequences.
>> 
>> With a Void "open" argument this would look like:
>> 
>> func ... (lhs:T, rhs:Void) -> RangeFrom { ... }
>> func ... (lhs:Void, rhs:T) -> RangeTo { ... }
>> 
>> let rangeFrom = 5 ... ()
>> let rangeTo = () ... 5
>> 
>> Not the prettiest with the Void brackets, however, if we could in future get 
>> underscore as another alias for Void we could refine this into:
>> 
>> Why would it make sense to have `_` as an alias for Void?
>>  
>> 
>> let rangeFrom = 5 ... _
>> let rangeTo = _ ... 5
>> 
>> This would have consistency with other uses of underscore that are used to 
>> indicate that something is being ignored on purpose, which I think fits this 
>> proposal very well. It would also leave the prefix/postfix ellipsis operator 
>> free for use on something else with less chance of creating ambiguity.
>> 
>> I disagree that this proposed use of the underscore is consistent with other 
>> uses.
>> 
>> The underscore is used as a pattern matching construct that means "I don't 
>> care what actual value goes here; match and allow anything and throw it 
>> away." But in the range case, not only is this not a pattern, but you also 
>> *do* care very much what value is used there—not any arbitrary value is 
>> acceptable. The value you want is the least or greatest possible value for 
>> that range.
> 
> Right; “_” is a placeholder for “don’t care”; it shouldn’t have different 
> semantic meanings in different contexts.

"Don't care" is little different to "omit", which is what is would be happening 
in the case of declaring a one-sided range. It's not a radically different 
meaning in different contexts, it's just slightly widening what it means.

>> Regardless, these ideas were brought up during the proposal's discussion and 
>> it's probably safe to assume that the core team considered them but felt 
>> they weren't a good solution.
> 
> Yes, the core team did consider the ideas around using the binary operators 
> rather than introducing the new prefix/postfix operators, and felt that the 
> proposal provided the clearest Swift code.

Can you please qualify this further? How is this clearly a one-sided range 
rather than a mistake:

let values = someArray[5...] // This one I wanted to be a one-sided 
range
let values = someArray[5...] // Scrolled up for correct endpoint to 
use, but forgot to fill it in

I just don't think that we should throw away the property whereby a range is 
incomplete until a second value or something else is given. If not an 
underscore then something else would be fine, even just the brackets that we 
have now to represent Void; omitting arguments is fine in methods and functions 
where it's still clear, but I just don't think that this is the case here, as 
this isn't a unique new operator, it's an overload of an existing one that does 
essentially the same thing but differently.

The only similar case that springs to mind is that we an exclamation both for 
negation, and force-unwrapping, but they're used at different ends to an 
argument, so it's not similar in practice.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

[Haravikk via swift-evolution]

> On 25 Apr 2017, at 17:20, Tony Allevato <tony.allev...@gmail.com> wrote:
> 
> 
> On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> While it's good that this was accepted I still feel there could be some more 
> discussion about whether the operators should be prefix/postfix or instead 
> involve a more explicit declaration of one-sidedness.
> 
> I still would very much prefer that the operator declarations were binary and 
> take Void as a second argument, this way there is very explicit indication 
> that one-sidedness was requested, rather than potentially accidental; 
> assuming many subscripts and methods that take currently closed ranges will 
> be updated to also take one-sided ranges, the distinction is very important 
> as a omitting one of the values could represent a mistake, and result in 
> one-sided behaviour with unintended consequences.
> 
> With a Void "open" argument this would look like:
> 
> func ... (lhs:T, rhs:Void) -> RangeFrom { ... }
> func ... (lhs:Void, rhs:T) -> RangeTo { ... }
> 
> let rangeFrom = 5 ... ()
> let rangeTo = () ... 5
> 
> Not the prettiest with the Void brackets, however, if we could in future get 
> underscore as another alias for Void we could refine this into:
> 
> Why would it make sense to have `_` as an alias for Void?
>  
> 
> let rangeFrom = 5 ... _
> let rangeTo = _ ... 5
> 
> This would have consistency with other uses of underscore that are used to 
> indicate that something is being ignored on purpose, which I think fits this 
> proposal very well. It would also leave the prefix/postfix ellipsis operator 
> free for use on something else with less chance of creating ambiguity.
> 
> I disagree that this proposed use of the underscore is consistent with other 
> uses.
> 
> The underscore is used as a pattern matching construct that means "I don't 
> care what actual value goes here; match and allow anything and throw it 
> away." But in the range case, not only is this not a pattern, but you also 
> *do* care very much what value is used there—not any arbitrary value is 
> acceptable. The value you want is the least or greatest possible value for 
> that range.

To me the concept of not caring what a value is, and not wanting to specify one 
are consistent; in both cases they are effectively wildcards. The difference is 
that in one context (pattern matching) it's "match anything but don't bother 
assigning it" while in the other (one-sided range) it's leaving the actual or 
effective value up to the implementation of the subscript/method, which is what 
in reality you are doing anyway.

Either way you're ignoring part of the argument, and IMO it's better that this 
is done more explicitly to avoid ambiguity and/or mistakes. Maybe underscore is 
the best option, but if not, I'd like to discuss that as well. Even if it meant 
leaving me with using brackets, I'd still prefer that to omitting one side of 
the range as it would mean giving an explicit declaration of intent.

> Regardless, these ideas were brought up during the proposal's discussion and 
> it's probably safe to assume that the core team considered them but felt they 
> weren't a good solution.

Well then hopefully one of them will see fit to discuss why that is so? ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

[Haravikk via swift-evolution]

While it's good that this was accepted I still feel there could be some more 
discussion about whether the operators should be prefix/postfix or instead 
involve a more explicit declaration of one-sidedness.

I still would very much prefer that the operator declarations were binary and 
take Void as a second argument, this way there is very explicit indication that 
one-sidedness was requested, rather than potentially accidental; assuming many 
subscripts and methods that take currently closed ranges will be updated to 
also take one-sided ranges, the distinction is very important as a omitting one 
of the values could represent a mistake, and result in one-sided behaviour with 
unintended consequences.

With a Void "open" argument this would look like:

func ... (lhs:T, rhs:Void) -> RangeFrom { ... }
func ... (lhs:Void, rhs:T) -> RangeTo { ... }

let rangeFrom = 5 ... ()
let rangeTo = () ... 5

Not the prettiest with the Void brackets, however, if we could in future get 
underscore as another alias for Void we could refine this into:

let rangeFrom = 5 ... _
let rangeTo = _ ... 5

This would have consistency with other uses of underscore that are used to 
indicate that something is being ignored on purpose, which I think fits this 
proposal very well. It would also leave the prefix/postfix ellipsis operator 
free for use on something else with less chance of creating ambiguity.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0172: One-sided Ranges

[Haravikk via swift-evolution]

> On 18 Apr 2017, at 15:29, Matt Lewin via swift-evolution 
>  wrote:
> 
> In contrast, the proposed solution of 
> // half-open right-handed range
> let greeting = s[.. // closed right-handed range
> let withComma = s[...i]
> // left-handed range (no need for half-open variant)
> let location = s[i...]
> requires both the code-writer and the code-reader to infer the missing side 
> is the start or end.
> 
> From my perspective, this obfuscates the language by reducing the ability of 
> the code to be read as English. (One of the goals of Swift design, correct?)

I mentioned in an earlier reply that my preference would be to retain use of 
the binary operator and use Void as the open end like so:

func ... (lhs:T, rhs:Void) -> PartialRangeFrom { … }
func ... (lhs:Void, rhs:T) -> PartialRangeTo { … }

let rangeFrom = 5...()
let rangeTo = ()...5

Would that solve your concern? Ideally we could also push for underscore to 
become another alias for Void when used in such a context, so we could do:

let rangeFrom = 5..._
let rangeTo = _...5

This to me is a bit more explicit that one end of the range being left open on 
purpose. I initially considered some kind of other symbol, but I think 
Void/underscore is suitable enough, underscore especially as it's consistent 
with other features.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

[Haravikk via swift-evolution]

> On 18 Apr 2017, at 05:40, Douglas Gregor via swift-evolution 
>  wrote:
> 
> What is your evaluation of the proposal?
I like the principle of the proposal, but I have some concerns regarding the 
operators. In particular I don't like that it relies on prefix/postfix versions 
of the range operator, I'd prefer it to use the standard binary operator with 
Void as an argument like so:

func ... (lhs:T, rhs:Void) -> PartialRangeFrom { … }
func ... (lhs:Void, rhs:T) -> PartialRangeTo { … }

let rangeFrom = 5...()
let rangeTo = ()...5

With a view to having underscore in future as another alias for Void, so we can 
do the following:

let rangeFrom = 5..._
let rangeTo = _...5

Otherwise I like the basic idea (one-sided ranges) I just feel that the 
one-sidedness of the range operator should be explicit for safety, to avoid 
accidentally declaring a one-sided range somewhere that may accept one. This 
should also leave the ellipsis operators free for use in more specialised cases 
such as variadic tuples, tuple splatting etc.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
It's relatively minor (there are workarounds), but I'd say so.

> Does this proposal fit well with the feel and direction of Swift?
Yes, aside from the accident safety mentioned above.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Read during discussion and re-read now.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] One-sided Ranges

[Haravikk via swift-evolution]

Apologies if this comes through as a duplicate for some people, but I'm not 
sure if it went through the first time; I seem to have some trouble with 
ProofPoint, who apparently do not monitor their false positive reporting 
system. As such my mail server is still listed from eight months ago despite 
never having a single spam message reported in that time, so pretty sure 
ProofPoint is a massive waste of money to anyone having it inflicted upon them, 
as it seemingly blocks entire servers with no negative rating.

Anyway, I'll repost for anyone that didn't get it the first time; if you 
ignored it the first time then feel free to do-so again, just know that it 
shall do irreparable harm to my fragile ego:



I like the principle in general, but I have some concerns about the range 
syntax. Firstly my concern is that allowing either end of the range to be 
omitted feels like a possible bug to me, so I'm not sure if we should encourage 
that?

I'm wondering if a slightly better alternative might to be to retain the 
operators as binary but to pass Void, like so:

let rangeFrom = 5...()
let rangeTo = ()...5

And so-on. It's not quite as pretty, but makes it clear that no mistake was 
made, and allows the operators to be defined normally taking two arguments of 
Comparable and Void (and vice versa).

It could be neatened up if we could allow a lone underscore as Void, like so:

let rangeFrom = 5..._
let rangeTo = _...5

This is a bit neater looking, and should be consistent with how underscore is 
used elsewhere? I'm not sure if it might conflict though, but I don't think so.

Just I thought, but I dislike the idea that by forgetting a value on a range, 
or making some other typo, I could accidentally define an open ended range and 
change the behaviour of something that accepts both open and closed ranges, I 
think requiring something that explicitly indicates an open range is a bit 
better.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] One-sided Ranges

[Haravikk via swift-evolution]

I like the principle in general, but I have some concerns about the range 
syntax. Firstly my concern is that allowing either end of the range to be 
omitted feels like a possible bug to me, so I'm not sure if we should encourage 
that?

I'm wondering if a slightly better alternative might to be to retain the 
operators as binary but to pass Void, like so:

let rangeFrom = 5...()
let rangeTo = ()...5

And so-on. It's not quite as pretty, but makes it clear that no mistake was 
made, and allows the operators to be defined normally taking two arguments of 
Comparable and Void (and vice versa).

It could be neatened up if we could allow a lone underscore as Void, like so:

let rangeFrom = 5..._
let rangeTo = _...5

This is a bit neater looking, and should be consistent with how underscore is 
used elsewhere? I'm not sure if it might conflict though, but I don't think so.

Just I thought, but I dislike the idea that by forgetting a value on a range, 
or making some other typo, I could accidentally define an open ended range and 
change the behaviour of something that accepts both open and closed ranges, I 
think requiring something that explicitly indicates an open range is a bit 
better.

> On 12 Apr 2017, at 17:40, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi Swift community,
> 
> Another proposal pitch. These operators were mentioned briefly in the String 
> manifesto as prefixing/suffixing is very common with strings.
> 
> Online copy here: 
> https://github.com/airspeedswift/swift-evolution/blob/71b819d30676c44234bac1aa61fc5c39bcf3/proposals/-OneSidedRanges.md
>  
> 
> One-sided Ranges
> 
> Proposal: SE- 
> 
> Authors: Ben Cohen , Dave Abrahams 
> , Brent Royal-Gordon 
> 
> Review Manager: TBD
> Status: Awaiting review
> Introduction
> 
> This proposal introduces the concept of a “one-sided” range, created via 
> prefix/postfix versions of the existing range operators.
> 
> It also introduces a new protocol, RangeExpression, to simplify the creation 
> of methods that take different kinds of ranges.
> 
> Motivation
> 
> It is common, given an index into a collection, to want a slice up to or from 
> that index versus the start/end.
> 
> For example (assuming String is once more a Collection):
> 
> let s = "Hello, World!"
> let i = s.index(where: ",")
> let greeting = s[s.startIndex.. When performing lots of slicing like this, the verbosity of repeating 
> s.startIndex is tiresome to write and harmful to readability.
> 
> Swift 3’s solution to this is a family of methods:
> 
> let greeting = s.prefix(upTo: i)
> let withComma = s.prefix(through: i)
> let location = s.suffix(from: i)
> The two very different-looking ways to perform a similar task is jarring. And 
> as methods, the result cannot be used as an l-value.
> 
> A variant of the one-sided slicing syntax found in Python (i.e. s[i:]) is 
> proposed to resolve this.
> 
> Proposed solution
> 
> Introduce a one-sided range syntax, where the “missing” side is inferred to 
> be the start/end:
> 
> // half-open right-handed range
> let greeting = s[.. // closed right-handed range
> let withComma = s[...i]
> // left-handed range (no need for half-open variant)
> let location = s[i...]
> Additionally, when the index is a countable type, i... should form a Sequence 
> that counts up from i indefinitely. This is useful in forming variants of 
> Sequence.enumerated() when you either want them non-zero-based i.e. zip(1..., 
> greeting), or want to flip the order i.e. zip(greeting, 0...).
> 
> This syntax would supercede the existing prefix and suffix operations that 
> take indices, which will be deprecated in a later release. Note that the 
> versions that take distances are not covered by this proposal, and would 
> remain.
> 
> This will require the introduction of new range types (e.g. 
> PartialRangeThrough). There are already multiple range types (e.g. 
> ClosedRange, CountableHalfOpenRange), which require overloads to allow them 
> to be used whereever a Range can be.
> 
> To unify these different range types, a new protocol, RangeExpression will be 
> created and all ranges conformed to it. Existing overloads taking concrete 
> types other than Range can then be replaced with a single generic method that 
> takes a RangeExpression, converts it to a Range, and then forward the method 
> on.
> 
> A generic version of ~= will also be implemented for all range expressions:
> 
> switch i {
> case 9001...: print("It’s over NINE THOUSAAAND")
> default: print("There's no way that can be right!")
> }
> The existing concrete overloads that take ranges other than Range will be 
> deprecated in favor of generic ones that take a RangeExpression.
> 
> Detailed 

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Haravikk via swift-evolution]

> On 9 Apr 2017, at 05:12, Tony Allevato  wrote:
> 
> Agreed—I think the parentheses have to go on the outside for this to work. In 
> this sense, `\Person.mother.age` is an expression that returns a keypath 
> type, with the idea that the parser is greedy and tries to take as many 
> dotted names that follow. The parentheses halt that if needed, but the 
> backslash needs to be bound to the type name for the part inside the 
> parentheses to be interpreted as a keypath.
> 
> `\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then 
> compute the "keypath" of that, which doesn't make sense, whereas `(\Foo.bar)` 
> makes it clear that the keypath expression is being separated from whatever 
> might come after it.

I kind of like having it outside the brackets for the consistency with 
inserting variables etc. within strings; I've learned to think of that as a 
special type of escape from the "string" context, so it could make sense for 
key-paths in the same way.

I'm just thinking that since we're using a backlash it feels a lot like we're 
escaping from normal type access in order to define the key-path instead, and 
since \() is a form of escape used inside strings to encompass something larger 
it makes a kind of sense to me.

As Brent says though it shouldn't be a very common case so it doesn't really 
matter; I'd be fine with either style. I suppose using the backslash inside the 
brackets may be simpler to parse since it's using the parenthesis as normal?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Haravikk via swift-evolution]

> On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution 
>  wrote:
> 
> I love the idea of a leading and trailing backslash. It makes it much easier 
> to read, and handles the "but what if I want to access a property of a 
> KeyPath?" case really well.
> 
> For example, these two are clearly distinct:
> 
>   let x = \Person.mother.age\.valueType
> 
>   let y = \Person.mother.age.valueType\
> 
> I'm not sure why an 'age' object would have a 'valueType' property, but this 
> variant makes it easy to handle. Even in cases where no disambiguation is 
> required, having the trailing backslash makes it much easier to read as I'm 
> scanning through code.
> 
> -BJ

I think I'd prefer brackets for that case; in your first example that reads to 
me like an escape of the period character, rather than "this is the end of the 
key path". Brackets would make this consistent with escaping within strings, 
like so:

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)

Which makes sense to me if you consider the backslash in this case being an 
escape from normal type/variable access. Put another way, normally when you 
type Person. you're telling Swift "access this type and look for static 
methods/properties etc.", whereas when you "escape" it you're telling Swift to 
not to do that, resulting in a key-path instead.

Maybe it's a stretch, it that makes sense logically to me, plus I think the use 
of brackets just looks cleaner than another backslash.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 6 Apr 2017, at 21:47, David Hart <da...@hartbit.com> wrote:
> 
>> 
>> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> • What is your evaluation of the proposal?
>> 
>> I'm a -1 for several reasons, mostly subjective but still. First thing is 
>> that I'm generally not comfortable with encouraging the use of multi-line 
>> strings at all. These are things that usually should be templated or 
>> localised, and personally I don't see what's inconvenient about 
>> concatenating on those occasions where you can't (or just don't want to); 
>> I'm actually of the opinion that this is the kind of thing that should be 
>> awkward and annoying, to encourage developers to think about what they're 
>> doing.
> 
> IMHO, there are plenty of uses for multi-line strings that are entire valid 
> and acceptable. SQL queries is the example I encounter the most in my 
> day-to-day work. And concatenating makes working with them very cumbersome.

Maybe, but with SQL I long moved on to using placeholders for variables, which 
makes most statements fairly compact. And in fact these days I almost entirely 
use stored procedures, so most SQL statements I work with are just enough to 
call a procedure.

Even so, while that may be an argument for the need for multi-line strings it's 
a use case that would still be better handled by continuation quotes IMO, but 
again, they don't offer so much added convenience over concatenation to really 
be worth it.


Also, just wanted to add, but those arguing against continuation quotes on the 
basis of pasting into Swift; you already can paste into Swift using regular 
double quotes, you just don't get to indent text and have the indentation 
magically handled for you. It's the magic handling of indentation that makes me 
most uncomfortable about the main proposal. This is why I mentioned the idea of 
using a compiler directive which would be more explicit in what's going on, as 
well as being more discoverable as it would provide something easy to search 
for. Like so:

let foo = #trimleft("
foo
bar
baz
")

Becoming (behind the scenes):

let foo = "foo
bar
baz"

It has the same benefits as heredocs but without any new syntax, and someone 
new to the language can just search for "Swift #trimleft" (or whatever it'd be 
called) to find out what it does exactly.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution 
>  wrote:
> 
>   • What is your evaluation of the proposal?

I'm a -1 for several reasons, mostly subjective but still. First thing is that 
I'm generally not comfortable with encouraging the use of multi-line strings at 
all. These are things that usually should be templated or localised, and 
personally I don't see what's inconvenient about concatenating on those 
occasions where you can't (or just don't want to); I'm actually of the opinion 
that this is the kind of thing that should be awkward and annoying, to 
encourage developers to think about what they're doing.

My second issue really is that, if the aim is simply to indent your multi-line 
string more nicely, then is this actually something that the language has to 
solve? I know we don't like to consider proposals purely from the perspective 
of what an IDE may, or may not, do, but this seems like a case where a good IDE 
could take:

let foo = "This is my
multi-line
text"

And display it visually to look like:

let foo = "This is my
multi-line
text"

This is basically what Xcode does for line-wrapped text right now. While it 
would mean people using more basic editors would still see the original, it's 
not really like that's a major problem.

Another alternative might be a compiler directive that is more explicit about 
what you want to do, for example:

let foo = #trimleft("
This is my
multi-line
text
")

Here the directive would look at the text as a whole and see that all lines are 
indented by at least one tab, and so strip one tab from each line. There's 
probably a better name for the directive, but hopefully you hopefully get the 
idea, as this is much more explicit about what you want to do.

Also, one thing that really stands out with the proposal is how unwise the 
example is; the fact that the assertion relies on leading whitespace being 
stripped from the multi-line HTML makes it clear why things like this may not 
be a good idea, as if the code is edited to produce indented HTML then the 
assertion will fail, even if the HTML is still correct. The continuation quotes 
example makes this more obvious as it actually include some of the whitespace, 
so which is correct?

I don't want to seem too negative, I just think that whitespace stripping 
multi-line strings are a weird thing to want in a language. If an easier 
multi-line syntax has to be added then my preference would be for the 
alternative continuation quotes personally, as it's more explicit about what is 
included, though I still say there's nothing wrong with just doing the 
concatenation and newline characters IMO, as it's fully supported today and not 
really that much more burdensome to do (and it being a bit more difficult may 
be a good thing, as I say).

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Not really. We can already do multi-line by either putting newlines inside 
quotes and leaving out indentation, or by concatenating lines terminated with 
the new-line character. IMO these two existing options are enough as it is.

>   • Does this proposal fit well with the feel and direction of Swift?

I'm not sure; in terms of simplicity I think that adding new syntax for 
multi-line strings is an unnecessary added complexity and something else to 
learn, and doesn't enable anything we can't already do fairly easily.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

All of the proposed syntaxes are present in various languages, I've used many 
of them, and I know from my own bad habits that 99% of the time I shouldn't 
have 

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Followed the discussion and re-read the proposal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Haravikk via swift-evolution]

> On 6 Apr 2017, at 06:56, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 6 Apr 2017, at 04:21, Ricardo Parada via swift-evolution 
> > wrote:
> 
>> 
>>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
>>> It's worth noting that, if you write `\Person.name.valueType`, this syntax 
>>> is ambiguous—it could mean "make a key path for the `valueType` property on 
>>> `name` property of `Person`", or it could mean "make a key path for the 
>>> `name` property of `Person`, then access the key path's `valueType` 
>>> property". We can solve this by always interpreting it as the former and 
>>> requiring parentheses for the latter—that is, 
>>> `(\Person.name).valueType`—but I thought it was worth calling out 
>>> explicitly.
>> 
>> Good point. 
>> 
>>  I'm thinking about the hypothetical code examples from previous emails:
>> 
>> 
>>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> Couldn't the compiler see there exists no contains property on pets and allow 
> us to avoid the parentheses?

Probably, but IMO it actually looks better, and is clearer, with the brackets 
anyway, so encouraging their use could be a good thing perhaps?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Haravikk via swift-evolution]

I still don't really see what's so wrong with just doing:

let foo = "This my " +
  "multiline " +
  "string"

It's only one or two characters more than other proposed styles, and IMO it's 
not something that should come up all that often; I'm kind of uncomfortable 
with the idea of encouraging multi-line strings in code, as really these should 
be localised properly instead.

If there needs to be an alternative I'd say just allow omission of the 
concatenation operator like so:

let foo = "This my "
  "multiline "
  "string"

The caveat for this is that we would need to disallow a string as a statement, 
or require explicit concatenation anywhere it might be ambiguous like so:

let foo = "This my "
  "multiline "
  "string".capitalized // Warning: Use concatenation (+) or let _ = to 
disambiguate

This would need become one of the following:

let foo = "This my "
  "multiline " + // Clearly concatenated
  "string".capitalized


let foo = "This my " +
  "multiline "
let _ = "string".capitalized // Clearly separate for some reason

But yeah, I don't know if we should really encourage multi-line comments too 
much; if I had my way we'd somehow make them more awkward to use, just to stop 
people using them 

> On 3 Apr 2017, at 13:36, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I don’t really think this is about how to indicate a multi-lined string, 
> where the string starts and ends with something like ", ' or """ is trivial 
> to me. It’s just a decision to make. However the main debate I see with that 
> topic is the ambiguity from the readers perspective.
> 
> In your example I assume you want a result to match this: “my multiline 
> string”, but what if you need precision? Should we really fallback to single 
> line string then? What if you want to print some XML file with all it’s 
> indent calculated with whitespaces rather than tabs? The multiline version 
> like that won’t work, and if your string is huge you’ll end up at a place 
> where we already are. This doesn’t solve the main then because we could 
> otherwise simply allow this today:
> 
> let string = "my
> multiline
> string"
> I’m only speaking for my personal preference, others might see it completely 
> different. However I’m totally sure multiline strings solve more than simply 
> being able to write them so that the compiler is satisfied.
> 
> As a compromise for everyone we possibly could come up with a way which 
> serves both, simplicity and precision. 
> 
> For the next bikeshedding example I’m going to use ' for multi-lined strings:
> 
> // Simplicity which supports indent but at a cost of no  
> // leading or trailing space characters
> let string1 = 'my
> multiline
> string'
> 
> print(string1) // prints "mymultilinestring"
> 
> let string2 = 'my \  
> multiline \
> string'
>  
> // Trailing precision
> print(string2) // prints "my multiline string"
> 
> let string3 = 'my
> ' multiline
> ' string'
>  
> // Leading precision
> print(string3) // prints "my multiline string"
> 
> let string4 = 'my \
> ' multiline \
> ' string'
>  
> // Leading and trailing precision
> print(string4) // prints "my  multiline  string" (Note: 2x two whitespaces)
> 
> let string5 = 'my\
> 'multiline\
> 'string'
>  
> // Leading and trailing precision
> // Provide a fix-it to remove some `\` and `'` characters
> // because it equals `string1`
> print(string5) // prints "mymultilinestring"
> 
> let string6 = 'my \
> 'multiline \
> 'string'
>  
> // Leading and trailing precision
> // Provide a fix-it to remove some `'` characters
> // because it equals `string2`
> print(string6) // prints "my multiline string"
> 
> let string7 = 'my\
> ' multiline\
> ' string'
>  
> // Leading and trailing precision
> // Provide a fix-it to remove some `\` characters
> // because it equals `string3`
> print(string7) // prints "my multiline string"
> Comments should be only allowed after the escaping character. string1 can 
> only have comments after the last line of that string.
> 
> I think a model like this could have the best from both worlds.
> 
> Personally I dislike the idea of """ and would rather want a model from above 
> with " and \ or as written.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 11:56:12, Daniel Leping (dan...@crossroadlabs.xyz 
> ) schrieb:
> 
>> What about """ notation?
>> 
>> It could become something like:
>> let mys = """my
>>   multiline
>>   string"""
>> 
>> On Mon, 3 Apr 2017 at 12:35 Adrian Zubarev via swift-evolution 
>> > wrote:
>> Simply because it’s always a zero to n space characters at the start of the 
>> line 

Re: [swift-evolution] Smart KeyPaths

[Haravikk via swift-evolution]

> On 31 Mar 2017, at 12:33, Brent Royal-Gordon <br...@architechies.com> wrote:
> 
>> On Mar 31, 2017, at 3:07 AM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Is it actually in-use or just reserved? Not sure I've ever needed it in the 
>> debugger.
> 
> Pop into the REPL for a minute:
> 
>   $ swift
>   Welcome to Apple Swift version 3.1 (swiftlang-802.0.41 clang-802.0.36). 
> Type :help for assistance.
> 1> "hello"
>   $R0: String = "hello"
> 2> $R0
>   $R1: String = "hello"
> 
> You may not have ever noticed it was there, but it was.

Is it always in the form of $R? If it can't include periods then it doesn't 
seem like it would present a collision (just as overlap with $0, $1 etc. in 
closures does not).

>> What about @? It has a certain appropriateness in how it reads for a path 
>> like: @Person.friend.lastName
> 
> We're already using @ for attributes; I don't think we want to overload its 
> meaning.

Ack, no idea how I forgot about attributes considering I use them all the time. 
Hmm.

>> Another alternative might be something like an unnamed compiler directive, 
>> for example: #(Person.friend.lastName)
>> If you consider the statement to mean "expand this".
> 
> The unnamed compiler directive seems like *really* valuable real estate, 
> arguably much more so than unresolved-member-on-KeyPath-type is. I think it'd 
> be foolish to assign it to anything before we have a macro system designed.

Perhaps, but how many other features might be making a bid for it? There's 
always the possibility of using a more "specialised" bracket for paths instead, 
like #{Person.friend.lastName}
Leaving regular parenthesis up for grabs for something else.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Haravikk via swift-evolution]

> On 30 Mar 2017, at 17:18, Joe Groff <jgr...@apple.com> wrote:
> 
> 
>> On Mar 30, 2017, at 6:54 AM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>>> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> I'm not a fan of the new syntax for creating key paths. To me, it feels 
>>>> like they've been demoted to second class citizens of the language simply 
>>>> because of how more verbose it now is. The new syntax is also too 
>>>> confusingly similar to string key paths: I had to look closely at the code 
>>>> to see the difference. Is there no symbol we can use to make it ambiguous? 
>>>> Ideas:
>>>> 
>>>> Person::friend.lastName
>>>> Person/friend.lastName
>>>> Person#friend.lastName
>>>> 
>>>> I'm a fan of the first one as it has similarities to names pacing in C++.
>>> 
>>> I'm a big fan of the last one.  I argued for it earlier as the best syntax 
>>> to use if we deviated from the initial proposal.  I like it for several 
>>> reasons:
>>> 
>>> - # suggests compiler magic is at work which is the case here.
>>> - #friend.lastName works nicely as a shorthand in contexts expecting a key 
>>> path with a fixed Root
>>> - # would work for unbound methods solving the no arguments case.  IMO all 
>>> unbound members should be accessed using the same syntax.
>>> - # enables the possibility of mixing property access and method calls in 
>>> the path as a future enhancement
>>> 
>>> The arguments supporting this approach are pretty strong to me.  I agree 
>>> with David that the #keyPath syntax makes it feel more like a second class 
>>> citizen, not just because of the verbosity but also because it is directly 
>>> borrowed from an Objective-C interop feature.  This is a very powerful 
>>> feature that deserves to be a first class syntactic citizen every bit as 
>>> much as unbound methods do.
>> 
>> Personally I'd prefer the use of a leading dollar sign for this, for example:
>> 
>>  $Person.friend.lastName
>> 
>> I find a symbol midway through the path a bit strange, plus the leading 
>> dollar sign already implies compiler magic in the same way as anonymous 
>> parameters in closures. In fact you can think of anonymous parameters as a 
>> kind of special key-path of sorts, and there should be no ambiguity.
>> 
>> I prefer this to the hash symbol for compiler directives, since those feel 
>> more like things that are done once during compilation, rather than 
>> something you actually use at run-time, so I like the distinction of another 
>> symbol for that.
> 
> $ is reserved for the debugger. We don't really have many free symbols to 
> burn, and it would be unwise to burn one on a new feature before having 
> evidence that it deserves it.

Is it actually in-use or just reserved? Not sure I've ever needed it in the 
debugger.
What about @? It has a certain appropriateness in how it reads for a path like: 
@Person.friend.lastName

Another alternative might be something like an unnamed compiler directive, for 
example: #(Person.friend.lastName)
If you consider the statement to mean "expand this".___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Haravikk via swift-evolution]

> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution 
>  wrote:
>> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution 
>> > wrote:
>> I'm not a fan of the new syntax for creating key paths. To me, it feels like 
>> they've been demoted to second class citizens of the language simply because 
>> of how more verbose it now is. The new syntax is also too confusingly 
>> similar to string key paths: I had to look closely at the code to see the 
>> difference. Is there no symbol we can use to make it ambiguous? Ideas:
>> 
>> Person::friend.lastName
>> Person/friend.lastName
>> Person#friend.lastName
>> 
>> I'm a fan of the first one as it has similarities to names pacing in C++.
> 
> I'm a big fan of the last one.  I argued for it earlier as the best syntax to 
> use if we deviated from the initial proposal.  I like it for several reasons:
> 
> - # suggests compiler magic is at work which is the case here.
> - #friend.lastName works nicely as a shorthand in contexts expecting a key 
> path with a fixed Root
> - # would work for unbound methods solving the no arguments case.  IMO all 
> unbound members should be accessed using the same syntax.
> - # enables the possibility of mixing property access and method calls in the 
> path as a future enhancement
> 
> The arguments supporting this approach are pretty strong to me.  I agree with 
> David that the #keyPath syntax makes it feel more like a second class 
> citizen, not just because of the verbosity but also because it is directly 
> borrowed from an Objective-C interop feature.  This is a very powerful 
> feature that deserves to be a first class syntactic citizen every bit as much 
> as unbound methods do.

Personally I'd prefer the use of a leading dollar sign for this, for example:

$Person.friend.lastName

I find a symbol midway through the path a bit strange, plus the leading dollar 
sign already implies compiler magic in the same way as anonymous parameters in 
closures. In fact you can think of anonymous parameters as a kind of special 
key-path of sorts, and there should be no ambiguity.

I prefer this to the hash symbol for compiler directives, since those feel more 
like things that are done once during compilation, rather than something you 
actually use at run-time, so I like the distinction of another symbol for that.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Disallowing unreachable code

[Haravikk via swift-evolution]

> On 24 Mar 2017, at 22:54, Peter Dillinger via swift-evolution 
>  wrote:
> 
> I don't see anything directly relevant to this in the archives, and I haven't 
> prepared a detailed proposal.  But I'm raising the general idea because I 
> recently criticized Swift 3 for allowing unreachable code in a blog post: 
> https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/
>  (search for "unreachable code").  And I want you to have every opportunity 
> to rectify this, even though I'm in the business of finding defects the 
> compiler doesn't.  :)
> 
> Part of my argument is that people commonly ignore compiler warnings.  We see 
> lots of defective code that would be (or is) caught by compiler warnings but 
> people don't pay attention.

Which people? Personally warnings bug me no end; I'm not happy until they're 
all dealt with, so a warning is more than sufficient in my case.

While obviously writing unreachable code on purpose isn't the best way to do 
something, sometimes throwing some code into an if (false) or dropping in an 
early return to see if it fixes or triggers a problem is a perfectly reasonable 
way to do something in a quick and dirty way.

IMO a warning is more than sufficient for this, so that the programmer is 
reminded to go back and fix it.

I don't know if it's possible to elevate specific warnings to errors (I used to 
do this working with Java in Eclipse but have never wanted to in Xcode), if not 
then that may be worth considering as an alternative? But as a default I think 
a warning is sufficient, at least for me, as I'd rather be able to make code 
unreachable than have an error when it is.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Partial Implementations

[Haravikk via swift-evolution]

> On 24 Mar 2017, at 12:13, Vladimir.S  wrote:
>> On 24.03.2017 12:50, Haravikk wrote:
>> I can see why some people might want to do stored properties in extensions
>> to structure things, but personally I quite like the lack of flexibility as
>> it encourages the initial type declaration to focus on what a type
>> *contains*, while extensions focus on what it *does*. I've really taken to
>> that style, as I now almost never declare methods or computed properties in
>> an initial type declaration, unless it's a very simple one; instead doing
>> all my methods and protocol conformances in their own extensions.
> 
> The main problem I currently see with extensions: you can't conform to 
> protocol in extension if you want to have stored properties to implement the 
> protocol. And conforming to separate protocol in separate extension is a 
> common practice and usually you need this in the same file when you define 
> the type.
> *This* was my main point when I suggest to allow stored properties *only in 
> the same file where the type is declared*.

Even, so I think this is kind of the right way to do it; protocols don't 
specify stored properties, only a name and type, so IMO it doesn't necessarily 
follow that fulfilling that requirement with a store property belongs in an 
extension.

Consider for example a conformance to Indexable, I want to do this in an 
extension and I need to decide to how I'm going to handle the startIndex and 
endIndex properties. For some reason I decide I'll store one in my type and 
compute the other:

struct MyCollection {
let startIndex:Int = 0
}

extension MyCollection : Indexable {
var lastIndex:Int { return someValue() } // it's a really bad 
collection
}

Bit contrived I know, but here I've been forced to think about where to put 
each, hopefully making it more obvious that my choice for startIndex was a 
waste of space, since it has made MyCollection 4/8 bytes larger.

I just really like that property of the pattern; it also means that, if I keep 
the type declaration clean, then at a glance I can see what contributes to the 
type's actual contents and size. Here someone new to the code would immediately 
see that I was an idiot 

I'll agree that there's some separation from the protocol that it was actually 
required by, but I prefer it that way to having stored properties scattered 
around, even within the same file (especially since we're often talking about 
very large files here for complex types). This "feature" is good for someone 
new to the code as it makes it easy to learn what is a stored vs computed 
property, especially if it has encouraged the developer to keep the number of 
stored properties to a minimum.

I dunno, maybe it comes from having once had header files for everything, but I 
like this separation of concrete components of a type.


There was a proposal a while ago as an alternative to stored properties in 
regular extensions, which was the use of "mix-ins", which would be its own 
category. The aim of those is to modularly build up a type and quickly add 
conformances from reusable mix-ins, but you could also do it just for a single 
type.

I preferred that idea because it formalises that this is something you can't 
just do to an imported type, and gets away from this idea of having something 
you can do with an extension, but only at the file-scope, which I feel kind of 
weird about.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Partial Implementations

[Haravikk via swift-evolution]

> On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote:
>> 
>>> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution
>>>  wrote:
>>> 
>>> MOTIVATION:
>>> 
>>> In current Swift, a pattern has emerged among some developers, in
>>> order to logically group parts of a class or struct’s declaration,
>>> particularly around protocols:
> >> ...
>>> 
>>> What do you think?
>> 
>> If we wanted to allow code like this to be written we wouldn’t need a
>> new keyword to do it.  You are proposing two things here:
>> 
>> 1) Allow stored properties in same-module extensions.  This has been
>> discussed in the past and is a possibility, but I suspect it is not in
>> scope for consideration during Swift 4.
> 
> Are we really expect to have stored properties in same-module extensions?
> As I remember, there a lot of questions were raised during discussions so for 
> some reason *I* had a feeling that we should not expect this happens in near 
> feature. Probably I missed something.

I can see why some people might want to do stored properties in extensions to 
structure things, but personally I quite like the lack of flexibility as it 
encourages the initial type declaration to focus on what a type contains, while 
extensions focus on what it does. I've really taken to that style, as I now 
almost never declare methods or computed properties in an initial type 
declaration, unless it's a very simple one; instead doing all my methods and 
protocol conformances in their own extensions.

i.e- I quite like that by the time you've finished your type declaration you 
have finalised what its size will be, and nothing else can change that, 
spreading it out feels like it could make that more confusing. It also IMO 
helps to encourage you to keep a type's contents fairly simple, as you can see 
in one place if you've made it very complicated.

I suppose there's an argument for having the freedom to do it however you want, 
but I don't think spreading out across a module is a good idea; unless we're 
assuming that module in this context applies like in other proposals, where 
fileprivate is a "module" with only one file.

I dunno, I just think that as a pattern the current requirement to keep stored 
properties within a type declaration enforces some good practices. I found it a 
bit jarring at first too, but after adapting to the type + extensions style I 
find I actually really like doing things that way.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Haravikk via swift-evolution]

> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution 
>  wrote:
> * What is your evaluation of the proposal?

In favour.

Like others I can foresee there being a bit of pain for some developers, but I 
think it's worth it to be more explicit about what's going on, and to clean up 
a feature that's just for supporting a specific other language.

My main concern is on whether things could be made a bit easier; specifically I 
wonder whether we could introduce an option (to the compiler?) to trigger 
warnings anywhere there is a possible missing @objc attribute. Basically on any 
code that produces bridging headers this would give a warning anywhere that 
@objc would have been inferred in the past, but will no longer be. Of course 
this will generate a lot of warnings, but it'll be an easier way for developers 
to go through and make sure they didn't miss something. Xcode could offer this 
automatically during migration, and the developer can turn it off when they're 
done. Not perfect, but it may be a little extra help for those most affected?

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

I believe so, I think we need to cut down on anything that's too platform or 
legacy specific in favour of Swift being as clean and functional as possible 
with limited magic features.

> * Does this proposal fit well with the feel and direction of Swift?

Yes, as I believe it tidies up the language and removes something caters too 
much towards a specific, hopefully increasingly legacy, use-case.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study? 

Following discussion, quick re-read.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Haravikk via swift-evolution]

> On 21 Mar 2017, at 20:04, David Smith via swift-evolution 
>  wrote:
> 
> 
>> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> +1.  This is my favorite solution so far. 
>>> 
>>> With ‘Person.keypath.name' it is obvious that we are creating a key path.  
>>> There is no ambiguity for the reader.  With autocomplete it will be very 
>>> little extra typing anyway…
>> 
>> But that adds a lot of verbosity. They disregarded #keyPath because it was 
>> too verbose.
> 
> For what it's worth, I'm not especially worried about verbosity. Long-term 
> I'm hoping that this feature and the ones we build on it will see far broader 
> use than keypaths ever did in ObjC, but a little more typing isn't that bad. 
> What *is* a loss though, is something I'll call "conceptual surface area".
> 
> We talk a lot about "conceptual load" when designing APIs, which is the 
> notion that even if each individual concept is simple, the sheer volume of 
> things that you have to keep track of can be exhausting, make learning 
> difficult, and cause mistakes. With some features though, the conceptual load 
> comes more from what isn't there. With unbound methods, you have to know "ok 
> String.init gets me String's initializer as an unbound function I can call, 
> so I can do stuff like [1, 2, 3].map(String.init)" but you *also* have to 
> know "but that doesn't work on subscripts or properties, just methods". So 
> even though there's only one concept here, the hole in the feature is itself 
> an additional concept; an irregularly shaped thing having more mental surface 
> area.
> 
> So the biggest reason I like the current syntax proposal is that it fills in 
> a hole, reducing the conceptual surface area to "ok, Foo.bar gets me an 
> unbound version of anything".
> 
> Unfortunately, as everyone has pointed out, static/class properties make that 
> claim not so true. Hanging keypaths off a ".keypath" class property also 
> conflicts, since there's nothing stopping a method or property from being 
> called "keypath". I see several paths forward from here, not least of which 
> is "it's probably not a huge deal in practice", but I'd like to think about 
> it and listen to the discussion a bit longer before suggesting anything.

Would an operator solve this issue? I have to admit I've never really used 
something like this so I've only really been half-glancing at this thread as 
the messages come up, but it seems like an operator would keep the paths from 
being too verbose, while disambiguating.

This may in fact be something where the dollar sign could be a good fit, i.e: 
$Foo.bar

It's unambiguous with shorthand variables in closures, and keeps the feature in 
the same kind of "sort of compiler magic" category that they exist in, since 
they're not proper variables, but can be used as such, just as a key-path here 
is sort of a property access, but handled in a special way.

Just a thought anyway.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Code blocks and trailing closures

[Haravikk via swift-evolution]

> On 20 Mar 2017, at 14:24, Rien via swift-evolution 
>  wrote:
> 
> Another solution to the original problem would be to allow the parameter name 
> of the closure outside the functions parenthesis:
> 
> func test(a: Int, onError: ()->Void) {…}
> 
> could be called like this:
> 
> test(5) onError: { myErrorHandler() }

When you get onto that kind of syntax the obvious question is, what's wrong 
with:

test(5, onError: { myErrorHandler() })

To me there's no real difference, in fact all that's changed now is that a 
round bracket is at the end; while being within the parenthesis is a little 
noisier, it's also clearer what's going on. Consider, if the body of the 
closure were very long:

test(5, onError: {
// Lots
// and
// lots
// of
// code
})

Here the closing round bracket reminds me that this is the end of a closure 
being passed to a function, rather than some other code block and, if properly 
indented, it should be easy to jump to whatever that function is.

It could just be my personal preference; I'm generally uncomfortable with the 
use of trailing closures except for language-like constructs such as .forEach, 
and I've never had any problem using closures within the function's 
parenthesis, but it just seems like there's a point at which we're bolting so 
much onto trailing closures, that you really do have to ask what's so wrong 
with just passing the closure normally?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [draft] Add `clamped(to:)` to the stdlib

[Haravikk via swift-evolution]

> On 15 Mar 2017, at 19:40, Nate Cook via swift-evolution 
>  wrote:
> 
> Hi Nick,
> 
> I think this might have come up in an earlier thread, but clamped(to:) with a 
> half-open range argument brings up the question of how to clamp to an empty 
> range. As proposed, the implementation of this method would result in an 
> error when passed an empty range:
> 
> foo.clamped(to: 0..<0)
> // fatal error: Can't form Range with upperBound < lowerBound
> 
> Is that the desired behavior? Providing documentation for both new methods 
> would help make it clear what the expected functionality is.

I'd say that's the correct behaviour; it makes no sense to call a clamp method 
without anything to actually clamp to; an empty range contains nothing, so not 
only can't include the value you're testing against, but also has no bounds to 
clamp to instead.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Hasher & HashVisitable

[Haravikk via swift-evolution]

I really like the proposal!

Only thing I'm wondering is whether a convenience function on Hasher might be 
nice to have, like so:

extension Hasher {
mutating func hash(_ hashable:H) -> Int {
hashable.hash(self)
return self.finish()
}
}

This just feels like it would be easier for the most common case where you just 
need to hash a single value right away, as you'd just do:

let hashValue = hasher.hash(foo)

While leaving the inout style available for when you do need to combine 
multiple values together or otherwise feed in data gradually. This way we're 
not losing as much of the convenience of the .hashValue that's being 
deprecated. On that note, should Hashable be updated to do something like the 
above as well, so it still immediately returns a value from a default hasher?

Anyway, definitely in favour of this change, as you're right; .hashValue is a 
hard thing to do right, and is often an after-thought, which can make it of 
limited usefulness to types that depend upon it!

> On 13 Mar 2017, at 15:38, Vincent Esche via swift-evolution 
>  wrote:
> 
> Hi there,
> 
> I've written up a proposal for an overhaul/replacement of the Hashable 
> protocol and would love to hear your feedback on it!
> 
> Rendered 
>  | Blog 
> Post 
> 
> Cheers,
> Vincent
> 
> Ps: I'd like to thank David Hart (@hartbit) for his great editorial feedback 
> on this proposal. 
> 
> HashVisitable
> 
> Proposal: SE- 
> Authors: Vincent Esche 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> Replace the Hashable protocol by two new procotols (Hasher and HashVisitable) 
> to improve safety, versatility and learnability.
> 
>  
> Motivation
> 
> Implementing Hashable is difficult and the consequences if not done well have 
> dire performance and safety repercussions.
> 
> The documentation of Hashable lists a sample implementation 
>  of var hashValue:
> 
> /// A point in an x-y coordinate system.
> struct GridPoint {
> var x: Int
> var y: Int
> }
> 
> extension GridPoint: Hashable {
> var hashValue: Int {
> return x.hashValue ^ y.hashValue
> }
> 
> static func == (lhs: GridPoint, rhs: GridPoint) -> Bool {
> return lhs.x == rhs.x && lhs.y == rhs.y
> }
> }
> Calculating the hashes of all GridPoints (given the above implementation) on 
> a 1000 × 1000 grid …
> 
> let (width, height) = (1000, 1000)
> let total = width * height
> var hashes = Set()
> for x in 0.. for y in 0.. hashes.insert(GridPoint(x: x, y: y).hashValue)
> }
> }
> print("\(hashes.count) unique hashes out of a total of \(total).")
> … results in just 1024 unique hash values for 1_000_000 unique values.
> 
> In other words: The recommended implementation causes 99.9% of values to 
> trigger a hash collision.
> 
> Out of those 1_000_000 values the median collision count was 976 with min and 
> max being 976 and 1000respectively.
> 
> The collision rate will have negative impact in algorithms which heavily use 
> hashValue like the ones in Dictionaryand Set. Furthermore, it increases the 
> vulnerability to DDOS attacks when exposed to the web 
> .
> 
> If even the official Swift documentation gets the implementation of hashValue 
> wrong, then who is to expect the average Swift programmer to do any better?
> 
> In contrast, running the same snippet using HashVisitable and the semi-secure 
> Fnv1aHash (see below) results in zero collisions!
> 
> Finally, the design of the Hashable protocol forces the use of one 
> implementation without the possibility of switching between multiple hashing 
> algorithms.
> 
>  
> Proposed
>  solution
> 
> Instead of coupling the hashing algorithm with each and every Swift type, we 
> should provide a hashing API based on the visitor-pattern. By freeing 
> application developers from the burden of having to implement hashing 
> algorithms, the Standard Library can provide default ones which fulfill 
> collision, performance and security goals. Furthermore, it would allow 
> developers to swap to different algorithms based on the use case.
> 
>  
> Detailed
>  design
> 
> The proposal deprecates the Hashable protocol and 

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Haravikk via swift-evolution]

> On 12 Mar 2017, at 04:33, Ricardo Parada via swift-evolution 
>  wrote:
> 
> I read Haravikk's proposal a second time. I think I see the advantage of 
> being able to use it with other types besides array. 
> 
> I also found disambiguating with the trailing comma to be intuitive. On the 
> other hand I did not find it so intuitive to use @variadic and @nonVariadic 
> to disambiguate.  I would say just pick the trailing comma. 

As written you'd be able to do both, it's just down to personal preference 
which. However, while the comma works fine for enforcing a variadic call, there 
does still need to be a way to tell Swift you want to call with an array, which 
is what the nonVariadic attribute/compiler directive is for; fortunately this 
is a case that only comes up when the function accepts elements of type Any, so 
there's ambiguity as to whether you're passing an array of elements, or an 
element that happens to be an array.

There are some other features being discussed where it might make sense to have 
an expansion operator, and some have proposed using the trailing ellipsis for 
this, so we could end up with something like:

let bar = myFunc(foo...) // call as an array
let baz = myFunc(foo,) // call variadically

But I'm just not sure if it's worth doing only for the single proposal or not? 
I suppose I could mention it in alternatives though!___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Infer types of default function parameters

[Haravikk via swift-evolution]

> On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I sent the message below to swift-users@ ~a day ago, but this might be a 
> better place to ask and gather some discussion. It is a rather minor 
> suggestion and I'm just looking for some opinions.
> 
> Declaring a function that has default parameters currently looks like this:
> 
> func foo(bar: String = "baz") {
> print(bar)
> }
> 
> Now I'm wondering if there would be any problems if it were possible to omit 
> the type annotation for default params and let Swift's type inference handle 
> that. 
> 
> func foo(bar = "baz") {
> print(bar)
> }
> 
> It feels to be equivalent to omitting type annotations with variable 
> declarations. Obviously more complex types would still require annotations 
> being specified. Off the top of my head I can't think of any negative 
> ramifications this might bring, be it in simple function/method declarations 
> or protocol extensions and elsewhere. 
> Any further input or examples for situations where this might cause issues 
> would be much appreciated :)

I like the idea but I'm afraid I don't think I can support it.

I think it is more important for function/method declarations to have as 
explicit a signature as possible; I mean, I'm not even that comfortable with 
the ability to omit -> Void on non-returning functions (I always include it 
just to be consistent).

As others point out, while this makes sense for types where there's only one 
obvious choice to infer, it's not quite so clear on things like ints where a 
function really needs to be absolutely clear on what type/width of int it 
expects, since it's not something you want to have to change in future.

One alternative I thought of was an operator for this purpose, e.g- := (chosen 
since the colon kind of suits the omitted type declaration); this would allow a 
developer to be explicit about wanting Swift to infer the type, but it would be 
inconsistent with regular variables where it's always inferred, so I'm not sure 
if it'd be a good option anyway.

Sorry, I do agree that it feels inconsistent that a function default doesn't 
behave more like a variable's initialisation, but at the same time they are two 
slightly different concepts so that's not necessarily a bad thing.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Static methods as global functions

[Haravikk via swift-evolution]

> On 10 Mar 2017, at 13:36, Derrick Ho  wrote:
> 
> -1

Thanks for being so specific in a discussion thread 樂
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Discussion] Static methods as global functions

[Haravikk via swift-evolution]

So the topic of global functions like min/max came up on the thread about 
adding a standard clamp method, and it got me to thinking whether there was a 
better way to define most global methods.

Currently for example there are two global functions min and max; very useful, 
and don't make much sense as instance methods, but they're not as easily 
discoverable as a static method declared under relevant type(s). We could get 
around this by defining such functions both as a static method, and as a global 
function, but it means duplicate code and by convention only.

An alternative is to remove the need for duplicate methods using a new global 
keyword for a method declaration, telling Swift to define it as both a static 
method and a global function. This allows the function to be grouped logically 
under a type, making it a bit neater, but without losing the benefit of the 
global definition. For example:

protocol Comparable {
global func min(_ a:Self, _ b:Self) -> Self { return a < b ? a 
: b }
global func max(_ a:Self, _ b:Self) -> Self { return a > b ? a 
: b }
}

With this single definition both of the following are now valid:

let min = Int.min(1, 3)
let max = max(5, 10)

In the second case, Swift looks at all global definitions for "max" in order to 
locate the best match, leading it to Int.max.

It's a relatively small change, but helps with neatness. It may also be good 
for consistency if we ever get the ability to define operators within types 
(though I'm not sure where we are with that?), as they could potentially just 
use the same format like-so:

struct MyType : Equatable {
global func == (_ a:MyType, _ b:MyType) -> Bool { /* Determine 
equality */ }
}

I just think it's a neater way to do this than currently requiring separate 
declarations for the static and global versions, especially since one usually 
just calls the other anyway, anyone have any thoughts?

I normally argue against new keywords, but in this case it may be justified, as 
I considered an attribute but it would only end up requiring static anyway, so 
it seemed neater to just have a new category "above" static that is both static 
and global, since a global non-static doesn't make any sense. However, one 
advantage of a @global attribute is that it could potentially take a different 
name for the global function, so I could (but probably wouldn't) define 
something like:

@global("min") static func smallerOfTwo(_ a:Self, _ b:Self) -> Self { 
return a < b ? a : b }

So here, although the method name is smallerOfTwo, it is exposed globally as 
"min". Though I don't know much need there would be for something like that.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] class indent in swift, history?

[Haravikk via swift-evolution]

> On 8 Mar 2017, at 17:23, Rob Mayoff via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> On Wed, Mar 8, 2017 at 5:09 AM, Haravikk via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> willSet and didSet have their own distinct scope; they execute independently, 
> however a switch statement is effectively a single scope because of the 
> ability to use fallthrough to visit later cases.
> 
> A switch statement has a separate scope for every case, including default. 
> Example:
> 
> switch Int() {
> case 0:
> let m = "zero"
> fallthrough
> default:
> Swift.print(m)
> }
> 
> Result:
> 
> Playground execution failed: error: MyPlayground.playground:2:17: error: use 
> of unresolved identifier 'm'
> Swift.print(m)

I think I'm using the term scope in a confusing way, but I think I thought of a 
better way to explain it anyway:

When it comes to indenting the switch, the switch itself, and its cases, are 
actually all part of the same "level", because they're actually a leading 
conditional plus a bunch of labels to jump to, no new scope has occurred yet. 
It's only once you've jumped to a label that any kind of narrowing can actually 
occur.

To go back to my example of how a switch statement actually works, here's what 
it looks like again with jumps and labels, this time with case contents 
indented to show variable scope:

if (foo == 1) jump @case1
else if (foo == 2) jump @case2
else jump @default

@case1
print("Case 1")
jump @end
@case2
print("Case 2")
// no jump because of fallthrough
@default
print("Default")
jump @end
@end

Perhaps the term block would have been better; the switch contents are a 
contiguous block of code that you jump into, the variable scope occurs because 
you can't guarantee that a previous case was visited and fell through. Thus the 
case conditions/labels themselves are not of a more limited scope because 
they're testing for and setting up a jump to the correct location. Just like 
how an if statement's condition isn't indented, because they're essentially the 
same thing.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] class indent in swift, history?

[Haravikk via swift-evolution]

> On 8 Mar 2017, at 08:35, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> The latter slightly confused me for a second and I had to double check. 
> You’re saying that cases are not indented “because” they are part of the 
> switch statement, but observers like willSet and didSet are indented even if 
> they are part of the property they are defined on. What’s the point I’m 
> missing in this argument? (I’m precisely talking about the comparison between 
> cases and observers, not about the indent elsewhere.)
> 

willSet and didSet have their own distinct scope; they execute independently, 
however a switch statement is effectively a single scope because of the ability 
to use fallthrough to visit later cases.

To try and illustrate, consider the following switch statement:

switch(foo) {
case 1:
print("Case 1")
case 2:
print("Case 2")
fallthrough
default:
print("Default")
}

If foo is equal to 2, the output will be both "Case 2" and "Default". Another 
way to think of this is in terms of how a switch statement actually executes, 
the above would become something resembling the following (using rough 
pseudo-code):

if (foo == 1) jump @case1
else if (foo == 2) jump @case2
else jump @default

@case1
print("Case 1")
jump @end
@case2
print("Case 2")
// no jump because of fallthrough
@default
print("Default")
jump @end

@end

I don't know if that helps clear it up, but while syntactically a switch 
statement's cases are grouped with the code that they trigger, this is just 
because it's easier to work with; in reality the entire content of the switch 
is one contiguous run of code that you jump into (and possibly out of) as 
determined by some form of test at the start. The ability for a case to 
fallthrough (no jump to the end) means that it's possible to execute multiple 
cases, unlike an if-statement where only one branch is ever executed.

The lack of indentation is a good reminder that a case should be thought of 
more as a label, and that its condition is actually checked at the switch(foo) 
part of the construct.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] class indent in swift, history?

[Haravikk via swift-evolution]

> On 7 Mar 2017, at 15:24, Saagar Jha via swift-evolution 
>  wrote:
> 
> 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.

I'm not sure that it's Swift-specific, this just seems to be what Xcode does 
even if you're working in another language; I use Xcode to do PHP and 
Javascript as well (it's not the best for these but I already have it so it's 
an obvious choice), and it does the same thing for switch statements.

It's a matter of personal preference; personally I do indent switch cases but 
only if all of them are simple (i.e- the case and its content can be put on a 
single line without being too noisy looking), but if one or more of the cases 
are multi-line then I use the default (cases not indented, but contents are).

I think the point is that it's (sort of) one scope, since you can use the 
fallthrough keyword to process multiple cases if you want to, the switch and 
cases just determines at what point you dive into that scope.

It makes sense when you think about how switch statements actually execute; in 
essence the contents of each case are usually structured as one big lump of 
code, with jumps to break out of it once the case is complete. The switch 
itself is some form of conditional matching to pick which case is triggered, 
resulting in a jump to the correct location. While this is similar to how if 
statements work behind the scenes, you can't fall-through (only one branch is 
ever executed, never both).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Random

[Haravikk via swift-evolution]

> On 4 Mar 2017, at 06:58, Charlie Monroe via swift-evolution 
> > wrote:
> 
> While I am not against the idea, I believe that this is not as easy as one 
> would think as everyone has a different understanding of the word "random" as 
> most of random generators aren't "true" random generators.
> 
> I think this would ideally require a new protocol RandomGenerator which would 
> be passed to the collection to get the random element, i.e. it would look 
> something like:
> 
> arr.randomElement(using: ARC4RandomGenerator())
> 
> 
>> On Mar 4, 2017, at 6:55 AM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> This is a small improvement, but I still think it is worthwhile.
>> 
>> I would like to see an 'init(randomIn: Range)’ added to Numeric (where 
>> Comparable), which would return a random number in the given range.  It is 
>> something I have added myself to a subset of number types, but it really 
>> should be part of the standard library since there are a million small 
>> number types that have to be added individually, there are a couple of 
>> tricky edge cases to get right, and my version won’t work with Numeric types 
>> added by others.
>> 
>> I would also like to see a ‘randomElement’ method added to collection.  This 
>> is much easier to get right ourselves, but it comes up often enough in 
>> generic code that I still think it is a worthwhile addition…


I suppose the question is whether a default PRNG on numeric types is "good 
enough", since most developers just need some randomness, it doesn't matter how 
good it actually is. Anyone with stricter requirements shouldn't be using a 
black-box, default generator.

That said, my preference is to just keep a stable of useful generators and 
allow developers to choose their preference; if they want they can easily add a 
constructor via extension, or a factory method or whatever, in which case they 
have control over the default.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Random

[Haravikk via swift-evolution]

> On 4 Mar 2017, at 06:58, Charlie Monroe via swift-evolution 
>  wrote:
> 
> While I am not against the idea, I believe that this is not as easy as one 
> would think as everyone has a different understanding of the word "random" as 
> most of random generators aren't "true" random generators.
> 
> I think this would ideally require a new protocol RandomGenerator which would 
> be passed to the collection to get the random element, i.e. it would look 
> something like:
> 
> arr.randomElement(using: ARC4RandomGenerator())
> 
> 
>> On Mar 4, 2017, at 6:55 AM, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> This is a small improvement, but I still think it is worthwhile.
>> 
>> I would like to see an 'init(randomIn: Range)’ added to Numeric (where 
>> Comparable), which would return a random number in the given range.  It is 
>> something I have added myself to a subset of number types, but it really 
>> should be part of the standard library since there are a million small 
>> number types that have to be added individually, there are a couple of 
>> tricky edge cases to get right, and my version won’t work with Numeric types 
>> added by others.
>> 
>> I would also like to see a ‘randomElement’ method added to collection.  This 
>> is much easier to get right ourselves, but it comes up often enough in 
>> generic code that I still think it is a worthwhile addition…


I suppose the question is whether a default PRNG on numeric types is "good 
enough", since most developers just need some randomness, it doesn't matter how 
good it actually is. Anyone with stricter requirements shouldn't be using a 
black-box, default generator.

That said, my preference is to just keep a stable of useful generators and 
allow developers to choose their preference; if they want they can easily add a 
constructor via extension, or a factory method or whatever, in which case they 
have control over the default.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

[Haravikk via swift-evolution]

> On 28 Feb 2017, at 21:40, John McCall via swift-evolution 
>  wrote:
> 
> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. The problem it addresses is an almost daily annoyance when working with 
collections!

> Does this proposal fit well with the feel and direction of Swift?
Yes. In fact it removes the need for some very ugly workarounds that are 
currently in use within stdlib (and aren't full workarounds anyway).

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Been following the subject for a while, quick re-read of the latest proposal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Haravikk via swift-evolution]

> On 27 Feb 2017, at 19:09, Jose Cheyo Jimenez  wrote:
> 
>> 
>> On Feb 27, 2017, at 9:59 AM, Haravikk > > wrote:
>> 
>> 
>>> On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution 
>>> > wrote:
>>> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
>>> > wrote:
>>> 
 I suggest to take a look at the topics "Variadics as an Attribute" and 
 "array splatting for variadic parameters" and 
 https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
  
 .
 
 This is basically the other way round (arrays would accept variadic 
 arguments), but it has the same effect — and more:
 You get rid of the odd "…" type, and it's also possible to use this with 
 types besides array (set, iterator….)
>>> I agree with getting rid of the Type... because we could use ... in slicing 
>>> (see String manifesto). Why must it be an attribute and not just "*" ? The 
>>> advantage I see is that this will play great in also deconstructing 
>>> collection like things like Array, Slice and Tuple. This is already 
>>> familiar to python and ruby users. 
>> 
>> Part of the aim is to avoid less easily discovered custom syntax; the point 
>> of the proposal is that there's no need for a special syntax just to support 
>> variadics as attributes already exist, plus they're more descriptive about 
>> what they do and easy to look-up.
> 
> 
> These is very unfortunate as a solution for “spreading” a collection or tuple 
> so that It can be applied to function taking a variadic.
> It makes sense on the declaration site but not on the call site. 
> 
> someFunc(@nonVariadic [1])  
> someFunc(@variadic [1]) 

These are only required in the case that a function accepts arguments of type 
Any; since both the array itself, and its contents are valid example of Any. 
This isn't the case if the variadic is on any other type.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Haravikk via swift-evolution]

> On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
> > wrote:
> 
>> I suggest to take a look at the topics "Variadics as an Attribute" and 
>> "array splatting for variadic parameters" and 
>> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
>>  
>> .
>> 
>> This is basically the other way round (arrays would accept variadic 
>> arguments), but it has the same effect — and more:
>> You get rid of the odd "…" type, and it's also possible to use this with 
>> types besides array (set, iterator….)
> I agree with getting rid of the Type... because we could use ... in slicing 
> (see String manifesto). Why must it be an attribute and not just "*" ? The 
> advantage I see is that this will play great in also deconstructing 
> collection like things like Array, Slice and Tuple. This is already familiar 
> to python and ruby users. 

Part of the aim is to avoid less easily discovered custom syntax; the point of 
the proposal is that there's no need for a special syntax just to support 
variadics as attributes already exist, plus they're more descriptive about what 
they do and easy to look-up.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 25 Feb 2017, at 01:25, Robert Bennett via swift-evolution 
>  wrote:
> 
>> Sorry, that turned into a bit of a rant, though hopefully a constructive 
>> one. I wasn't directing this at you in particular; I just wanted to properly 
>> get those points across.
> 
> No worries at all, we're all working towards the same goal here.
> 
> While I agree that the current proposals feel heavy, equally heavy is 
> creating an entire type, a one-case enum, for the sake of one function. It 
> may fit into the current language design but it is not (IMO) nice by any 
> means. I'm also not a huge fan of the existing proposals, including my own 
> dollar-sign proposal. But I would like to see some version of this added to 
> the language because it does feel awkward to have to rearrange the sentence 
> structure of a function to fit Swift's syntax. Just as ending a sentence with 
> a preposition is something up with which some people won't put, but which is 
> nevertheless useful to avoid awkward sentence structure, I'd prefer not to 
> have to rearrange the English sentence structure of a sentence to comply with 
> Swift's syntactical rules — I'd like to avoid the awkwardness. So I'll throw 
> one more idea out there.
> 
> Older versions of Swift used # to indicate "special" behavior regarding 
> parameter labels. Since that use has been deprecated, maybe we could 
> resurrect # for trailing argument labels — in theory, for any positional 
> argument labels, but one step at a time. This would also fit nicely with the 
> current use of #selector, since when used for trailing arguments, # would 
> *select* the function.
> 
> // Define
> func adding(_ other: Self) // default behavior
> func adding(_ other: Self, #reportingOverflow)) // overflow reported
> 
> // Call
> x.adding(y)
> x.adding(y, #reportingOverflow)
> 
> // Selectors
> #selector(adding(_:))
> #selector(adding(_:, #reportingOverflow))

Looks like you've unintentionally split off into a separate topic, which may 
make things a bit confusing.

As you say, some kind of syntax is required for disambiguation, as doing 
without would mean relying on IDE support for label highlighting, which we've 
agreed in the past shouldn't be necessary (i.e- the language should work just 
as well in a black and white text-editor).

I'm not sure that the dollar sign is the right choice though, as it still 
implies a variable due to its usage in closures (where it could still become 
ambiguous), and just historically in other languages as well. A hash does make 
a bit more sense, but it's the symbol for compiler directives so it again does 
lead to potential ambiguity as #reportingOverflow isn't a known directive.

Did you see the discussion between myself and Vladimir S. on the subject? He 
proposed using a leading colon instead, as it's part of the syntax for labels 
already, but by making it a leading symbol it's unambiguous. Like-so:

x.adding(y, :reportingOverflow)

However, he also suggested another syntax which I've found quite interesting, 
which is to think of it more like a trailing method label (rather than an 
argument label), like so:

func adding(_ other:Self):reportingOverflow -> (Self, Bool)
x.adding(y):reportingOverflow

I quite like this alternative, but you have to think of it in terms of 
selecting return values. Basically, after you've typed x.adding(y) you've 
selected all adding(Self) methods of x, but haven't yet chosen a specific one 
until you either hit colon and add the trailing label, or move onto a new line 
(leaving it as the default method).

Ultimately though the question that really needs answered on the subject is; do 
people prefer the idea of using labels to select methods, or are they happy 
with elongated method names (such as addingWithOverflow)? If most people favour 
the latter then there's not much point in adding the feature, but if people 
like the idea of having grouped methods with identical names then it's a worthy 
addition, personally I like it, and I assume you do too, but it requires broad 
support to justify it.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

[Haravikk via swift-evolution]

> On 24 Feb 2017, at 02:05, Ben Cohen via swift-evolution 
>  wrote:
> 
> Regarding the question of the trailing argument to distinguish 
> overflow-checking vs expanding versions of multiplied: rather than add an 
> enum or use the void trick in order to do this via arguments, it is better to 
> just distinguish the two functions via different base names.

Regarding trailing arguments, any chance we could get you to weigh in on on the 
"Allow trailing argument labels" discussion?
Personally I like the idea of using the trailing arguments, but not having to 
use enums to do it; a proper language feature could make it more viable. One 
variation discussion could for example looking like:

let result = a.adding(b):reportingOverflow

Think of the trailing "argument" as a kind of selector, telling Swift which 
specific version of the adding method you want to invoke. I prefer this to 
elongated method names, but maybe others wouldn't.

If there's appetite for that style though then it would make sense to implement 
the language feature first, rather than creating inconsistencies now.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 23 Feb 2017, at 18:25, Vladimir.S  wrote:
> Weird idea, why not have function name just after arguments block, without 
> any separator:
> 
> func adding(_ other:Self) -> Self
> func adding(_ other:Self)reportingOverflow -> (Self, Bool)
> 
> let resultOnly = a.adding(b)
> let resultReportingOverflow = a.adding(b)reportingOverflow

Interesting, but personally I think it's less clear than with the colon 
separating it further.

> But again, I *do* believe such syntax improvements will not be approved by 
> core team(and most likely by the community). Is it worth to discuss this?

I think if there's going to be a proposal then it helps to have hashed out some 
of the syntax at least, but yeah, I suppose the key point is whether the 
feature is significant enough to warrant support. Personally I'm heavily in 
favour, as I dislike verbose naming and really like the idea of grouped 
functions being identically named. After all, in the case of protocol oriented 
integers the adding examples are both an addition operation, all that really 
differs is the type of result you want from it.

The question I suppose might partly come down to naming convention though; do 
people like the convention of using a "selector" to narrow the method, versus 
differently (but otherwise very similarly) named methods. I like how clean just 
having functions named "adding" is, with the option to narrow to a specific one 
other than the default, but others may prefer more verbose method names, in 
which case the feature isn't really needed, if that's the majority view.

I just like that if a group of methods all have the same name it is absolutely 
clear that they are closely related. The trade-off perhaps however is that 
narrowing down the choice comes later, whereas using the method name means 
narrowing down of auto-correct happens right away.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 23 Feb 2017, at 12:49, Vladimir.S  wrote:
> 
> On 23.02.2017 14:17, Haravikk wrote:
>> 
>>> On 22 Feb 2017, at 21:25, Patrick Pijnappel >> > wrote:
>>> 
>>> To summarize, there's one ambiguous case we'd need to resolve:
>>> 
>>> func foo(_ x: Int, reportingOverflow)
>>> func foo(_ x: Int, _ reportingOverflow: Bool)
>>> 
>>> let reportingOverflow = true
>>> foo(5, reportingOverflow) // Ambiguous
>>> 
>>> One solution is to make trailing argument labels syntactic sugar for a
>>> trailing void argument.
>>> That would allow breaking ambiguity by specifying it explicitly:
>>> 
>>> foo(5, reportingOverflow: ())
>>> 
>>> A related issue is the call-site ambiguity for the reader (less of a
>>> problem if Xcode highlighted argument labels).
>> 
>> Vladimir suggested that an alternative might be to use a leading colon to
> 
> There is another alternative I can think of, based on feature that was 
> discussed at some point of time the list: anonymous enums, i.e. when you can 
> declare enum inside function declaration, when such enum has almost no 
> meaning outside of the function call.
> 
> I.e. something like this:
> 
> func foo(_ x: Int, with: (.reportingOverflow))
> 
> foo(10, with:.reportingOverflow)
> 
> I.e. you can have more than one enum case here if you want:
> func foo(_ x: Int, with: (.reportingOverflow, .otherFlag))
> // IIRC, such syntax was discussed:
> // func foo(_ x: Int, with: (.reportingOverflow | .otherFlag))
> 
> foo(10, with:.otherFlag)
> 
> But such anonymous enums were considered as bad idea during the discussion, 
> so…

Yeah, I was one of the ones who liked the idea but it never seemed to get much 
traction unfortunately.

Part of the problem though with using enums to select methods is that it's not 
immediately obvious what they're doing; if you look at the signature for a 
method you see a type, then have to investigate what it is and find it only has 
one case, which is confusing. Documentation then needs to fill in all the gaps 
to explain that it will only ever have one case (e.g- it's not an enum that may 
be expanded with more options in future), and that's it's for selecting 
methods. A single-case ad-hoc enum could be a bit clearer, but it's still more 
of a workaround.

I think having a proper language feature is still the way to go, as it can be 
more obvious at the function declaration that it's something different, since 
it would be an untyped parameter.

You mentioned another possibility of putting the extra label after the 
function, and I've been thinking about that as well, because the interesting 
thing about that is it could be thought of as a kind of label on the return 
type.

func adding(_ other:Self) -> Self
func adding(_ other:Self):reportingOverflow -> (Self, Bool)

let resultOnly = a.adding(b)
let resultReportingOverflow = a.adding(b):reportingOverflow

You did say it looks a bit like an operation on the result, but I suppose 
another way of thinking about it is that until you set (or omit) 
:reportingOverflow then you're actually calling *both* methods with two 
possible results, and by adding that you tell Swift which one you want. It 
could be a very neat thing to use as well within modern auto-complete; type out 
the method at which point you can either hit space to move onto something else, 
hit period to call a method on the result, or hit colon to narrow down the 
result to something more specific.

Ack, I think I'm confusing myself now as to which solution I prefer. Having the 
trailing label *after* the function call does have merits as well.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 22 Feb 2017, at 21:25, Patrick Pijnappel  
> wrote:
> 
> To summarize, there's one ambiguous case we'd need to resolve:
> 
> func foo(_ x: Int, reportingOverflow)
> func foo(_ x: Int, _ reportingOverflow: Bool)
> 
> let reportingOverflow = true
> foo(5, reportingOverflow) // Ambiguous
> 
> One solution is to make trailing argument labels syntactic sugar for a 
> trailing void argument.
> That would allow breaking ambiguity by specifying it explicitly:
> 
> foo(5, reportingOverflow: ())
> 
> A related issue is the call-site ambiguity for the reader (less of a problem 
> if Xcode highlighted argument labels).

Vladimir suggested that an alternative might be to use a leading colon to 
indicate that the label is for selecting a function only, which would solve the 
ambiguity issues. Of course this means it's much the same as using the single 
enum case trick, but at least this way it'd still be a proper language feature 
rather than a workaround, and no extra types are declared just to support it.

So you'd have something like:

func foo(_ x:Int, :reportingOverflow) { … }
func foo(_ x:Int, _ reportingOverflow:Bool) { … }

let reportingOverflow = true
foo(5, reportingOverflow) // Calls the second declaration of foo using 
the boolean argument
foo(5, :reportingOverflow) // Calls the first declaration of foo

It's still a little subtle, but the single-case enum that this feature would 
replace has the exact same problem. So long as the label is sufficiently 
descriptive it shouldn't be a very likely target for a naming collision.

I think the leading colon alternative is probably the one I'd favour, as a 
plain argument label probably isn't clear enough, so having an indicator is 
better overall. It means that as a feature it won't have any advantages over 
the single-case enum, except that you don't have to declare an unnecessary 
extra type (which needs to be documented somehow), so I think it's still worth 
having to make this capability part of the function signature proper.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 22 Feb 2017, at 15:38, Vladimir.S  wrote:
> Do I understand correctly, that the proposed solution is some kind of sugar 
> to not have separate method named like 'addingWithReportingOverflow' ?

Basically yes; the discussion came up briefly during protocol oriented integers 
where this is quite common, especially with added methods for handling 
double-width operations and such as well.

> In any case IMO such argument label should have special syntax on caller 
> site.. don't know, probably:
> 
> let resultWithOverflow = a.adding(b, :reportingOverflow)
> 
> probably with the same declaration:
> func adding(_ other:Self, :reportingOverflow) -> (Self, Bool)

Huh, that could be a great alternative! It would solve the ambiguity issues 
completely and allow for even single argument cases (if someone wanted to use 
those).
Any preferences on how to specify these arguments? e.g- just declare them void, 
attribute or something else?

Also apologies to Patrick, I seem to be leading his discussion, I really should 
get some work done! ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 22 Feb 2017, at 15:38, Vladimir.S  > wrote:
> Do I understand correctly, that the proposed solution is some kind of sugar 
> to not have separate method named like 'addingWithReportingOverflow' ?

Basically yes; the discussion came up briefly during protocol oriented integers 
where this is quite common, especially with added methods for handling 
double-width operations and such as well.

> In any case IMO such argument label should have special syntax on caller 
> site.. don't know, probably:
> 
> let resultWithOverflow = a.adding(b, :reportingOverflow)
> 
> probably with the same declaration:
> func adding(_ other:Self, :reportingOverflow) -> (Self, Bool)

Huh, that could be a great alternative! It would solve the ambiguity issues 
completely and allow for even single argument cases (if someone wanted to use 
those).
Any preferences on how to specify these arguments? e.g- just declare them void, 
attribute or something else?

Also apologies to Patrick, I seem to be leading his discussion, I really should 
get some work done! ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 22 Feb 2017, at 13:19, Derrick Ho  wrote:
> 
> I've read the pitch, but it isn't clear what the ask is or what benefit it 
> would give.

The purpose of the feature is to enable selection of identically named methods 
with similar signatures. This came up in the protocol-oriented integers debate 
on the ability to have arithmetic methods with and without overflow. Like so:

protocol IntegerArithmetic {
func adding(_ other:Self) -> Self
func adding(_ other:Self, reportingOverflow) -> (Self, Bool)
}

var a = 2, b = 3
let resultWithoutOverflow = a.adding(b)
let resultWithOverflow = a.adding(b, reportingOverflow)

Here we have two different methods, one reporting overflow and one without, 
using the label to enable selection, rather than having to have an 
addingWithOverflow() method or similar.

Currently the alternative is to do something like:

enum ReportingOverflow { case .reportingOverflow }
protocol IntegerArithmetic {
func adding(_ other:Self) -> Self
func adding(_ other:Self, _) -> (Self, Bool)
}

var a = 2, b = 3
let resultWithoutOverflow = a.adding(b)
let resultWithOverflow = a.adding(b, .reportingOverflow)

Basically the ability to use the label for method selection is an alternative 
to either defining an enum as above, or having to use a different method name.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 22 Feb 2017, at 11:48, Brent Royal-Gordon <br...@architechies.com> wrote:
> 
>> On Feb 22, 2017, at 3:32 AM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>  foo.example(foo) // What did I mean here?
>>  let result = foo.example(foo:) // This looks like I might be trying to 
>> select a function, rather than call it
> 
> I think it would be really weird to support not one, but *two* potentially 
> ambiguous sugar forms.

Those aren't examples I think should be supported, I was thinking out loud. The 
point I was trying to make is that it's not the trailing nature that's a 
requirement, but that the real requirement for this feature to work is that 
there's at least one other, non-Void argument.


On another note, one other alternative I did think of for declaration is that 
perhaps it might be better still to use an attribute to specify a label-only 
"argument". Think of it like an attribute on the type, except that it specifies 
that there is no type:

func adding(_ other:Self, reportingOverflow:@labelonly) { … }

The attribute makes it absolutely clear that this is just a label and not an 
actual, functional argument (there won't be a reportingOverflow local 
variable), and that it can be passed without a value when calling this method. 
It'll still need the trailing colon for possible disambiguation of variables 
though.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

[Haravikk via swift-evolution]

> On 22 Feb 2017, at 10:24, Patrick Pijnappel via swift-evolution 
>  wrote:
> 
> I'd like to discuss allowing a trailing 'argument label' without an actual 
> argument:
> 
> func adding(_ other: Self, reportingOverflow) -> … // Actual case in SE-104 
> where this came up
> func tableView(_ tableView: UITableView, numberOfSections) -> Int // 
> Referenced as tableView(_:numberOfSections)
> 
> As illustrated above, the way we reference functions extends very naturally 
> to include these.
> 
> This would be very useful for several cases:
> • Delegate methods, which currently all start with the same prefix, except 
> for some odd cases that really actually just needed a trailing argument label.
> • Cases where the function is a more specialized version of one with the same 
> name, but can't use a flag because the return type is different (e.g. 
> reportingOverflow), or the extra flag check is just undesirable. The standard 
> library now uses some workarounds to achieve this (e.g. having a trailing 
> argument of type void).
> • Function names that just work more naturally with some additional words 
> after the last argument. If we allow trailing argument labels, you can form 
> any sentence, rounding out the syntax. 
> 
> Overall, I think this could be the final missing piece to complete Swift's 
> functions-as-sentences approach.

I'm a +1 for this.

I think the best way to define it though would be to use Void arguments, and 
simply eliminate the need to add :() to call them if they are trailing. We 
should however retain the ability to add the colon for disambiguation.

Some examples to illustrate:

struct Foo { func adding(_ other:Foo, reportingOverflow:Void) { … } }
var a = Foo(), b = Foo()

a.adding(b, reportingOverflow) // Trailing Void argument doesn't 
require a value, so :() can be omitted

let reportingOverflow = "I don't know why I defined this"
a.adding(b, reportingOverflow) // This is now ambiguous thanks to my 
stupidly named variable
a.adding(b, reportingOverflow:) // However, this isn't, thanks to the 
colon clarifying that it's a label

It's possible the feature doesn't have to be restricted to only trailing 
arguments; the key is the ambiguity due to variable names and/or function 
selection. For example:

struct Foo { func example(foo:Void) -> String { … }}
var foo = Foo()

foo.example(foo) // What did I mean here?
let result = foo.example(foo:) // This looks like I might be trying to 
select a function, rather than call it

So it's possible it could be allowed for any function that has at least one 
non-Void argument?

I think to really seal the deal it would be nice if Xcode would highlight 
argument labels differently, as that would make it clearer to user's what 
something is at a glance, but that's a separate issue.

Just some thoughts; I do prefer this to using single case enums just to create 
a different method signature. Labels are definitely the right way to do this. 
The main thing for me is that I think we should keep the requirement to specify 
the type in the function declaration as Void, just for clarity.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

[Haravikk via swift-evolution]

> On 20 Feb 2017, at 15:25, Ross O'Brien  wrote:
> Does 'private(module, type)' grant get-set access to external subclasses, or 
> get-only?

Without a specific set condition it'd be both get and set for both. So you 
might need to do for example:

private(module, set:type) func someMethod() { … }

Though this may be assuming that set always implies get; I'm not sure if 
there's a need for set-only access restrictions, as any example I can think of 
that might need it can be handled by a method specifically for that purpose.

> If I write 'private(file, type)' is the property accessible only to types 
> within the module, or outside as well?

The property would be accessible anywhere in the same file, as well as 
accessible to any sub-class both in the module and externally.

Are you asking whether it'd be possible to restrict the external access of 
type? This might be an argument for allowing the type parameter on both private 
and public perhaps? So if you want external access to sub-classes you'd do:

public(type) func someMethod() { … }

Whereas for internal access you'd do:

public(file, type) func someMethod() { … }

Or are there still cases that aren't covered? It's possible it's a bad example 
of something that can be added to the parameterised form in future, and maybe 
it is something that does still require its own keyword?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Discussion] fileprivate vs. private(file)

[Haravikk via swift-evolution]

So discussion of the exact naming convention for access modifiers has been 
discussed multiple times, especially when fileprivate was being introduced. 
It's now been a while since fileprivate was added, so we've all had more time 
to actually work with it, so I wanted to raise the discussion again to see what 
people now think.

Specifically, during the debate over access modifiers I really didn't like the 
propose fileprivate, as I don't like conjoined lower-case key-"words" (to me a 
keyword should always be a single word, I still don't like associatetype or 
typealias either, and neither does macOS' auto-correct ). And to be honest my 
opinion hasn't changed; if anything I hate it even more.

The proposal I preferred was to use only the public and private keywords and 
use parameters to provide greater specificity, like so:

public  as it is now
private(module) equivalent to internal, which is private to the current 
module/project
private(file)   equivalent to fileprivate
private(scope)  equivalent to current private

The actual parameters are up for debate, but I still feel this a lot clearer. I 
also generally prefer the parameterised version for several reasons:

Readability: I know not everyone will agree on this one, but I much prefer the 
separation to having conjoined keywords.
Fewer Keywords: Maybe I'm a keyword purist or something, but I just don't like 
having too many keywords in the language, especially four for what amounts to a 
single feature (access).
Extensibility: It is easier and cleaner to add more parameters in future. For 
example, private(type) could be an equivalent to protected access in other 
languages. It can also be used to more easily group external extension 
modifiers under public such as public(final), public(open) etc.

For setter-specific access it might look something like:

private(file:set) var someValue:Int = 0

I know it might not seem that important to some people, but this is one area of 
Swift's syntax that still bothers me, perhaps unreasonably so, but I don't get 
to pick what annoys me! I'd also seek to replace associatedtype and typealias 
(and any other conjoined keyword I've forgotten) but I haven't thought of any 
alternatives that I like for those yet.

Anyway, just wanted to discuss how others felt having used fileprivate and such 
for a while, and whether it's worth revisiting, or if I just have to live with 
it.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

[Haravikk via swift-evolution]

> On 20 Feb 2017, at 06:40, Niels Andriesse via swift-evolution 
>  wrote:
> 
> I'd like to discuss the possibility of treating the cases of a given enum as 
> if they are subtypes of that enum. This seems like a natural thing to do 
> because enum cases (especially when they have associated values) effectively 
> define a closed set of subtypes.
> 
> Doing so would allow for constructions such as the following:
> 
> enum Foo {
>   case a(name: String)
> }
> 
> func isA(foo: Foo) -> Bool {
>   // The old way:
>   if case .a = foo { return true }
>   return false
>   // The new way:
>   return foo is .a
> }
> 
> func printNameIfFooIsA(foo: Foo) -> Bool {
>   // The old way:
>   if case let .a(name) = foo {
> print(name)
>   }
>   // The new way (1):
>   if let a = foo as? .a {
> print(a.name )
>   }
>   // The new way (2):
>   if let name = (foo as? .a)?.name {
> print(name)
>   }
> }
> 
> Treating an enum's cases as its subtypes would make enums easier to work with 
> because handling them would be syntactically the same as handling other types.
> 
> The pattern matching capabilities of enums wouldn't be affected by this 
> proposal.
> 
> Multiple other proposals have already attempted to simplify enum handling 
> (they have particularly focused on getting rid of "if case" and adding the 
> ability to treat enum case tests as expressions), but none of the solutions 
> presented in those proposals have worked out so far.
> 
> I believe that this could be the right solution to multiple enum-related 
> problems that have been brought up repeatedly.

I really like the simplification of is/as here, since the leading dot should be 
clear enough and is consistent with other usages of enums.

Presumably this would apply even further though? For example, could I do:

func myMethod(_ something:Foo.a) -> Foo.a { … }

i.e- take and return only instances of Foo.a?

It should then also be possible for me to do:

let a:Foo = myMethod(Foo.a("test"))

In other words, Foo.a is a valid instance of Foo (but not vice versa without 
casting first)?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

[Haravikk via swift-evolution]

> On 18 Feb 2017, at 16:28, Matthew Johnson <matt...@anandabits.com> wrote:
> 
>> 
>> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> This is an idea I had while working with collections, and is particularly 
>>> inspired by those that use common index types.
>>> 
>>> Consider for example an array; for indices it simply uses an integer, 
>>> however, while this is a perfectly valid type to use it opens up the 
>>> possibility of integers from any number of different sources being passed 
>>> in by mistake and causing run-time errors. The same is true for wrapping 
>>> types that use AnyIndex, or really any type that uses Any* to hide 
>>> underlying types, as on the surface all AnyIndex instances give the 
>>> illusion of being compatible when they're not, and will only produce errors 
>>> at run-time when a conflict arises.
>>> 
>>> The idea to combat this is simple; a new attribute that can be applied to a 
>>> typealias, my working name is @unique, but there's probably a much better 
>>> name for it. When applied to a type-alias it indicates to the type-checker 
>>> that the type being aliased should be treated as a unique type outside of 
>>> the scope in which it is declared.
>> 
>> I've encountered the same problem in essentially the same place, so I'd like 
>> to see a solution too.
>> 
>> This sounds like a slight variation on what, in previous discussions, has 
>> been called `newtype`. IIRC, one of the reasons we've never done `newtype` 
>> is that it's not clear which features you want to bring over from the base 
>> type, or which types should be used for things like operators. (If you have 
>> `func + (lhs: Int, rhs: Int) -> Int`, you don't want `func + (lhs: Index, 
>> rhs: Index) -> Index`; you want `func + (lhs: Index, rhs: Int) -> Index`.)
>> 
>> I'd like to suggest a design that I don't think has been considered before. 
>> Currently, if the first type in an enum's inheritance clause is a concrete 
>> type, a set of magical behaviors occur:
>> 
>> * The enum is conformed to `RawRepresentable` with a `RawValue` of the 
>> concrete type.
>> * Each case is associated with a raw value, specified by a literal attached 
>> to the case.
>> * `init?(rawValue:)` and `var rawValue { get }` are automatically generated.
>> 
>> There is currently no equivalent for structs, but I suggest we add one.
>> 
>> If you say:
>> 
>>  struct Index: Int {}
>> 
>> This is automatically equivalent to saying:
>> 
>>  struct Index: RawRepresentable {
>>  var rawValue: Int
>>  init(rawValue: Int) { self.rawValue = rawValue }
>>  }
>> 
>> And a special rule is applied: You may not declare any other stored 
>> properties.
>> 
>> Additionally, for both `enum`s and `struct`s with raw types, I would suggest 
>> that, if you conform to a protocol which the raw type conforms to and then 
>> fail to fulfill its (non-defaulted) requirements, Swift should generate a 
>> member which forwards to the raw value's implementation. It might even be 
>> nice to do the same when an initializer, method, property, or subscript is 
>> declared without providing a body. This would make it easy to decide which 
>> functionality should be exposed and how it should be provided--and it would 
>> provide a partial way to fulfill the frequent request for syntactic sugar 
>> for `Equatable`, `Hashable`, and `Comparable` conformances. (I could imagine 
>> this being generalized later on.)
>> 
>> The main drawback I can see is that the `rawValue` could not be 
>> encapsulated, since the conformance to the public `RawRepresentable` 
>> protocol could not be made private. That might be acceptable in a 
>> convenience feature, or we might decide (perhaps for both `struct`s and 
>> `enum`s) that Swift should generate the members without actually conforming 
>> the type unless explicitly asked to.
> 
> A lot of this is very similar to the protocol-based forwarding proposal I 
> worked on last year.  That proposal would avoid the problems you describe 
> around not being able to properly encapsulate `RawRepresentable`.  It was 
> also able to handle many nuances around forwarding of self and associated 
> type requirements.  It even had an example of how something like `new

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

[Haravikk via swift-evolution]

> On 18 Feb 2017, at 10:54, Brent Royal-Gordon <br...@architechies.com> wrote:
> 
>> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> This is an idea I had while working with collections, and is particularly 
>> inspired by those that use common index types.
>> 
>> Consider for example an array; for indices it simply uses an integer, 
>> however, while this is a perfectly valid type to use it opens up the 
>> possibility of integers from any number of different sources being passed in 
>> by mistake and causing run-time errors. The same is true for wrapping types 
>> that use AnyIndex, or really any type that uses Any* to hide underlying 
>> types, as on the surface all AnyIndex instances give the illusion of being 
>> compatible when they're not, and will only produce errors at run-time when a 
>> conflict arises.
>> 
>> The idea to combat this is simple; a new attribute that can be applied to a 
>> typealias, my working name is @unique, but there's probably a much better 
>> name for it. When applied to a type-alias it indicates to the type-checker 
>> that the type being aliased should be treated as a unique type outside of 
>> the scope in which it is declared.
> 
> I've encountered the same problem in essentially the same place, so I'd like 
> to see a solution too.
> 
> This sounds like a slight variation on what, in previous discussions, has 
> been called `newtype`. IIRC, one of the reasons we've never done `newtype` is 
> that it's not clear which features you want to bring over from the base type, 
> or which types should be used for things like operators. (If you have `func + 
> (lhs: Int, rhs: Int) -> Int`, you don't want `func + (lhs: Index, rhs: Index) 
> -> Index`; you want `func + (lhs: Index, rhs: Int) -> Index`.)
> 
> I'd like to suggest a design that I don't think has been considered before. 
> Currently, if the first type in an enum's inheritance clause is a concrete 
> type, a set of magical behaviors occur:
> 
> * The enum is conformed to `RawRepresentable` with a `RawValue` of the 
> concrete type.
> * Each case is associated with a raw value, specified by a literal attached 
> to the case.
> * `init?(rawValue:)` and `var rawValue { get }` are automatically generated.
> 
> There is currently no equivalent for structs, but I suggest we add one.
> 
> If you say:
> 
>   struct Index: Int {}
> 
> This is automatically equivalent to saying:
> 
>   struct Index: RawRepresentable {
>   var rawValue: Int
>   init(rawValue: Int) { self.rawValue = rawValue }
>   }
> 
> And a special rule is applied: You may not declare any other stored 
> properties.
> 
> Additionally, for both `enum`s and `struct`s with raw types, I would suggest 
> that, if you conform to a protocol which the raw type conforms to and then 
> fail to fulfill its (non-defaulted) requirements, Swift should generate a 
> member which forwards to the raw value's implementation. It might even be 
> nice to do the same when an initializer, method, property, or subscript is 
> declared without providing a body. This would make it easy to decide which 
> functionality should be exposed and how it should be provided--and it would 
> provide a partial way to fulfill the frequent request for syntactic sugar for 
> `Equatable`, `Hashable`, and `Comparable` conformances. (I could imagine this 
> being generalized later on.)
> 
> The main drawback I can see is that the `rawValue` could not be encapsulated, 
> since the conformance to the public `RawRepresentable` protocol could not be 
> made private. That might be acceptable in a convenience feature, or we might 
> decide (perhaps for both `struct`s and `enum`s) that Swift should generate 
> the members without actually conforming the type unless explicitly asked to.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

Hmm, that's a very interesting alternative; it's a lot like what we have to do 
now ourselves anyway, plus more flexible overall. I still like the idea of 
being able to do something at the typealias itself purely for convenience, but 
that's something that could always come later.

For example:

typealias Index:Int // shorthand for struct IntIndex: Int {}, typealias 
Index = IntIndex

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

[swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

[Haravikk via swift-evolution]

This is an idea I had while working with collections, and is particularly 
inspired by those that use common index types.

Consider for example an array; for indices it simply uses an integer, however, 
while this is a perfectly valid type to use it opens up the possibility of 
integers from any number of different sources being passed in by mistake and 
causing run-time errors. The same is true for wrapping types that use AnyIndex, 
or really any type that uses Any* to hide underlying types, as on the surface 
all AnyIndex instances give the illusion of being compatible when they're not, 
and will only produce errors at run-time when a conflict arises.

The idea to combat this is simple; a new attribute that can be applied to a 
typealias, my working name is @unique, but there's probably a much better name 
for it. When applied to a type-alias it indicates to the type-checker that the 
type being aliased should be treated as a unique type outside of the scope in 
which it is declared.

For example:

struct MyCollection : Collection {
@unique typealias Index = Int
var startIndex:Index { return 0 }
…
}

var foo = MyCollection()
var bar = MyCollection()
foo[bar.startIndex] // warning: incompatible types

Although the underlying type is an Int for both collections, and Ints can be 
used internally to satisfy methods/properties of type Index (i.e- within 
MyCollection the concrete type is still Int), externally indices are treated as 
a unique type of MyCollection.Index, that just happens to have all the same 
methods, operators and properties as Int, minimising the risk of passing an 
index from the wrong source.

If you actually want to pass the "wrong" type you can still do it by casting:

foo[bar.startIndex as MyCollection.Index]

Bit verbose, but it makes absolutely clear that you want this to happen, rather 
than it happening by mistake. The same can also be done in reverse (to change 
an index to an Int).

Of course this isn't completely fool-proof, as two different instances of 
MyCollection could still confuse indices as they're of the same 
pseudo-type, but in other cases it reduces the possibility of a mistake. It was 
the recent discussion on the .enumerate() method that reminded me of this, as a 
common mistake is to think that the offsets produced by enumerate are indices, 
just because they happen to be compatible with an Array, this could eliminate 
that as a mistake by forcing developers to see what's actually happening.

Currently to do something like this requires duplicating types, or using 
wrappers around Int just to make it appear to be different; it's not hard as 
such but there's no standard for it, so making it easier and more prevalent is 
desirable.

This shouldn't have any implications to ABI compatibility as it's a 
type-checker only feature (the code should still compile exactly as the same is 
now), but it's a partially source-breaking change in that if Array etc. are 
changed to use this feature then any code relying on Array indices being 
integers will need to add a cast. Since the types are still known to be 
compatible though a mismatch needn't be an error, a warning should suffice, in 
which case the change won't actually prevent compilation of existing code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

[Haravikk via swift-evolution]

> On 18 Feb 2017, at 01:45, Joe Groff via swift-evolution 
>  wrote:
> 
>   • What is your evaluation of the proposal?

Solid +1, though like others I disagree with deprecating BitwiseOperations, and 
feel it should be integrated into the protocol hierarchy.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Definitely; interpretability of integers and some ambiguity with the types are 
weaknesses in Swift right now, so the improved design should make a big 
difference.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I've been keeping an eye on the discussion and skimmed the proposal again to 
hopefully catch any changes.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Haravikk via swift-evolution]

I like the idea of having pure functions in Swift, but my first thought is; 
should we have to declare it at all? Is it not easier to just have the compiler 
automatically flag a function as pure or not?

With that in mind we don't need any new syntax, but a simple @pure attribute 
should be sufficient. This can be used anywhere that a function is declared, or 
a closure is accepted as a parameter, allowing us to be explicit that we are 
trying to define a pure function, or only accept pure closures.

The big benefit of this is that it is retroactive; all existing functions that 
are pure will be automatically detected as such, and can be passed into any 
method accepting only pure functions. The new capability will be that 
developers can specify that a function *must* be pure and thus produce an error 
if it isn't.

> On 16 Feb 2017, at 17:03, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> # Pure Functions
> 
> * Proposal: 
> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
>  
> )
> * Author(s): [TJ Usiyan](https://github.com/griotspeak 
> )
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> Some functions are, essentially, only meant to be transformations of their 
> input and–as such–do not and should not reference any variables other than 
> those passed in. These same functions are not meant to have any effects other 
> than the aforementioned transformation of input. Currently, Swift cannot 
> assist the developer and confirm that any given function is one of these 
> 'pure' functions. To facilitate this, this proposal adds syntax to signal 
> that a function is 'pure'.
> 
> 'pure', in this context, means:
> 1. The function must have a return value
> 1. This function can only call other pure functions
> 1. This function cannot access/modify global or static variables.
> 
> ## Motivation
> 
> Consider the following example where `_computeNullability(of:)` is meant to 
> create its output solely based on the provided recognizer.
> 
> ```
> class Recognizer {
>   var nullabilityMemo: Bool?
>   var isNullable: Bool {
>   func _computeNullability(of recognizer: Recognizer) -> Bool {…}
>   if let back = nullabilityMemo {
>   return back 
>   } else {
>   let back =  _computeNullability(of: self)
>   nullabilityMemo = back
>   return back
>   }
>   }
> }
> ```
> if `_computeNullability(of:)` is recursive at all, there exists a real 
> potential to accidentally reference `self` in its body and the mistake, 
> depending on circumstance, can be terribly subtle. Converting 
> `_computeNullability(of:)` to a `static` function is an option but obfuscates 
> the fact that it is *only* to be called within `isNullable`.
> 
> 
> ## Proposed solution
> 
> Given the ability to indicate that `_computeNullability(of:)` is a 'pure' 
> function, the developer gains assurance from the tooling that it doesn't 
> reference anything or cause any side effects.
> 
> 
> ```
> class Recognizer {
>   var nullabilityMemo: Bool?
>   var isNullable: Bool {
>   pfunc _computeNullability(of recognizer: Recognizer) -> Bool {…}
>   if let back = nullabilityMemo {
>   return back 
>   } else {
>   let back =  _computeNullability(of: self)
>   nullabilityMemo = back
>   return back
>   }
>   }
> }
> ```
> 
> ## Detailed design
> 
> This proposal introduces a new annotation `=>`, which is to be accepted 
> everywhere `->` currently is. Members created using this kewyord must follow 
> the rules listed in the introduction.
> 
> ## Impact on existing code
> 
> This is an additive feature unless alternative 2 is chosen and, as such, 
> should not require an effect on existing code. It could be used to annotate 
> closures accepted by methods in the standard library such as `map`, `filter`, 
> and `reduce`. While this would fit well with their typical use, such a change 
> is not necessarily part of this proposal.
> 
> ## Alternatives considered
> 
> It should be noted that neither of these alternatives can remain consistent 
> for inline closures.
> 1. keyword `pfunc` (pronounciation: pifəŋk) for 'pure' functions. 
> 2. `proc` keyword for 'impure' functions and 'func' for 'pure' functions. 
> This would be a massively source breaking change and, as such, is unlikely to 
> have any feasibility. It is, however, the most clean semantically, in my 
> opinion.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Does protocol support add to an object's size?

[Haravikk via swift-evolution]

> On 15 Feb 2017, at 17:51, Daryle Walker via swift-evolution 
>  wrote:
> 
> I don't know how protocol support works. I asking because I want to maintain 
> the stride of an array being the total count times the stride of the element, 
> which would complicate nominal arrays if adding protocols to one breaks that. 

Short answer; no.

A protocol can't add stored properties, which are what determine the 
size/stride of a type; all they can add are computed properties and methods, 
neither of which are actually stored alongside the objects themselves.

Basically a type's size is memory required to store only the parts that are 
unique to that specific object (stored properties), all a protocol does is tell 
the compiler some operations you can perform, the actual code for which is 
stored elsewhere.

As Karl points out though the type's size isn't necessarily the full picture, 
as a store property can be a pointer to some other piece of memory such as an 
object (class, rather than struct) or to an unmanaged buffer and other 
constructs that are particularly useful for things like arrays.

Also, for future reference, questions like this are more appropriate to the 
swift-users mailing list; swift-evolution is intended more for language 
improvements, rather than general queries. Easy enough mistake to make though!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Dictionary Enhancements

[Haravikk via swift-evolution]

> On 17 Feb 2017, at 00:26, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi swift-evolution,
> 
> Add capacity property and reserveCapacity() method.

Just wanted to quickly weigh in on this one, but I wonder if this might make 
most sense coming as a slight restructuring of the collection protocols. It 
could for example make sense as an ExtendableCollection protocol, which could 
also take a general purpose add/insert method (in the case of Dictionary this 
would take a Key/Value pair), which I believe is something that's also lacking 
from Dictionary?

Basically it's a protocol representing a Collection whose contents can grow, 
but which places no guarantees over ordering. So unlike append() you're not 
guaranteed to have the new element under .last. It makes sense to group with 
capacity since you don't need capacity in something that can't expand in some 
way.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Haravikk via swift-evolution]

> On 15 Feb 2017, at 22:44, Nicolas Fezans via swift-evolution 
>  wrote:
> 
> > 3: maybe ~ is a better fit?
> 
> just for information this is in line with Matlab in which the following three 
> "not"-related syntax exist:
> a) ~ as a prefix operator for not
> b) not as a function
> c) ~= as an infix operator for "is not equal to"
> 
> I see pros and cons for each option and have a very slight preference for ~ 
> over !.
> 
> I would however avoid ¬ because I would not like to have a character that is 
> not directly accessible on most keyboards for something as simple as a not 
> operation, even if I like these maths notations very much.
> 
> If it would be decided to keep ! I could imagine that  adding syntax 
> coloration in code editors to make both uses of ! look a bit different would 
> help beginners and newcomers. This is more complicated to do than the typical 
> syntax coloration logic in text editors (syntax must be understood for doing 
> that), but this should not be a problem in Xcode.
> 
> If ~ would be preferred, I would recommend to continue accepting ! for one or 
> more versions of swift but with a warning recommending to change it (we do 
> not need to make a source breaking change when it is possible to continue 
> accepting it and to mark it as obsolete)

Tilde is already used in Swift for bit-flipping, though actually on a boolean 
type (if you treat it as 1-bit) bit-flipping and logical NOT are equivalent, 
and you can't use logical NOT an Ints at the moment anyway.
So tilde could be a good option, however the ~= operator also already exists in 
Swift for pattern matching, so couldn't be used as a replacement for !=, unless 
there's a better operator for pattern matching (personally I don't like using 
an operator for pattern matching at all but maybe that's just me).

>> On 15 Feb 2017, at 22:28, Derrick Ho via swift-evolution 
>> > wrote:
>> 
>> There is no need to change it
>> 
>> Since the context basically disambiguates the meaning of !
>> 
>> The next best thing is to compare it to false
>> 
>> (val == false) // same as !val
>> On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution 
>> > wrote:
>> If someone came with a nice syntax I’d be for this. I can’t imagine what 
>> that would be.
>> 
>> I doubt there is an alternate prefix or postfix operator that would pass 
>> muster, due to ‘!’ already meaning the appropriate thing in so many 
>> languages, and swift only supporting symbolic operators.
>> 
>> I can’t think of a method on boolean which would read properly either, e.g.
>> 
>>  if isValid.not() {…}
>> 
>> The closest I could think to a decent bike shed color would be a global 
>> function:
>> 
>>  if not(isValid) {…}
>> 
>> -DW
>> 
>>> On Feb 15, 2017, at 11:10 AM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
>>> So you've identified the problem, but what do you propose as a solution 
>>> here?  
>>> 
>>> It should be noted that a (non-stdlib) language-level answer to this 
>>> question has already been discussed and rejected 
>>> (https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html
>>>  
>>> ).
>>> 
>>> ~Robert Widmann
>>> 
>>> 2017/02/15 9:02、Sadiq via swift-evolution >> > のメッセージ:
>>> 
 Hello,
 
 I would like to suggest to change Logical NOT Operator from ! to something 
 else. 
 It will increase the readability of the code and will avoid any confusion 
 with the symbol used for force unwrapping of optional values. 
 It would be easier for new programmers to learn Swift as the first 
 language. 
 I don't understand the rational behind using the same operator for two 
 different purposes. 
 
 Thanks and Regards,
 Mohammad Sadiq
 ___
 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

Re: [swift-evolution] [Discussion] Variadics as an Attribute

[Haravikk via swift-evolution]

> On 15 Feb 2017, at 12:16, Adrian Zubarev <adrian.zuba...@devandartist.com> 
> wrote:
> 
> I gave the topic a down vote not because I don’t like the proposal, but 
> because I personally see variadics go into the direction of tuples. 
> Especially I’d love to see some more talk about tuples in combination of 
> generic variadics (see here: 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics
>  
> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics>).
> 
> There is a lot of design overlap. That is the reason why I think we should 
> vision variadics as a whole in its future rather than simply repaint … 
> postfix to a type annotation keyword @variadics. This will only close the 
> doors for some features we might want to add in a future version of Swift.
> 
This seems like an entirely separate feature to me; unless the intention is to 
go back to the old style of treating function arguments as a tuple I don't see 
why they should need to be related?

Variable-width tuples would still be compiled down to fixed widths at some 
point (based on the number of types you pass).
Variadic functions however are just syntactic sugar for passing an array, 
currently minus the ability to actually pass an array.

I don't think they're similar at all; repurposing of ellipsis to variadic 
generics/tuples isn't something I'm opposed to (though I still don't like the 
ambiguity with ranges), because to me it doesn't seem like an overlapping 
feature at all.

Put another way; variadic generics is a way to allow developers to specify 
multiple types and arbitrary-width tuples, variadic functions just let 
developers call a method without using square braces. Why does the latter 
warrant a unique syntax that effectively creates a special class of function 
lacking the ability to specify collection type?

> Am 15. Februar 2017 um 12:43:49, Haravikk via swift-evolution 
> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:
>> Immediate followup, but is there something wrong with the gmane site that 
>> we've been using to provide links to mailing list discussions?
>> I can't seem to get a list of recent topics so I can find out what the new 
>> discussion link should be.
>> 
>>> On 15 Feb 2017, at 11:38, Haravikk via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I'm posting this as a new discussion topic for my earlier proposal of 
>>> Variadics as an Attribute. I would have reused the old topic but I have no 
>>> idea how to do that on a mailing list once the messages are gone (I don't 
>>> keep them for long); I'm looking forward to the possible switch to 
>>> Discourse!
>>> 
>>> The idea behind the proposal is fairly simple; to do away with the current 
>>> unique syntax for declaring variadic functions/methods, while retaining the 
>>> ability to call methods in the same way. In other words, instead of 
>>> declaring a method with an ellipsis, you would declare it just like any 
>>> other method, but add the @variadic attribute, enabling the ability to call 
>>> it just like you would call a variadic now.
>>> 
>>> Since this isn't strictly a code-breaking change (existing code can be 
>>> converted automatically) I'm unsure of when to issue a new pull request, so 
>>> I'll stick with a discussion to hammer out any lingering issues with the 
>>> proposal for just now. Here it is:
>>> 
>>> https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md
>>>  
>>> <https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md>
>>> 
>>> Variadics as Attribute
>>> Proposal: SE- 
>>> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md>
>>> Author: Haravikk <https://github.com/haravikk>
>>> Status: Awaiting review
>>> Review manager: TBD
>>>  
>>> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md#introduction>Introduction
>>> 
>>> This proposal seeks to redesign the current, unique variadic function 
>>> declaration syntax to use an attribute instead, with a goal of unifying 
>>> standard and variadic function declarations.
>>> 
>>>  
>>> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md#motivation>Motivatio

Re: [swift-evolution] [Discussion] Variadics as an Attribute

[Haravikk via swift-evolution]

Immediate followup, but is there something wrong with the gmane site that we've 
been using to provide links to mailing list discussions?
I can't seem to get a list of recent topics so I can find out what the new 
discussion link should be.

> On 15 Feb 2017, at 11:38, Haravikk via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I'm posting this as a new discussion topic for my earlier proposal of 
> Variadics as an Attribute. I would have reused the old topic but I have no 
> idea how to do that on a mailing list once the messages are gone (I don't 
> keep them for long); I'm looking forward to the possible switch to Discourse!
> 
> The idea behind the proposal is fairly simple; to do away with the current 
> unique syntax for declaring variadic functions/methods, while retaining the 
> ability to call methods in the same way. In other words, instead of declaring 
> a method with an ellipsis, you would declare it just like any other method, 
> but add the @variadic attribute, enabling the ability to call it just like 
> you would call a variadic now.
> 
> Since this isn't strictly a code-breaking change (existing code can be 
> converted automatically) I'm unsure of when to issue a new pull request, so 
> I'll stick with a discussion to hammer out any lingering issues with the 
> proposal for just now. Here it is:
> 
> https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md
>  
> <https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md>
> 
> Variadics as Attribute
> 
> Proposal: SE- 
> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md>
> Author: Haravikk <https://github.com/haravikk>
> Status: Awaiting review
> Review manager: TBD
> 
>  
> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md#introduction>Introduction
> 
> This proposal seeks to redesign the current, unique variadic function 
> declaration syntax to use an attribute instead, with a goal of unifying 
> standard and variadic function declarations.
> 
> 
>  
> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md#motivation>Motivation
> 
> Variadics are essentially a call-site feature enabling a function to be 
> called as if it is being provided with multiple arguments, rather than a 
> single list argument. However instead of being implemented as some kind of 
> switch, variadics have a unique declaration syntax that separates them 
> uncessarily from standard function declarations. Currently this also means 
> that redundancy is required in order to allow a function to be called both 
> with an explicit array, and in the variadic style.
> 
> 
>  
> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md#proposed-solution>Proposed
>  solution
> 
> To unify both regular and variadic function declarations this proposal seeks 
> to replace the unique trailing elipsis declaration syntax with a new 
> @variadic attribute on regular function declarations, enabling optional 
> variadic syntax at the call site.
> 
> In short this proposal would replace:
> 
> func someFunc(_ values:Int...) { … }
> With the following:
> 
> func someFunc(_ values:@variadic [Int]) { … }
> 
>  
> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md#detailed-design>Detailed
>  design
> 
> The trailing elipsis declaration syntax will be removed, with a fixit 
> providing a replacement to the new attribute-based syntax. The new @variadic 
> attribute can be placed on any one function parameter with a type of 
> Array (or [Foo]), enabling the optional use of variadic declaration at 
> the call site.
> 
> For example:
> 
> func someFunc(_ values:@variadic [Int]) { … }
> Can be called in any of the following forms:
> 
> someFunc(1, 2, 3, 4, 5)   // Fixed length variadic call
> someFunc([1, 2, 3, 4, 5]) // Fixed length array call
> someFunc(foo) // Dynamic array call passing the Array variable foo
> 
>  
> <https://github.com/Haravikk/swift-evolution/blob/master/proposals/-variadics-as-attribute.md#advantages>Advantages
> 
> Unifies standard and variadic function declarations, eliminating a unique 
> syntax that is arguably unnecessary.
> The type of the variadic parameter is absolutely explicit.
> Enables calling of a variadic function with dynamic arrays, without the need 
> for additional special syntax.
> No redundant overloads to enable

[swift-evolution] [Discussion] Variadics as an Attribute

[Haravikk via swift-evolution]

I'm posting this as a new discussion topic for my earlier proposal of Variadics 
as an Attribute. I would have reused the old topic but I have no idea how to do 
that on a mailing list once the messages are gone (I don't keep them for long); 
I'm looking forward to the possible switch to Discourse!

The idea behind the proposal is fairly simple; to do away with the current 
unique syntax for declaring variadic functions/methods, while retaining the 
ability to call methods in the same way. In other words, instead of declaring a 
method with an ellipsis, you would declare it just like any other method, but 
add the @variadic attribute, enabling the ability to call it just like you 
would call a variadic now.

Since this isn't strictly a code-breaking change (existing code can be 
converted automatically) I'm unsure of when to issue a new pull request, so 
I'll stick with a discussion to hammer out any lingering issues with the 
proposal for just now. Here it is:

https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md

Variadics as Attribute

Proposal: SE- 

Author: Haravikk 
Status: Awaiting review
Review manager: TBD

 
Introduction

This proposal seeks to redesign the current, unique variadic function 
declaration syntax to use an attribute instead, with a goal of unifying 
standard and variadic function declarations.


 
Motivation

Variadics are essentially a call-site feature enabling a function to be called 
as if it is being provided with multiple arguments, rather than a single list 
argument. However instead of being implemented as some kind of switch, 
variadics have a unique declaration syntax that separates them uncessarily from 
standard function declarations. Currently this also means that redundancy is 
required in order to allow a function to be called both with an explicit array, 
and in the variadic style.


 
Proposed
 solution

To unify both regular and variadic function declarations this proposal seeks to 
replace the unique trailing elipsis declaration syntax with a new @variadic 
attribute on regular function declarations, enabling optional variadic syntax 
at the call site.

In short this proposal would replace:

func someFunc(_ values:Int...) { … }
With the following:

func someFunc(_ values:@variadic [Int]) { … }

 
Detailed
 design

The trailing elipsis declaration syntax will be removed, with a fixit providing 
a replacement to the new attribute-based syntax. The new @variadic attribute 
can be placed on any one function parameter with a type of Array (or 
[Foo]), enabling the optional use of variadic declaration at the call site.

For example:

func someFunc(_ values:@variadic [Int]) { … }
Can be called in any of the following forms:

someFunc(1, 2, 3, 4, 5)   // Fixed length variadic call
someFunc([1, 2, 3, 4, 5]) // Fixed length array call
someFunc(foo) // Dynamic array call passing the Array variable foo

 
Advantages

Unifies standard and variadic function declarations, eliminating a unique 
syntax that is arguably unnecessary.
The type of the variadic parameter is absolutely explicit.
Enables calling of a variadic function with dynamic arrays, without the need 
for additional special syntax.
No redundant overloads to enable both call styles (one declaration provides 
both).
Enables further extension to support more collection types now or in future 
(see Proposed Extension below).
Moves the variadic feature declaration from syntax into the attributes list, 
which should aid discoverability (and simplify syntax very slightly).
The attribute is more explicit about what it does (provides a name that can be 
searched).

 
Ambiguity

One technical issue with this change is the introduction of ambiguity as 
follows:

someFunc(_ values:@variadic [Any]) { … }
someFunc([1]) // Is this an array call of [1] or a variadic call of [[1]]?
someFunc(foo) // If foo is an array, is this an array call of foo, or a 
variadic call of [foo]?
However, this issue is only exhibited when the type of variadic is Any (or 
another type that can represent both an array of elements and the elements 
themselves) and only when there is 

Re: [swift-evolution] array splatting for variadic parameters

[Haravikk via swift-evolution]

> On 14 Feb 2017, at 20:43, Anton Zhilin via swift-evolution 
>  wrote:
> 
> 2017-02-14 18:32 GMT+03:00 Dimitri Racordon via swift-evolution 
> >:
> 
> 
> 
> The proposal is indeed really interesting.
> I would love to see if it could get a second round of discussion.
> 
> However, I failed to understand the syntax of the proposed extension. Where 
> would be defined the label and parameter names? Is this just a typo?
> 
> func someFunc 
> 
> “Obviously”, the Collection variant should look like:
> 
> func someFunc(_ values: 
> @variadic C) { … }
> And the others are analagous.
> 

Thanks for the correction, not entirely sure how that mistake made it into the 
proposal!

I didn't get an especially positive response to the proposal at the time, but 
it is still very much my preferred solution.


"Splatting" as the OP suggests is a simpler solution, but leaves variadics 
limited to a unique syntax with no control over type; I'm also not keen on 
re-using ellipsis as an operator for it, since it's also used for handling 
ranges, though that's not a major overlap. But still, part of why I made my 
proposal is that splatting feels more like a workaround to a problem of there 
not being a proper array/sequence/etc. signature for the function.

I could of course be biased, but then I've never really supported variadics as 
a feature in the first place ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution