Re: [swift-evolution] [Proposal] Custom operators

[David Waite via swift-evolution]

Interesting model!

If I understand correctly: this changes the precedence from being based on a 
numeric value, to being represented as a bit of a DAG of precedence groups. A 
precedence group is defined implicitly for each operator, with one group around 
each set of operators where equalTo has been declared.

The groups are lazily evaluated, so if an expression can be resolved without 
ambiguity due to lack of reachability between two individual operators in the 
DAG, there is no issue/error.

Comments:
- I wonder if there are cases in the standard operators which would be better 
modeled as a non-linear chain.  The compiler could warn around usage which is 
defined by operator precedence, but is commonly considered ambiguous or error 
prone. 

For example, if users commonly get confused about the conjunctive and 
disjunctive levels (logical ‘and’ and ‘or’) being different levels with 
precedence, you could just omit the lessThan relationship between the two of 
them. The compiler would then error on ambiguous cases, prompting the user to 
use parenthesis.

- I’d prefer instead of operator precedence groups just being implicit by use 
of #precedence equalTo, that the operators are bound to a group explicitly. 
Something like
#precedence(+, group: “additive”)
#precedence(“additive”, lessThan: “multiplicative”)

However, this may create more issues than it solves (two frameworks creating 
their own custom operators, putting them in custom precedence groups, and the 
consumer decides the two precedence groups are really equivalent)

-DW

> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators. I 
> insist that this time we should focus less on linguistic aspects.
> 
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Andrey Tarantsov via swift-evolution]

> I'd prefer a more general solution instead of introducing the notion of an 
> "optional" function: just make it possible to write default implementations 
> inline in a protocol definition. 

This would work, too. I guess there's no need for an “optional” keyword if the 
implementation is right there in the protocol declaration.

A.

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Thorsten Seitz via swift-evolution]

I think Michel and Shawn did raise some good points here.

-Thorsten 

> Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution 
> :
> 
>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution 
>>  wrote:
>> > What is your evaluation of the proposal?
>> 
>> I don't like "form" as a prefix. To me there is no difference between 
>> `union` and `formUnion`: both sounds functional-style, and actually the 
>> second one perhaps a bit more to my ears. There's basically two dictionary 
>> definitions of "form":
>> 
>> 1. "bring together parts or combine to create (something)" which to me 
>> implies a new value is created, and
>> 2. "make or fashion into a certain shape or form" which would imply that the 
>> material you start with is transformed, which is apparently the intended 
>> meaning and also the reverse meaning from the above.
>> 
>> I mean, doesn't this make sense as an API?
>> 
>> let donut = baker.formDonut(dough) // non-mutating
>> 
>> Perhaps instead of "form" we could use "become" as a prefix when the 
>> operation is naturally described by a noun. That would seem less ambiguous 
>> to me:
>> 
>> a.becomeUnion(b)
>> a.becomeIntersection(b)
>> a.becomeSuccessor(b)
>> 
>> It's a bit passive, but I find it fits well when the operation is a noun.
>> 
>> And there's no way the term lends itself to non-mutating cases without 
>> things becoming nonsensical:
>> 
>> let donut = baker.becomeDonut(dough) // non-mutating?
> 
> I also am having difficulty coming to terms with the use of "form" (I am a 
> native English speaker). As you note "form" can imply the creation of 
> something from parts (more like assembling a new thing) as well as the 
> creation of something out of a material say a of block clay (more like 
> molding something out of an existing thing). It doesn't seem clear cut to me 
> to imply in place mutation.
> 
> Additionally my eyes / brain keep seeing "from" instead of "form". This type 
> of issue is generally true with any short word made up of the same set of 
> letters (made worse since "from" is more common in programming then "form"). 
> The mind quickly narrows in on a set of possible words given the letters we 
> see and then uses context to help get the correct one and/or additional 
> visual parsing to understand the exact ordering of letters (more energy 
> expended). Anyway since I keep seeing "from" instead of "form" I keep going 
> in the direction of thinking it returns something made from the two (or more) 
> items involved (not really sure why "from" goes that direction in my head, it 
> could also go the in place direction).
> 
> I would prefer something other then "form" (note I just typed "from" by 
> mistake)... I think your suggestion of "become" has merit.
> 
> y.becomeUnion(x) --reads to me as--> "y become union with x"
> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
> y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
> y.formIntersection(x) --read to me as--> "y from oops... y forming an 
> intersection with x"
> 
> In the "forming" situations it – to me – is ambiguous on if that is in place 
> or not. To me it implies more of giving something new back.
> 
> I am -1 on "form" aspect of this proposal. ...of course things are learnable 
> as long as things are fairly consistent and not to far out of the norm for 
> typical language use. Personally I don't see "form" as that typical in 
> English.
> 
> -Shawn
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

[Daniel Dunbar via swift-evolution]

> On Mar 21, 2016, at 4:05 PM, Max Howell  wrote:
> 
>> 2. I like VersionLocks.json well enough, but would like to see a discussion 
>> about possible alternatives. My personal proposal (in line with #1) is to 
>> use "PackageVersions.json" which has a nice agreement with Package.swift and 
>> would mean two common metadata files show up adjacent. I don't really want 
>> to bike shed on the name, but I suspect whatever we pick first will last for 
>> a while so I would at least like to review the various alternatives. I also 
>> will throw out that my personal opinion is we don't need to pick a name that 
>> bears much resemblance with existing terminology, whatever we pick will 
>> eventually become "the standard" for the SwiftPM ecosystem so I would prefer 
>> to pick the most-descriptive-possible name up front, not one that alludes to 
>> the same concept in other systems.
> 
> I like PackageVersions.json

Cool. There are still some instances of `VersionLocks.json` in the doc, btw.

>> 3. I like the terminology section here, I almost feel like we should adopt 
>> that as official terminology in our documentation (which I don't think we 
>> have yet, correct me if I am wrong).
> 
> We don’t, but I agree, we should aim to pick some names and use them 
> consistently.
> 
>> 4. I would like it if the lock file recorded the exact SHA it received, and 
>> validate that when retrieving. This helps protect users against MITM attacks 
>> or unexpected changes if an upstream modifies a tag. It also can be used as 
>> part of safety checks when migrating to an alternate repository host which 
>> is expected to have the same content.
> 
> Good point, this should be there.
> 
>> 5. The "workflow - build" sections #2,3,4 are rather complicated. Is this 
>> because the proposal is trying to work with existing Packages layouts, or 
>> because the proposal is trying to handle the various variations of what the 
>> user may have checked in inside the Packages subdirectory?
> 
> The latter, if we are to support checking in the `Packages` directory, we 
> should handle it when it is so. Is there a simpler way you can see?

I think the minimal feature here is that swiftpm grows the ability to read a 
specification file which declares how the package dependency tree is resolved. 
These seems like it should be primitive, and straightforward, so it is 
worrisome that the proposal is so complex.

What is your mental model for what checked in Packages should be? I can see 
several ways to interpret them:
A. The checked in copy is just a replica of the dependency repository. It 
exists to ensure the product can be built in a self contained manner.
B. The checked in copy *is* the dependency, it is basically a "convenient fork 
at a pinned version". SwiftPM recognizes the use case so that it can provide 
convenient features for the use case (like easily updating the fork).
C. Something in between. The checked in copy exists to ensure self containment, 
but it is also not treated like a fork.

I feel that too many problems are being combined into one proposal, and I think 
it makes it hard to work through and discuss the ramifications of all the 
changes here. There are at least five problems discussed in the current 
proposal:
1. The feature for pinning of package versions.
2. The workflow for interacting with the pinning feature (i.e., --lock, etc.).
3. Interactions between checked in Package trees and package versions.
4. Swift toolchain versioning issues.
5. Local diffs.
#1 and #2 obviously make sense together, and I can see how #1 and #3 might have 
to be in the same proposal (since implementing #1 may require solving #3 to not 
break things). I would like to see the rest be teased apart just so it is 
easier to understand all the implications.

A priori, I don't see how that minimal feature should require significant 
discussion w.r.t. checked in Packages. For example, consider the three models I 
gave above:
- If the expected model is (A), then the behavior I get with checked in 
Packages should always be exactly the same as if I blew it away (assuming the 
remote hasn't had content deleted). Therefore, the only new behaviors that need 
come with version pinning are probably a few cases of error detection (when 
updating versus a remote which has deleted content).
 - If the expected model is (B), then I would expect the behavior to be that 
there *must* be a PackageVersions.json, and the Packages *must* match those in 
that file. This may be what the existing rules are trying to codify, if so I 
think it would be most clear to simply specify the intent.
o I can see how there are workflow issues around the user editing their 
"local fork" and needing to update both the PackageVersions.json, but it seems 
like they follow from the basic behavior of "the PackageVersions *must* match 
the local fork".
 - If the expected model is (C), then I think it is important to clarify 
exactly what a checked 

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Thorsten Seitz via swift-evolution]

As the problem seems to be to eliminate having to write the extension with all 
its duplication, I'd prefer a more general solution instead of introducing the 
notion of an "optional" function: just make it possible to write default 
implementations inline in a protocol definition. 

Documenting the optionality can be done in the doc comment, maybe with a new 
documentation keyword "default". Having "optional" in the code has no 
additional value over a comment because the method is not optional in the Obj-C 
sense and the proposal requires a default value. Therefore the presence of 
"optional" has essentially no effect at all and is better moved into a comment.

-Thorsten 

> Am 04.04.2016 um 00:13 schrieb Chris Lattner via swift-evolution 
> :
> 
> 
>>> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov  wrote:
>>> 
>>> Protocol requirements with default (no-op) implementations already satisfy 
>>> that design goal, no?
>> 
>> Chris, as we've discussed in a thread that I think got forked from this one:
>> 
>> Yes, they do technically, but it would be nice to both:
>> 
>> 1) make it an obvious documented part of the signature, possibly including 
>> the default return value
>> 
>> 2) possibly make it less verbose by getting rid of the explicitly spelled 
>> out protocol extension
> 
> Right, but “more is worse” when it comes to language design.  Having a "more 
> general" facility that greatly overlaps with a “more narrow” facility always 
> makes us question whether it is worth the complexity to have both.
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Andrey Tarantsov via swift-evolution]

I understand the concern.

To me, the answer is clearly yes. The language cannot be considered in 
isolation from its use cases; imagine UIKit written in Swift.

You want the developers to be able to quickly understand which table view 
delegate methods they need to implement, and what the contract is (are cells 
editable or non-editable by default?).

We need the same thing for our own UIKit-style controls we're writing today 
(and we don't want to be limited to @objc types when doing that — those are 
particularly ill-suited for the return values of optional delegate methods; I 
often want a CGFloat? or a enum).

I don't see this as a separate faculty as much as a shorthand, similar to how 
T? is a shorthand for Optional.

The general opinion on shorthands varies from “there should be exactly one way 
to do everything” Python-style to “the language should help the developer 
express themselves” Ruby/Perl-style.

I personally am firmly in the “Ruby camp” here, so I'm all for use 
case-specific shorthands for general facilities.

You, sir (together with your dream team), should probably pick an official 
stance on this matter. :-)

A.


On 4 Apr 2016 04:15 +0600, Yuval Tal, wrote:
> For readability and specifically in this case, I think it does make sense 
> IMHO.
>  
> On Sunday, April 3, 2016, Chris 
> Lattnerwrote:
> >  
> > > On Apr 3, 2016, at 10:40 AM, Andrey 
> > > Tarantsovwrote:
> > > > Protocol requirements with default (no-op) implementations already 
> > > > satisfy that design goal, no?
> > > Chris, as we've discussed in a thread that I think got forked from this 
> > > one:
> > >  
> > > Yes, they do technically, but it would be nice to both:
> > >  
> > > 1) make it an obvious documented part of the signature, possibly 
> > > including the default return value
> > >  
> > > 2) possibly make it less verbose by getting rid of the explicitly spelled 
> > > out protocol extension
> > Right, but “more is worse” when it comes to language design.Having a "more 
> > general" facility that greatly overlaps with a “more narrow” facility 
> > always makes us question whether it is worth the complexity to have both.
> >  
> > -Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

See inline

> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution 
> :
> 
> There is a problem here of duplicated operators or custom precedence, and how 
> that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator **. A 
> and C each define a custom operator ++, and their meanings are different 
> (though, even if their meanings were the same, I'm not sure if they could 
> unify).
> 
> Module D uses A and B as dependencies and sets a custom precedence on ++ and 
> **. Module E uses B and C and has a different precedence on ++ and **. You're 
> working on Module F which uses D and E. Which ++ and which precedence does F 
> get implicitly?
> 

We could allow operator precedence overriding to resolve ambiguity. However 
this overriding should only be module internal since it would override the 
existing precedences in the other modules.

@AHTOH
Why do you use #keyword ?
I think defining a operator with

infix operator + {
 associativity: left
}

is perfectly fine since it is similar to class/struct/enum declaration.

// and it's precedence
precedence(+ lessThan *)

Note the missing "," and ":" before and after "lessThan" in order to give both 
operators the same importance (minor issue).

I feel that

#precedence(+, lessThan: *)

puts too much importance on the first operator.

Best regards
- Maximilian

> I'm wondering whether we can treat operators the way we recently decided to 
> treat selectors: if there is an ambiguity, it should be possible not just to 
> specify which module they came from, but their fixity or argument types. If 
> module D decides that '++' should refer to 'traditional postfix number 
> incrementation', and F decides that it should be an infix 'conjoin two 
> numbers as a string and turn the result into a number (e.g. 5 ++ 4 -> 54)' 
> then a #selector-like operator signature would come in really handy.
> 
> 
>> On Sun, Apr 3, 2016 at 12:10 PM, Taras Zakharko via swift-evolution 
>>  wrote:
>> I think this is a great suggestion! One potential problem I can see (if I 
>> understood this correctly) is that modules are allowed to set up their own 
>> precedence rules for operators defined elsewhere. I think this might lead to 
>> some difficult to debug errors if a developer of one module (who is used to 
>> certain conventions) then has to work with a different, independent module 
>> (where the conventions are different). This is one area where numerical 
>> precedence weights seem to be superior as they at least refer to a common 
>> subjective coordinate system. 
>> 
>> Maybe one should also have visibility for precedence, for instance having 
>> precedence module-internal by default?
>> 
>> Best, 
>> 
>>  — Taras  
>> 
>>> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution 
>>>  wrote:
>>> 
>>> Swift 2.2 is out, and I restart discussion on syntax for custom operators. 
>>> I insist that this time we should focus less on linguistic aspects.
>>> 
>>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>> 
>>> Introduction
>>> 
>>> Replace syntax of operator definition:
>>> 
>>> infix operator <> { precedence 100 associativity left }
>>> With a directive:
>>> 
>>> #operator(<>, fixity: infix, associativity: left)
>>> Also replace numeric definition of precedence with separate comparative 
>>> precedence definitions:
>>> 
>>> #precedence(+, lessThan: *)
>>> #precedence(+, equalTo: -)
>>> Swift-evolution thread: link to the discussion thread for that proposal
>>> 
>>> Motivation
>>> 
>>> Problems with numeric definition of precedence
>>> 
>>> In the beginning, operators had nice precedence values: 90, 100, 110, 120, 
>>> 130, 140, 150, 160.
>>> 
>>> As time went, new and new operators were introduced. Precedence could not 
>>> be simply changed, as this would be a breaking change. Ranges got 
>>> precedence 135, as got precedence 132. ?? had precedence greater than <, 
>>> but less thanas, so it had to be given precedence 131.
>>> 
>>> Now it is not possible to insert any custom operator between < and ??. It 
>>> is an inevitable consequence of current design: it will be impossible to 
>>> insert an operator between two existing ones at some point.
>>> 
>>> Problems with a single precedence hierarchy
>>> 
>>> Currently, if an operator wants to define precedence by comparison to one 
>>> operator, it must do so for all other operators.
>>> 
>>> In many cases, this is not wished. Example: a & b < c is a common error 
>>> pattern. a / b as Double is another one. C++ compilers sometimes emit 
>>> warnings on these. Swift does not.
>>> 
>>> The root of the problem is that precedence is defined between all 
>>> operators. If & had precedence defined only by comparison to other bitwise 
>>> operators and / – only to arithmetic operators, we would have to place 

Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations

[Charles Srstka via swift-evolution]

> On Apr 3, 2016, at 8:51 PM, David Waite via swift-evolution 
>  wrote:
> 
> Swift also has the benefit of built-in access to C/C++ and in some 
> environments Objective-C code and libraries. This means it does not have to 
> strive to either replace or to have universal coverage of features in these 
> languages. 
> 
> For example, I cite pointers in Swift: while UnsafePointer exists, one would 
> be hard-pressed to choose to use it for code involving significant pointer 
> manipulation over the equivalent C code - the C code is much more terse, and 
> in the domain of unsafe pointer juggling the C that terseness actually can 
> make the code more understandable. We have the benefit of letting C be good 
> at what C was made for, and having that C code talk to Swift. The language 
> doesn't need “Pure Swift” in the way a cross-platform distribution language 
> like Java needs “Pure Java”.

Keep in mind that this is only (fully) true on Apple platforms; it’s my 
understanding that the open-source version of Swift does not include the 
Objective-C bridge, with its bridging headers and all that jazz. Therefore, 
interop with C code is probably limited to calling things from libraries.

Charles

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

Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations

[David Waite via swift-evolution]

> On Apr 3, 2016, at 1:25 PM, John Heerema via swift-evolution 
>  wrote:


> So, I’d ask “why is it so terrible that we’re going to remove it, even though 
> it presents an obstacle to developers coming over to Swift?” Maybe there’s a 
> really good answer to that, but if there is, I haven’t seen it in the 
> discussion thus far. Did I miss something really important in the 0007 
> discussion?

0004 and 0007 were approved, implemented, and now with Swift 2.2 have been 
shipped as deprecation warnings, and will no longer be valid syntax in 3.0. 
That ship has sailed.

You will likely have far better results both engaging in discussion and 
possibly evoking change if your argument approached new reasons why it would be 
worth *adding* these syntaxes to the swift language as if they had never 
existed.

I admit this is a hard argument to make. For instance,I did not recognize any 
points in the email I’m replying to that had not already come up in the 
previous discussion while 0004 and 0007 were being reviewed. I would expect 
that a proposal to add either one of these features would almost certainly fail 
without genuinely new arguments backing them. However, I also suspect that it 
would be an equal barrier to add either of these had Swift never had them - at 
least, that would be the measure by which I would evaluate said proposal(s).

It is not often that features are removed from programming languages after 
their 1.0 release, and these two features were modeled after mechanisms people 
are accustomed to in other languages. Your voice has been heard by sympathetic 
ears. But neither of those points alone would form the basis of a proposal for 
their inclusion in a future swift release.

> I’m pretty sure that everyone on this list already knows the answer, and it’s 
> not the choice we might think that all those millions of developers “should” 
> have made. Given a free choice, developers overwhelmingly chose to use ++ and 
> —. They predominately use the suffix version, but the prefix version is also 
> common. If you don’t believe me, it’s easy to find out for yourself. 
> Actually, I would encourage you not to believe me. Please conduct your own 
> experiment if you have access to a significant body of code. At a more 
> personal level, did you have to refactor your own code to eliminate them? Of 
> course it's easy to do, but why didn’t you make the “right” choice in the 
> first place?


As you deferred in providing statistics:

With regards to reviewing code for usage, pre/post increment/decrement 
operators were found by reviewers to be almost entirely used within the 
per-loop statement of the C-style for loop.

With regards to reviewing code for ease of migration, most C-style for loops 
were found to be easily refactorable into the for…in syntax, usually with 
favorable increases to readability. More complex examples covered contrary 
include navigation of items containing a linked list, traversing a range in 
reverse or by a stride, and mutating the index within the body of the loop.

> If we have already made a particular choice, and we’re used to defending our 
> choice as being the right one, it’s really hard for us to even imagine that 
> we might have made a decision that doesn’t further our eventual goal.  So, 
> what’s the goal for Swift? Is it to be the language that finally takes over 
> from C’s popularity? Or is it to be a specialized niche language?

I do not believe that not having pre/post increment/decrement operators or 
C-style for loops makes something a ‘niche language’. Ruby for instance has 
neither.

Swift also has the benefit of built-in access to C/C++ and in some environments 
Objective-C code and libraries. This means it does not have to strive to either 
replace or to have universal coverage of features in these languages.

For example, I cite pointers in Swift: while UnsafePointer exists, one would be 
hard-pressed to choose to use it for code involving significant pointer 
manipulation over the equivalent C code - the C code is much more terse, and in 
the domain of unsafe pointer juggling the C that terseness actually can make 
the code more understandable. We have the benefit of letting C be good at what 
C was made for, and having that C code talk to Swift. The language doesn't need 
“Pure Swift” in the way a cross-platform distribution language like Java needs 
“Pure Java”.

-DW


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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Yuval Tal via swift-evolution]

For readability and specifically in this case, I think it does make sense
IMHO.

On Sunday, April 3, 2016, Chris Lattner  wrote:

>
> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov  > wrote:
>
> Protocol requirements with default (no-op) implementations already satisfy
> that design goal, no?
>
>
> Chris, as we've discussed in a thread that I think got forked from this
> one:
>
> Yes, they do technically, but it would be nice to both:
>
> 1) make it an obvious documented part of the signature, possibly including
> the default return value
>
> 2) possibly make it less verbose by getting rid of the explicitly spelled
> out protocol extension
>
>
> Right, but “more is worse” when it comes to language design.  Having a
> "more general" facility that greatly overlaps with a “more narrow” facility
> always makes us question whether it is worth the complexity to have both.
>
> -Chris
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Chris Lattner via swift-evolution]

> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov  wrote:
> 
>> Protocol requirements with default (no-op) implementations already satisfy 
>> that design goal, no?
> 
> Chris, as we've discussed in a thread that I think got forked from this one:
> 
> Yes, they do technically, but it would be nice to both:
> 
> 1) make it an obvious documented part of the signature, possibly including 
> the default return value
> 
> 2) possibly make it less verbose by getting rid of the explicitly spelled out 
> protocol extension

Right, but “more is worse” when it comes to language design.  Having a "more 
general" facility that greatly overlaps with a “more narrow” facility always 
makes us question whether it is worth the complexity to have both.

-Chris

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0049 Move @noescape and @autoclosure to be type attributes

[Kevin Ballard via swift-evolution]

On Mon, Mar 28, 2016, at 09:48 AM, Douglas Gregor wrote:
> Hello Swift community,
> The review of SE-0049 "Move @noescape and @autoclosure to be type
> attributes" begins now and runs through March 31, 2016. The proposal
> is available here:
 
I know the review period has elapsed, but the proposal is still marked
as under review so I'll review it anyway :)

>  * What is your evaluation of the proposal?
 
+1. Seems like a perfectly reasonable change to make.

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

>  * 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?
 
A glance.
 
-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Shawn Erickson via swift-evolution]

On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  wrote:

> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > What is your evaluation of the proposal?
>>
>> I don't like "form" as a prefix. To me there is no difference between
>> `union` and `formUnion`: both sounds functional-style, and actually the
>> second one perhaps a bit more to my ears. There's basically two dictionary
>> definitions of "form":
>>
>> 1. "bring together parts or combine to create (something)" which to me
>> implies a new value is created, and
>> 2. "make or fashion into a certain shape or form" which would imply that
>> the material you start with is transformed, which is apparently the
>> intended meaning and also the reverse meaning from the above.
>>
>> I mean, doesn't this make sense as an API?
>>
>> let donut = baker.formDonut(dough) // non-mutating
>>
>> Perhaps instead of "form" we could use "become" as a prefix when the
>> operation is naturally described by a noun. That would seem less ambiguous
>> to me:
>>
>> a.becomeUnion(b)
>> a.becomeIntersection(b)
>> a.becomeSuccessor(b)
>>
>> It's a bit passive, but I find it fits well when the operation is a noun.
>>
>> And there's no way the term lends itself to non-mutating cases without
>> things becoming nonsensical:
>>
>> let donut = baker.becomeDonut(dough) // non-mutating?
>>
>
> I also am having difficulty coming to terms with the use of "form" (I am a
> native English speaker). As you note "form" can imply the creation of
> something from parts (more like assembling a new thing) as well as the
> creation of something out of a material say a of block clay (more like
> molding something out of an existing thing). It doesn't seem clear cut to
> me to imply in place mutation.
>
> Additionally my eyes / brain keep seeing "from" instead of "form". This
> type of issue is generally true with any short word made up of the same set
> of letters (made worse since "from" is more common in programming then
> "form"). The mind quickly narrows in on a set of possible words given the
> letters we see and then uses context to help get the correct one and/or
> additional visual parsing to understand the exact ordering of letters (more
> energy expended). Anyway since I keep seeing "from" instead of "form" I
> keep going in the direction of thinking it returns something made from the
> two (or more) items involved (not really sure why "from" goes that
> direction in my head, it could also go the in place direction).
>
> I would prefer something other then "form" (note I just typed "from" by
> mistake)... I think your suggestion of "become" has merit.
>
> y.becomeUnion(x) --reads to me as--> "y become union with x"
> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
> y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
> y.formIntersection(x) --read to me as--> "y from oops... y forming an
> intersection with x"
>

After stepping away for a bit and looking at it from the POV of the API of
Set and not in the context of "y" I could read things in the abstract as...

"becomeUnion(with other:Self)" --> "I become a union with other"
"formUnion(with other:Self)" --> "I form a union with other"

No clear winner to me however when used in code "become" still feels more
strongly mutating then "form": y.formUnion(with:x) or y.becomeUnion(with:x)

All in all the API would have mutating in front of it (at least for
structs) and it wouldn't have a return type. It would become clear fairly
quickly as a result (hence learned).

Just still not that happy with "form" but with use my mind would likely
quickly adapt.

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Shawn Erickson via swift-evolution]

On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution <
swift-evolution@swift.org> wrote:

> > What is your evaluation of the proposal?
>
> I don't like "form" as a prefix. To me there is no difference between
> `union` and `formUnion`: both sounds functional-style, and actually the
> second one perhaps a bit more to my ears. There's basically two dictionary
> definitions of "form":
>
> 1. "bring together parts or combine to create (something)" which to me
> implies a new value is created, and
> 2. "make or fashion into a certain shape or form" which would imply that
> the material you start with is transformed, which is apparently the
> intended meaning and also the reverse meaning from the above.
>
> I mean, doesn't this make sense as an API?
>
> let donut = baker.formDonut(dough) // non-mutating
>
> Perhaps instead of "form" we could use "become" as a prefix when the
> operation is naturally described by a noun. That would seem less ambiguous
> to me:
>
> a.becomeUnion(b)
> a.becomeIntersection(b)
> a.becomeSuccessor(b)
>
> It's a bit passive, but I find it fits well when the operation is a noun.
>
> And there's no way the term lends itself to non-mutating cases without
> things becoming nonsensical:
>
> let donut = baker.becomeDonut(dough) // non-mutating?
>

I also am having difficulty coming to terms with the use of "form" (I am a
native English speaker). As you note "form" can imply the creation of
something from parts (more like assembling a new thing) as well as the
creation of something out of a material say a of block clay (more like
molding something out of an existing thing). It doesn't seem clear cut to
me to imply in place mutation.

Additionally my eyes / brain keep seeing "from" instead of "form". This
type of issue is generally true with any short word made up of the same set
of letters (made worse since "from" is more common in programming then
"form"). The mind quickly narrows in on a set of possible words given the
letters we see and then uses context to help get the correct one and/or
additional visual parsing to understand the exact ordering of letters (more
energy expended). Anyway since I keep seeing "from" instead of "form" I
keep going in the direction of thinking it returns something made from the
two (or more) items involved (not really sure why "from" goes that
direction in my head, it could also go the in place direction).

I would prefer something other then "form" (note I just typed "from" by
mistake)... I think your suggestion of "become" has merit.

y.becomeUnion(x) --reads to me as--> "y become union with x"
y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
y.formIntersection(x) --read to me as--> "y from oops... y forming an
intersection with x"

In the "forming" situations it – to me – is ambiguous on if that is in
place or not. To me it implies more of giving something new back.

I am -1 on "form" aspect of this proposal. ...of course things are
learnable as long as things are fairly consistent and not to far out of the
norm for typical language use. Personally I don't see "form" as that
typical in English.

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

Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations

[John Heerema via swift-evolution]

Thanks to all those who thoughtfully responded to this post! The folks who 
responded provided kind thoughts and advice.

Ross O’Brian asked if I was familiar with the original discussion for 0004 and 
0007.

To answer: Yes, I read the discussions several times over a period of a few 
weeks before writing anything myself. Unless the repo is somehow missing an 
awful lot of discussion, I would say that both of these proposals received 
startlingly little discussion at the time. These are very early proposals 
(numbers 4 and 7), and were conducted before a lot of people (including me) had 
any idea that feedback was being solicited.

My thoughts on these deprecations are aimed more at the human side of how 
developers actually behave, than on the strict “desirability" of the deprecated 
features.

Let’s take proposal 0004 – to deprecate the ++ and — operators.

A few years ago, I’ve have chimed in to say “sure, let’s deprecate those 
things. += is more general and obvious”. But that’s how those of us who think 
about orthogonality think.

On the human side, what do the human being who write code actually do?
Human beings notoriously do not act in the way we think they “should”.

Lots of languages, like C, C++, C#, Objective C, Java, etc., already have both 
the prefix and suffix versions of ++ and --.
All of those language also allow developers to use += 1. So, each and every one 
of the millions of people who use those languages already have a choice of 
using any of:
 a = a + 1
 a += 1, or
 a++

So an enormous social experiment has already been done, and we can benefit from 
it, if we are willing. Given that millions of people have already been given 
the choice of using any of the three forms shown above, what do they actually 
prefer to use? There are many, many millions of lines of extant code that can 
be parsed to determine what developers actually use when they are given the 
choice.

I’m pretty sure that everyone on this list already knows the answer, and it’s 
not the choice we might think that all those millions of developers “should” 
have made. Given a free choice, developers overwhelmingly chose to use ++ and 
—. They predominately use the suffix version, but the prefix version is also 
common. If you don’t believe me, it’s easy to find out for yourself. Actually, 
I would encourage you not to believe me. Please conduct your own experiment if 
you have access to a significant body of code. At a more personal level, did 
you have to refactor your own code to eliminate them? Of course it's easy to 
do, but why didn’t you make the “right” choice in the first place?

So, why would we deprecate the option that developers overwhelmingly choose to 
use?
Is it “for their own good”? Let’s remember that most people resent being told 
to do something “for their own good”.

There’s something inside most people’s brains that wants to make other people 
do something “for their own good”. I’d argue that this applies in spades to 
language designers. We want to make Swift even better than it already is (and I 
think that it’s already pretty darn good).  So it’s really tempting to have the 
compiler enforce doing the right thing.

But we also want other developers to make a voluntary choice to use Swift, when 
they could just as easily stick with Objective C, C, Java, or whatever they are 
using right now. At least, I hope that’s what everyone on this list wants.

Or do we want just Swift to be the cool language that those of us in the “in” 
club use, without necessarily wanting other people to join our exclusive little 
club? The answer to that question affects the discussion.

Taras Zakharko suggests that Swift isn’t trying to appeal to everyone. Perhaps 
not, but I hope that it does. We are long overdue for a modern general purpose 
language that compiles to, and is interoperable with native code. I think that 
Swift is great enough to be that language.

If we have already made a particular choice, and we’re used to defending our 
choice as being the right one, it’s really hard for us to even imagine that we 
might have made a decision that doesn’t further our eventual goal.  So, what’s 
the goal for Swift? Is it to be the language that finally takes over from C’s 
popularity? Or is it to be a specialized niche language?

The answer to that question affects the question of C-style For loops too, I 
suspect.

Andrew Bennett illustrated a neat way to generate an iterator using “defer”. 
It’s quite nice, but I would argue that it doesn’t jump out as being the 
perfect solution that’s so insanely great that people will give up C so that 
they can use it.

Taras Zakharko kindly pointed  out that the Swift compiler implements 
enumerable collections as lazy iterators. I was aware of that (and the way it’s 
done is pretty cool), but it seems dangerous to me to assume that the compiler 
will always be smart enough to avoid creating large enumerable collections. I 
think that looping is so common that it deserves 

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Xiaodi Wu via swift-evolution]

One idea related to this `for...do` syntax--maybe this will satisfy
some objections listed in the proposal:

Currently, Swift has optional semicolons. In the same spirit, suppose
control statements have optional colons, like this: `for eachValue in
theValues: { code }`. All current syntax continues to work, but you
could then use closures in control statements by putting in a colon
after the expression.

No new keywords would be needed, things would be very terse, and the
syntax would be unambiguous.

I'm proposing this because, even though the `for...do` idea is
interesting, I'm -1 as it is because it can create other ambiguities.
For example, imagine that you have `frobnicate(_: Int)` and
`frobnicate(_: Int, compare: (Int) -> Bool)`. Which function is being
called if you see the following?

```
for i in frobnicate(1) {
// code
}
do {
// code
}
```

Either you would need new rules about line breaks (adding new
inconsistencies between control statements, because `if...else` has
very flexible rules about line breaks), or else the meaning of the
code above would change if the lines that followed were:

```
catch {
// code
}
```


On Sun, Apr 3, 2016 at 10:20 AM, Haravikk via swift-evolution
 wrote:
> Although I use trailing closures a lot less now, I think I’m a +1 anyway for
> consistency’s sake.
>
> I actually really like the idea of having trailing keywords in loops and if
> statements, these needn’t be required (except where a trailing closure is
> used) but for example it means I could do a fully natural language loop
> like:
>
> for eachValue in theValues do { … }
>
> Which is very, very clear on what’s happening there and I like the
> consistency of every block having a kind of type (do, else, defer, catch
> etc.). That said it’s probably grounds for a separate, supplementary
> proposal once guard has this capability? Of course if it can be done at the
> same time that’d be great too, as the implementation of this proposal should
> assume that if/while will gain the same ability at some point once we decide
> how to do it.
>
> On 3 Apr 2016, at 13:44, Howard Lovatt via swift-evolution
>  wrote:
>
> Interesting idea to put keywords in the other statements so that they can
> also use trailing closures!
>
> On Sunday, 3 April 2016, Ilya Belenkiy via swift-evolution
>  wrote:
>>
>> What is your evaluation of the proposal?
>>
>> +1. I stumble on this quite often.
>>
>> Is the problem being addressed significant enough to warrant a change to
>> Swift?
>>
>> yes
>>
>> 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?
>>
>> quick reading
>>
>>
>> On Mar 31, 2016, at 11:27 PM, Douglas Gregor via swift-evolution
>>  wrote:
>>
>> Hello Swift community,
>>
>> The review of SE-0056 "Allow trailing closures in `guard` conditions"
>> begins now and runs through April 5, 2016. The proposal is available here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>>
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to the
>> review manager. When replying, please try to keep the proposal link at the
>> top of the message:
>>
>> Proposal link:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>>
>> Reply text
>>
>> Other replies
>>
>> What goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and, eventually, determine the direction of
>> Swift. When writing your review, here are some questions you might want to
>> answer in your review:
>>
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how
>> do you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading,
>> or an in-depth study?
>>
>> More information about the Swift evolution process is available at
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>
>> Thank you,
>>
>> Doug Gregor
>>
>> Review Manager
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> -- Howard.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] [Proposal] Custom operators

[Félix Cloutier via swift-evolution]

That doesn't sound future-proof. If it was in place and Range hadn't existed 
since the earliest Swift public release, it wouldn't be possible to define its 
precedence now.

Félix

> Le 3 avr. 2016 à 11:41:00, Ben Rimmington via swift-evolution 
>  a écrit :
> 
>  -operator-precedence.md>
> 
> Another way to eliminate numerical precedence is by using keywords:
> 
> infix operator << {
>associativity none
>exponentiative
> }
> 
> infix operator * {
>associativity left
>multiplicative
> }
> 
> infix operator + {
>associativity left
>additive
> }
> 
> infix operator == {
>associativity none
>comparative
> }
> 
> infix operator += {
>associativity right
>assignment
> }
> 
> All operators would need to use one of the existing precedence groups (Table 
> 2):
> 
>  Swift_StandardLibrary_Operators/>
> 
> -- Ben
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Custom operators

[Ben Rimmington via swift-evolution]

Another way to eliminate numerical precedence is by using keywords:

infix operator << {
associativity none
exponentiative
}

infix operator * {
associativity left
multiplicative
}

infix operator + {
associativity left
additive
}

infix operator == {
associativity none
comparative
}

infix operator += {
associativity right
assignment
}

All operators would need to use one of the existing precedence groups (Table 2):



-- Ben

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

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Rudolf Adamkovic via swift-evolution]

Like others, I'm -1 on this due to added inconsistency between the guard and 
other control flow statements.

R+

Sent from my iPhone

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Andrey Tarantsov via swift-evolution]

> Protocol requirements with default (no-op) implementations already satisfy 
> that design goal, no?

Chris, as we've discussed in a thread that I think got forked from this one:

Yes, they do technically, but it would be nice to both:

1) make it an obvious documented part of the signature, possibly including the 
default return value

2) possibly make it less verbose by getting rid of the explicitly spelled out 
protocol extension

A.


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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Andrey Tarantsov via swift-evolution]

>> I've actually had multiple cases in Objective-C code where this feature 
>> (some object behaving differently depending on wether or not a delegate 
>> method has been implemented) has prevented me from implementing features the 
>> easy and obvious way. In those cases I resorted to implementing 
>> 'respondsToSelector:'. So I'd argue that optional protocol methods encourage 
>> this type of behavior, which imho is bad API design. If you need to behave 
>> differently for some types of delegates (or whatever else your protocol 
>> represents), a separate method to call to determine how to behave is much 
>> simpler and better to use.
> 
> +1.  This is exactly the same thing I mentioned regarding the fast path for 
> row height in UITableView.  The fact that it depends on whether or not the 
> delegate implements heightForRowAtIndexPath is a bad design decision.

Yes, but please observe that the form of optional methods that we're discussing 
here is limited to avoid the case you mention (I hate that problem as well, 
very very much).

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Andrey Tarantsov via swift-evolution]

> I do not understand why an optional method should require a default value. 
> That’s not how optional methods work in Objective-C where the caller will ask 
> whether the method is implemented and calls it or does something else. With a 
> default value it would be much more difficult to do something different if 
> the method is not implemented.

Yes, and that's the best part. The way Obj-C optional methods currently work, 
they are very hard to wrap/proxy/etc. Swift has a lot more expressive power, so 
I'm sure that you can adjust the return value to express the “I don't care” 
case without making the absence of the method magical.

A.

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Andrey Tarantsov via swift-evolution]

> Some ideas I was thinking about for optional protocol functions was you’d 
> declare it like this:
> 
> protocol UIGestureRecognizerDelegate {
>  optional func gestureRecognizerShouldBegin(gestureRecognizer: 
> UIGestureRecognizer) -> Bool = true
> }
> 
> If you put “optional” there, the compiler would auto-generate an empty 
> function in a protocol extension in your module as if you had specified one 
> yourself. If the function has a return value, you would be required to 
> specify the default return value in the protocol which provides automatic 
> documentation of the default, too.

REALLY digging this. Strong +1.

A.

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

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Andrey Tarantsov via swift-evolution]

>> My point is that "protected" *isn't* access control. If we added it, it 
>> would have to be as an independent modifier. Private/internal/public 
>> fundamentally affect semantics—private and internal code is only accessible 
>> within a module, so we have full knowledge of their use sites at compile 
>> time and can be more permissive with extensions, implicit constructors, and 
>> other features. Public API can be used by arbitrary unknown external code so 
>> requires additional restrictions to ensure that the interface remains 
>> stable. "Only usable by subclasses" is an orthogonal axis to this—if a 
>> method is only usable by external subclasses, it requires all of the same 
>> restrictions as public code. If a method is only usable by subclasses within 
>> the module, it can behave like a private or internal method.

Okay. So you see it as “public subclassonly”, leaving space for “internal 
subclassonly” (which makes sense, although not as important in practice).

I can agree with that, let's consider it a new strawman.

I wonder, though, if you guys have additional, fresh ideas on the underlying 
problem. We're not really limiting to subclasses here — we're limiting to 
“extenders” aka “service providers”, and those don't necessarily take a form of 
a subclass. I've listed some examples in my strawman: an implementation of a 
protocol, an extension of a class/protocol.

Are there any novel and fresh ideas that would take care of all that in a 
straightforward and uncomplicated way?

A.

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

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Dany St-Amant via swift-evolution]

> Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution 
>  a écrit :
> 
>> What is your evaluation of the proposal?
> I think there is a lot of value to allowing trailing closures in the guard 
> condition clause. However, not at the cost of inconsistency. We have reviewed 
> many proposals over the last month that addressed consistency issues in the 
> Swift language, and if I'm not mistaken, all of them have been accepted by 
> the community, larger to eliminate the inconsistency.
> 
> Because of this, I think two of the alternatives stated by the proposal have 
> credibility:
> 1) Eliminate the "else" keyword from the guard syntax.
> 2) Add keywords to "if", "while", "for", and "switch" to delineate the 
> condition clause from the body of the statement.
> 
> The second alternative has more appeal, because it supports trailing closures 
> without "heroics".

It have been mentioned multiple times that allowing trailing closure only for 
guard is creating an inconsistency, but these keywords already are inconsistent 
with the each other (beside the presence of the 'trailing' else keyword) on the 
variable scoping:

- guard let: outer scope immutable variable
- if let: inner scope immutable variable
- for: inner scope immutable variable without let keyword

Consistency is good, but since each keywords are not for the exact same thing, 
it is normal to see some variances.  Like the global scope of the immutable 
variable created by guard; as per the intent of the keyword, or its trailing 
else keyword; needed to clarify that what follow is for, for lack of better 
word, the 'else' case.

So as long as such inconsistency have a "raison d'être", that they have been 
designed and are not an oversight; there should be no reason to not allow them.

Dany

> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> No.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> No. Please don't add inconsistencies to the language, as we're just going to 
> have to deal with it down the road.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> Not in my experience.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> In-depth study.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Haravikk via swift-evolution]

Although I use trailing closures a lot less now, I think I’m a +1 anyway for 
consistency’s sake.

I actually really like the idea of having trailing keywords in loops and if 
statements, these needn’t be required (except where a trailing closure is used) 
but for example it means I could do a fully natural language loop like:

for eachValue in theValues do { … }

Which is very, very clear on what’s happening there and I like the consistency 
of every block having a kind of type (do, else, defer, catch etc.). That said 
it’s probably grounds for a separate, supplementary proposal once guard has 
this capability? Of course if it can be done at the same time that’d be great 
too, as the implementation of this proposal should assume that if/while will 
gain the same ability at some point once we decide how to do it.

> On 3 Apr 2016, at 13:44, Howard Lovatt via swift-evolution 
>  wrote:
> 
> Interesting idea to put keywords in the other statements so that they can 
> also use trailing closures!
> 
> On Sunday, 3 April 2016, Ilya Belenkiy via swift-evolution 
> > wrote:
>> What is your evaluation of the proposal?
> +1. I stumble on this quite often.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> yes
> 
>> 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?
> quick reading
> 
> 
>> On Mar 31, 2016, at 11:27 PM, Douglas Gregor via swift-evolution 
>> > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0056 "Allow trailing closures in `guard` conditions" begins 
>> now and runs through April 5, 2016. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>>  
>> 
>> Reply text
>> 
>> Other replies
>>  What 
>> goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thank you,
>> 
>> Doug Gregor
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> 
> -- 
> -- Howard.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Michel Fortin via swift-evolution]

> What is your evaluation of the proposal?

I don't like "form" as a prefix. To me there is no difference between `union` 
and `formUnion`: both sounds functional-style, and actually the second one 
perhaps a bit more to my ears. There's basically two dictionary definitions of 
"form":

1. "bring together parts or combine to create (something)" which to me implies 
a new value is created, and
2. "make or fashion into a certain shape or form" which would imply that the 
material you start with is transformed, which is apparently the intended 
meaning and also the reverse meaning from the above.

I mean, doesn't this make sense as an API?

let donut = baker.formDonut(dough) // non-mutating

Perhaps instead of "form" we could use "become" as a prefix when the operation 
is naturally described by a noun. That would seem less ambiguous to me:

a.becomeUnion(b)
a.becomeIntersection(b)
a.becomeSuccessor(b)

It's a bit passive, but I find it fits well when the operation is a noun.

And there's no way the term lends itself to non-mutating cases without things 
becoming nonsensical:

let donut = baker.becomeDonut(dough) // non-mutating?


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

I'm still not entirely convinced any of this is better than the `InPlace` 
suffix we had before. `InPlace` might be ugly visually and grammatically, but 
seems to be the clearest at expressing the intent.


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

There is no question that using a verb instead of the `InPlace` suffix makes 
things fits better with the other API guidelines.


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

N/A


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

Read the guideline and API diffs, thought about a few alternative wording, 
looked in my dictionary.


-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Howard Lovatt via swift-evolution]

Interesting idea to put keywords in the other statements so that they can
also use trailing closures!

On Sunday, 3 April 2016, Ilya Belenkiy via swift-evolution <
swift-evolution@swift.org> wrote:

>
>- What is your evaluation of the proposal?
>
> +1. I stumble on this quite often.
>
>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> yes
>
>
>- 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?
>
> quick reading
>
>
>-
>
>
> On Mar 31, 2016, at 11:27 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
> Hello Swift community,
>
> The review of SE-0056 "Allow trailing closures in `guard` conditions"
> begins now and runs through April 5, 2016. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
>
> Reply text
>
> Other replies
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> Doug Gregor
>
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>

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

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

Right, the proposal in its current form does not really aim to resolve such
conflicts, although it makes them occur less often by "merging" precedence
and associativity when possible.

At first, I also tried to resolve such conflicts by naming operators. But I
found that compiler instructions will be too complex in some cases:

#operator(+, name: numericAdd, fixity: infix, associativity: left)
#operator(+, name: arrayAppend, fixity: infix, associativity: right)

func numericAdd(left: A, right: B) -> C
func numericAdd(left: B, right: C) -> B
func arrayAppend(left: A, right: A) -> B
func arrayAppend(left: B, right: C) -> A

A() + B() + C()

Compiler will have to find by brute-force that this expression can only
represent arrayAppend(A(), arrayAppend(B(), C())), and others result in
errors. To me, this scheme seems pretty absurd.

That said, it might be a good idea to add visibility for operators.
Hiding already imported operators, on the other hand, would be inconsistent
with othr elements of the language. It is currently impossible to hide
contents of module A from C where C imports B and B imports A. Not that I'm
against such a feature in general.

- Anton


2016-04-03 14:26 GMT+03:00 Ross O'Brien :

> There is a problem here of duplicated operators or custom precedence, and
> how that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator
> **. A and C each define a custom operator ++, and their meanings are
> different (though, even if their meanings were the same, I'm not sure if
> they could unify).
>
> Module D uses A and B as dependencies and sets a custom precedence on ++
> and **. Module E uses B and C and has a different precedence on ++ and **.
> You're working on Module F which uses D and E. Which ++ and which
> precedence does F get implicitly?
>
> I'm wondering whether we can treat operators the way we recently decided
> to treat selectors: if there is an ambiguity, it should be possible not
> just to specify which module they came from, but their fixity or argument
> types. If module D decides that '++' should refer to 'traditional postfix
> number incrementation', and F decides that it should be an infix 'conjoin
> two numbers as a string and turn the result into a number (e.g. 5 ++ 4 ->
> 54)' then a #selector-like operator signature would come in really handy.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[James Campbell via swift-evolution]

In these case of module operator conflicts perhaps there could be a way we
could import these operators ?

Likes a #importOperators(OtherModule) or some kind of build flag.

*___*

*James⎥Future Prime Minister*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Sun, Apr 3, 2016 at 12:26 PM, Ross O'Brien via swift-evolution <
swift-evolution@swift.org> wrote:

> There is a problem here of duplicated operators or custom precedence, and
> how that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator
> **. A and C each define a custom operator ++, and their meanings are
> different (though, even if their meanings were the same, I'm not sure if
> they could unify).
>
> Module D uses A and B as dependencies and sets a custom precedence on ++
> and **. Module E uses B and C and has a different precedence on ++ and **.
> You're working on Module F which uses D and E. Which ++ and which
> precedence does F get implicitly?
>
> I'm wondering whether we can treat operators the way we recently decided
> to treat selectors: if there is an ambiguity, it should be possible not
> just to specify which module they came from, but their fixity or argument
> types. If module D decides that '++' should refer to 'traditional postfix
> number incrementation', and F decides that it should be an infix 'conjoin
> two numbers as a string and turn the result into a number (e.g. 5 ++ 4 ->
> 54)' then a #selector-like operator signature would come in really handy.
>
>
> On Sun, Apr 3, 2016 at 12:10 PM, Taras Zakharko via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I think this is a great suggestion! One potential problem I can see (if I
>> understood this correctly) is that modules are allowed to set up their own
>> precedence rules for operators defined elsewhere. I think this might lead
>> to some difficult to debug errors if a developer of one module (who is used
>> to certain conventions) then has to work with a different, independent
>> module (where the conventions are different). This is one area where
>> numerical precedence weights seem to be superior as they at least refer to
>> a common subjective coordinate system.
>>
>> Maybe one should also have visibility for precedence, for instance having
>> precedence module-internal by default?
>>
>> Best,
>>
>>  — Taras
>>
>> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Swift 2.2 is out, and I restart discussion on syntax for custom
>> operators. I insist that this time we should focus less on linguistic
>> aspects.
>>
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Introduction
>>
>> Replace syntax of operator definition:
>>
>> infix operator <> { precedence 100 associativity left }
>>
>> With a directive:
>>
>> #operator(<>, fixity: infix, associativity: left)
>>
>> Also replace numeric definition of precedence with separate comparative
>> precedence definitions:
>>
>> #precedence(+, lessThan: *)
>> #precedence(+, equalTo: -)
>>
>> Swift-evolution thread: link to the discussion thread for that proposal
>> 
>>
>> 
>> Motivation
>> Problems
>> with numeric definition of precedence
>>
>> In the beginning, operators had nice precedence values: 90, 100, 110,
>> 120, 130, 140, 150, 160.
>>
>> As time went, new and new operators were introduced. Precedence could not
>> be simply changed, as this would be a breaking change. Ranges got
>> precedence 135, as got precedence 132. ?? had precedence greater than <,
>> but less thanas, so it had to be given precedence 131.
>>
>> Now it is not possible to insert any custom operator between < and ??.
>> It is an inevitable consequence of current design: it will be impossible to
>> insert an operator between two existing ones at some point.
>>
>> Problems
>> with a single precedence hierarchy
>>
>> Currently, if an operator wants to define precedence by comparison to one
>> operator, it must do so for all other operators.
>>
>> In many cases, this is not wished. Example: a & b < c is a common error
>> pattern. a / b as Double is another one. C++ compilers sometimes emit
>> warnings on these. Swift does not.
>>
>> The root of the problem is that precedence is defined between all
>> operators. If & had precedence defined only by comparison to other
>> bitwise operators 

Re: [swift-evolution] [Proposal] Custom operators

[Ross O'Brien via swift-evolution]

There is a problem here of duplicated operators or custom precedence, and
how that gets passed between modules.
Assume there are three modules, A, B and C. B defines a custom operator **.
A and C each define a custom operator ++, and their meanings are different
(though, even if their meanings were the same, I'm not sure if they could
unify).

Module D uses A and B as dependencies and sets a custom precedence on ++
and **. Module E uses B and C and has a different precedence on ++ and **.
You're working on Module F which uses D and E. Which ++ and which
precedence does F get implicitly?

I'm wondering whether we can treat operators the way we recently decided to
treat selectors: if there is an ambiguity, it should be possible not just
to specify which module they came from, but their fixity or argument types.
If module D decides that '++' should refer to 'traditional postfix number
incrementation', and F decides that it should be an infix 'conjoin two
numbers as a string and turn the result into a number (e.g. 5 ++ 4 -> 54)'
then a #selector-like operator signature would come in really handy.


On Sun, Apr 3, 2016 at 12:10 PM, Taras Zakharko via swift-evolution <
swift-evolution@swift.org> wrote:

> I think this is a great suggestion! One potential problem I can see (if I
> understood this correctly) is that modules are allowed to set up their own
> precedence rules for operators defined elsewhere. I think this might lead
> to some difficult to debug errors if a developer of one module (who is used
> to certain conventions) then has to work with a different, independent
> module (where the conventions are different). This is one area where
> numerical precedence weights seem to be superior as they at least refer to
> a common subjective coordinate system.
>
> Maybe one should also have visibility for precedence, for instance having
> precedence module-internal by default?
>
> Best,
>
>  — Taras
>
> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.
>
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Introduction
>
> Replace syntax of operator definition:
>
> infix operator <> { precedence 100 associativity left }
>
> With a directive:
>
> #operator(<>, fixity: infix, associativity: left)
>
> Also replace numeric definition of precedence with separate comparative
> precedence definitions:
>
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
>
> Swift-evolution thread: link to the discussion thread for that proposal
> 
>
> 
> Motivation
> Problems
> with numeric definition of precedence
>
> In the beginning, operators had nice precedence values: 90, 100, 110, 120,
> 130, 140, 150, 160.
>
> As time went, new and new operators were introduced. Precedence could not
> be simply changed, as this would be a breaking change. Ranges got
> precedence 135, as got precedence 132. ?? had precedence greater than <,
> but less thanas, so it had to be given precedence 131.
>
> Now it is not possible to insert any custom operator between < and ??. It
> is an inevitable consequence of current design: it will be impossible to
> insert an operator between two existing ones at some point.
>
> Problems
> with a single precedence hierarchy
>
> Currently, if an operator wants to define precedence by comparison to one
> operator, it must do so for all other operators.
>
> In many cases, this is not wished. Example: a & b < c is a common error
> pattern. a / b as Double is another one. C++ compilers sometimes emit
> warnings on these. Swift does not.
>
> The root of the problem is that precedence is defined between all
> operators. If & had precedence defined only by comparison to other
> bitwise operators and / – only to arithmetic operators, we would have to
> place parentheses in such places, not get subtle bugs, and not ever have to
> look at the huge operator precedence table.
>
> Problems
> with current operator definition syntax
>
> Some argue that current operator syntax is not consistent with other
> language constructs. Properties of operators have dictionary semantics and
> should be defined as such. It is a rather weak argument right now, but
> 

Re: [swift-evolution] [Proposal] Custom operators

[Taras Zakharko via swift-evolution]

I think this is a great suggestion! One potential problem I can see (if I 
understood this correctly) is that modules are allowed to set up their own 
precedence rules for operators defined elsewhere. I think this might lead to 
some difficult to debug errors if a developer of one module (who is used to 
certain conventions) then has to work with a different, independent module 
(where the conventions are different). This is one area where numerical 
precedence weights seem to be superior as they at least refer to a common 
subjective coordinate system. 

Maybe one should also have visibility for precedence, for instance having 
precedence module-internal by default?

Best, 

 — Taras  

> On 03 Apr 2016, at 11:36, Антон Жилин via swift-evolution 
>  wrote:
> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators. I 
> insist that this time we should focus less on linguistic aspects.
> 
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 
> Introduction
> 
> Replace syntax of operator definition:
> 
> infix operator <> { precedence 100 associativity left }
> With a directive:
> 
> #operator(<>, fixity: infix, associativity: left)
> Also replace numeric definition of precedence with separate comparative 
> precedence definitions:
> 
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
> Swift-evolution thread: link to the discussion thread for that proposal 
> 
>  
> Motivation
> 
>  
> Problems
>  with numeric definition of precedence
> 
> In the beginning, operators had nice precedence values: 90, 100, 110, 120, 
> 130, 140, 150, 160.
> 
> As time went, new and new operators were introduced. Precedence could not be 
> simply changed, as this would be a breaking change. Ranges got precedence 
> 135, as got precedence 132. ?? had precedence greater than <, but less 
> thanas, so it had to be given precedence 131.
> 
> Now it is not possible to insert any custom operator between < and ??. It is 
> an inevitable consequence of current design: it will be impossible to insert 
> an operator between two existing ones at some point.
> 
>  
> Problems
>  with a single precedence hierarchy
> 
> Currently, if an operator wants to define precedence by comparison to one 
> operator, it must do so for all other operators.
> 
> In many cases, this is not wished. Example: a & b < c is a common error 
> pattern. a / b as Double is another one. C++ compilers sometimes emit 
> warnings on these. Swift does not.
> 
> The root of the problem is that precedence is defined between all operators. 
> If & had precedence defined only by comparison to other bitwise operators and 
> / – only to arithmetic operators, we would have to place parentheses in such 
> places, not get subtle bugs, and not ever have to look at the huge operator 
> precedence table.
> 
>  
> Problems
>  with current operator definition syntax
> 
> Some argue that current operator syntax is not consistent with other language 
> constructs. Properties of operators have dictionary semantics and should be 
> defined as such. It is a rather weak argument right now, but after reworking 
> of precedence, the new syntax will be more to place. More reasons are given 
> below.
> 
>  
> Conflicts
>  of operator definitions
> 
> Consider two operator definitions in different modules.
> 
> Module A:
> 
> infix operator |> { precedence 137 associativity left }
> Module B:
> 
> infix operator |> { precedence 138 associativity left }
>  
> Proposed
>  solution
> 
>  
> Change
>  syntax for operator definition
> 
> #operator(<>, fixity: infix, associativity: left)
> #operator(!, fixity: postfix)
> First parameter of #operator directive is name of the operator. Then goes 
> required parameter fixity that can be infix,prefix, or postfix. 

Re: [swift-evolution] [Proposal] Custom operators

[Haravikk via swift-evolution]

> On 3 Apr 2016, at 11:45, Антон Жилин  wrote:
> 
> > Assuming these are defined in separate modules, how do we determine the 
> > order of • and ~?
> 
> By default, priority between any two operators is undefined. If two modules 
> don't know about each other, but the user wishes to prioritize them, then he 
> will write:
> 
> #precedence(•, lessThan: ~)
> 
> If • suddenly wishes to cooperate with ~, then it will add directives:
> 
> #operator(~, fixity: infix, associativity: left)
> #precedence(•, lessThan: ~)
> 
> It doesn't matter if ~ or user have already added them: if they do not 
> contain contradictory information, there will be no conflict.

Ah, I misunderstood then, so a warning/error will be raised if no precedence 
exists? Thanks for the explanation! I’ll probably still favour overkill 
brackets, but this makes sense.

In any event I’m on +1 for the more standardised syntax and the switch to using 
#directives, makes a lot of sense since these are really just customisable 
compiler symbols.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

[Антон Жилин via swift-evolution]

> Assuming these are defined in separate modules, how do we determine the
order of • and ~?

By default, priority between any two operators is undefined. If two modules
don't know about each other, but the user wishes to prioritize them, then
he will write:

#precedence(•, lessThan: ~)

If • suddenly wishes to cooperate with ~, then it will add directives:

#operator(~, fixity: infix, associativity: left)
#precedence(•, lessThan: ~)

It doesn't matter if ~ or user have already added them: if they do not
contain contradictory information, there will be no conflict.

> On a related note, I never encounter precedence issues because I always
use parenthesis, since I know I’ll just forget the precedence rules so it’d
be a mistake for me to rely on them. If we’re adding operators in
precedence hierarchies then that only makes it even harder to
learn/remember, so I wonder if we might actually be better served by
removing precedence entirely?

That's exactly what I'm trying to do! I propose that there should be no
hierarchy. Each pair of operators will have to define priority explicitly,
if they need it.

I'll give an example of what I mean by "removing hierarchy":

#precedence(+, lessThan: *)
#precedence(*, lessThan: ^)
2 ^ 3 + 6   # error
#precedence(+, lessThan: ^)
2 ^ 3 + 6   # now ok

- Anton

2016-04-03 13:31 GMT+03:00 Haravikk :

> Interesting, I like the idea of changing how precedence is defined, but
> I’m curious how under the new scheme we would go about inserting a new
> operator unambiguously? For example:
>
> #precedence(•, lessThan: *)
> #precedence(~, lessThan: *)
>
> Assuming these are defined in separate modules, how do we determine the
> order of • and ~?
>
> On a related note, I never encounter precedence issues because I always
> use parenthesis, since I know I’ll just forget the precedence rules so it’d
> be a mistake for me to rely on them. If we’re adding operators in
> precedence hierarchies then that only makes it even harder to
> learn/remember, so I wonder if we might actually be better served by
> removing precedence entirely? i.e- the compiler would instead require the
> use of parenthesis to eliminate ambiguity like so:
>
> let a = 5 + 6 // Correct, as there aren’t enough operators for ambiguity
> let b = 5 + 6 * 7 + 8 // Incorrect, as it relies on precedence to be
> meaningful
> let c = (5 + 6) * (7 + 8) // Correct, as parenthesis eliminates
> ambiguity/the need for precedence
>
> This not only eliminates the need to learn, remember and/or lookup
> precedence, but it’s clearer and avoids mistakes, and IMO it’s actually
> more readable despite the added noise.
>
> On 3 Apr 2016, at 10:36, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.
>
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Introduction
>
> Replace syntax of operator definition:
>
> infix operator <> { precedence 100 associativity left }
>
> With a directive:
>
> #operator(<>, fixity: infix, associativity: left)
>
> Also replace numeric definition of precedence with separate comparative
> precedence definitions:
>
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
>
> Swift-evolution thread: link to the discussion thread for that proposal
> 
>
> 
> Motivation
> Problems
> with numeric definition of precedence
>
> In the beginning, operators had nice precedence values: 90, 100, 110, 120,
> 130, 140, 150, 160.
>
> As time went, new and new operators were introduced. Precedence could not
> be simply changed, as this would be a breaking change. Ranges got
> precedence 135, as got precedence 132. ?? had precedence greater than <,
> but less thanas, so it had to be given precedence 131.
>
> Now it is not possible to insert any custom operator between < and ??. It
> is an inevitable consequence of current design: it will be impossible to
> insert an operator between two existing ones at some point.
>
> Problems
> with a single precedence hierarchy
>
> Currently, if an operator wants to define precedence by comparison to one
> operator, it must do so for all other operators.
>
> In many cases, this is not wished. Example: a & b < c is a common error
> pattern. a / b as Double is another one. C++ compilers sometimes emit
> warnings on these. Swift does not.
>
> The root of the problem is that 

Re: [swift-evolution] [Proposal] Custom operators

[Haravikk via swift-evolution]

Interesting, I like the idea of changing how precedence is defined, but I’m 
curious how under the new scheme we would go about inserting a new operator 
unambiguously? For example:

#precedence(•, lessThan: *)
#precedence(~, lessThan: *)

Assuming these are defined in separate modules, how do we determine the order 
of • and ~?

On a related note, I never encounter precedence issues because I always use 
parenthesis, since I know I’ll just forget the precedence rules so it’d be a 
mistake for me to rely on them. If we’re adding operators in precedence 
hierarchies then that only makes it even harder to learn/remember, so I wonder 
if we might actually be better served by removing precedence entirely? i.e- the 
compiler would instead require the use of parenthesis to eliminate ambiguity 
like so:

let a = 5 + 6   // Correct, as there aren’t enough 
operators for ambiguity
let b = 5 + 6 * 7 + 8   // Incorrect, as it relies on 
precedence to be meaningful
let c = (5 + 6) * (7 + 8)   // Correct, as parenthesis eliminates 
ambiguity/the need for precedence

This not only eliminates the need to learn, remember and/or lookup precedence, 
but it’s clearer and avoids mistakes, and IMO it’s actually more readable 
despite the added noise.

> On 3 Apr 2016, at 10:36, Антон Жилин via swift-evolution 
>  wrote:
> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators. I 
> insist that this time we should focus less on linguistic aspects.
> 
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>  
> 
> 
> Introduction
> 
> Replace syntax of operator definition:
> 
> infix operator <> { precedence 100 associativity left }
> With a directive:
> 
> #operator(<>, fixity: infix, associativity: left)
> Also replace numeric definition of precedence with separate comparative 
> precedence definitions:
> 
> #precedence(+, lessThan: *)
> #precedence(+, equalTo: -)
> Swift-evolution thread: link to the discussion thread for that proposal 
> 
>  
> Motivation
> 
>  
> Problems
>  with numeric definition of precedence
> 
> In the beginning, operators had nice precedence values: 90, 100, 110, 120, 
> 130, 140, 150, 160.
> 
> As time went, new and new operators were introduced. Precedence could not be 
> simply changed, as this would be a breaking change. Ranges got precedence 
> 135, as got precedence 132. ?? had precedence greater than <, but less 
> thanas, so it had to be given precedence 131.
> 
> Now it is not possible to insert any custom operator between < and ??. It is 
> an inevitable consequence of current design: it will be impossible to insert 
> an operator between two existing ones at some point.
> 
>  
> Problems
>  with a single precedence hierarchy
> 
> Currently, if an operator wants to define precedence by comparison to one 
> operator, it must do so for all other operators.
> 
> In many cases, this is not wished. Example: a & b < c is a common error 
> pattern. a / b as Double is another one. C++ compilers sometimes emit 
> warnings on these. Swift does not.
> 
> The root of the problem is that precedence is defined between all operators. 
> If & had precedence defined only by comparison to other bitwise operators and 
> / – only to arithmetic operators, we would have to place parentheses in such 
> places, not get subtle bugs, and not ever have to look at the huge operator 
> precedence table.
> 
>  
> Problems
>  with current operator definition syntax
> 
> Some argue that current operator syntax is not consistent with other language 
> constructs. Properties of operators have dictionary semantics and should be 
> defined as such. It is a rather weak argument right now, but after reworking 
> of precedence, the new syntax will be more to place. More reasons are given 
> below.
> 
>  
> Conflicts
>  of operator definitions
> 
> Consider two operator definitions in different modules.
> 
> Module A:
> 
> infix operator |> { precedence 137 associativity left }
> Module B:
> 
> infix operator 

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

[Goffredo Marocchi via swift-evolution]

It would be very interesting to see more examples dynamic loop conditions and 
dynamic loop increments using the Swifter for in loop with strides... without 
while :).

[[iOS messageWithData:ideas] broadcast]

> On 3 Apr 2016, at 09:19, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Apr 2, 2016 at 6:45 PM, John Heerema via swift-evolution
>  wrote:
>> Yes, there are many cases in which I believe that Swift
>> provides looping structures that are safer and easier to understand than
>> the
>> C-style For loop. I¹d even say most cases. But I work in the scientific and
>> engineering domains, and can point to many instances of looping structures
>> that
>> are easily expressed with a C-style For loop, but are clumsy to implement
>> without it.
>> 
>> In the world of the natural sciences, there are any number
>> of instances of loop increments that requires some kind of a calculation.
>> There
>> are any number of instances of dynamically calculated loop termination.
>> 
>> Swift¹s stride has some nice features for simple increments,
>> but also has some important limitations. Among them, it involves the two
>> step
>> process of first creating an enumerable set, and then iterating over it.
>> In the
>> natural sciences, it is not uncommon for complex loop increments to be
>> used in
>> loops that are executed millions of times.
>> 
>> Conceptually, creating an enumerable set, and then iterating over it,
>> reeks of the arrogance of assuming that computing resources are unlimited.
>> Even
>> though the compiler may optimize the stride into the loop structure, it
>> feels
>> like unnecessarily creating a gigantic enumerable set.
>> 
>> Whether we like it or not, the enduring popularity of the
>> C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
>> alternative that also provides the same flexibility. So don¹t take it
>> away. If
>> you don¹t like it (I don¹t always either), think of something that is
>> clearly
>> superior in 100% of use cases. Even then, I would argue against removing
>> it.
> 
> FWIW, as an anecdote, I've been working on a side project in the
> natural sciences using Swift and I haven't missed the C-style for;;
> loop much. It seemed a little irksome at first to refactor, but that
> was about it. Looking around at other languages, I'm also not seeing
> evidence that working in the natural sciences domain
> disproportionately requires these loops. For instance, Python (which
> has significant uptake in my corner of the natural sciences world) and
> Julia (the up-and-coming technical computing language) both lack
> C-style for;; syntax and the ++ and -- operators, which doesn't seem
> to have dampened the enthusiasm of my colleagues for those languages.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

[Xiaodi Wu via swift-evolution]

On Sat, Apr 2, 2016 at 6:45 PM, John Heerema via swift-evolution
 wrote:
> Yes, there are many cases in which I believe that Swift
> provides looping structures that are safer and easier to understand than
> the
> C-style For loop. I¹d even say most cases. But I work in the scientific and
> engineering domains, and can point to many instances of looping structures
> that
> are easily expressed with a C-style For loop, but are clumsy to implement
> without it.
>
> In the world of the natural sciences, there are any number
> of instances of loop increments that requires some kind of a calculation.
> There
> are any number of instances of dynamically calculated loop termination.
>
> Swift¹s stride has some nice features for simple increments,
> but also has some important limitations. Among them, it involves the two
> step
> process of first creating an enumerable set, and then iterating over it.
> In the
> natural sciences, it is not uncommon for complex loop increments to be
> used in
> loops that are executed millions of times.
>
> Conceptually, creating an enumerable set, and then iterating over it,
> reeks of the arrogance of assuming that computing resources are unlimited.
> Even
> though the compiler may optimize the stride into the loop structure, it
> feels
> like unnecessarily creating a gigantic enumerable set.
>
> Whether we like it or not, the enduring popularity of the
> C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
> alternative that also provides the same flexibility. So don¹t take it
> away. If
> you don¹t like it (I don¹t always either), think of something that is
> clearly
> superior in 100% of use cases. Even then, I would argue against removing
> it.

FWIW, as an anecdote, I've been working on a side project in the
natural sciences using Swift and I haven't missed the C-style for;;
loop much. It seemed a little irksome at first to refactor, but that
was about it. Looking around at other languages, I'm also not seeing
evidence that working in the natural sciences domain
disproportionately requires these loops. For instance, Python (which
has significant uptake in my corner of the natural sciences world) and
Julia (the up-and-coming technical computing language) both lack
C-style for;; syntax and the ++ and -- operators, which doesn't seem
to have dampened the enthusiasm of my colleagues for those languages.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution