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

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

In the poposed model, all relations are not transitive. Example:

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

Would it be better to have such indirect relations inferred? Or would it
put too much responsibility on the compiler?
Maybe add it to future directions?

Cycles of length >2 are also allowed. This was not added intentionally, but
follows from other specified rules.
Example: ^ (binary) < & (binary) < + < * < ^ (power). OK, & < + is a bit
stretched, otherwise quite logical.

> - I wonder if there are cases in the standard operators which would be
better modeled as a non-linear chain.
In the standard library, non-linearity will be primarily used to break a
single hierarchy into multiple small ones. I doubt that any trees or cycles
will form, although that would be good news.

- Anton

2016-04-04 8:55 GMT+03:00 David Waite :

> 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 <
> 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
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

[Daniel Dunbar via swift-evolution]

Hi Max,

The proposal refers to "the pkg-config specification", can you add a link to 
that? In particular, I am curious how SwiftPM will know where to look for those 
files.

 - Daniel

> On Mar 31, 2016, at 4:04 PM, Max Howell via swift-evolution 
>  wrote:
> 
> I have updated the proposal with everyone’s feedback:
> 
> SwiftPM System Module Search Paths
> 
> Proposal: SE- 
> 
> Author: Max Howell 
> Status: Awaiting review
> Review manager: Anders Bertelrud
>  
> Introduction
> 
> Swift is able to import C libraries in the same manner as Swift libraries.
> 
> For this to occur the library must be represented by a clang module-map file.
> 
> The current system for using these module-map files with SwiftPM works, but 
> with a number of caveats that must be addressed.
> 
>  
> Motivation
> 
> The current implementation of system module packages have a number of 
> problems:
> 
> Install locations vary across platforms and modulemap files require absolute 
> paths
> /usr/lib:/usr/local/lib is not always a sufficient -L search path
> /usr/include:/usr/local/include is not always a sufficient -I C compiler 
> search path
> Installing the system library is left up to the end-user to figure out
> For example to import a module map representing the GTK library, the include 
> search path must be supplemented with -I/usr/include/gtk so that a number of 
> includes in the gtk.h header can be sourced for the complete modular 
> definition of GTK.
> 
> For example to import a module map representing the GTK library a user must 
> first have a copy of GTK and its headers installed. On Debian based systems 
> the install name for this system package is libgtk-3-0-dev which is not 
> entirely intuitive.
> 
> For example, Homebrew and MacPorts on OS X install to prefixes other than 
> /usr. .modulemap files must specify headers with absolute paths. The standard 
> we encourage with modulemaps is for the headers to be specified with an 
> assumed prefix of /usr, but you will not find eg. jpeglib.h at 
> /usr/include/jpeglib.h if it is installed with Homebrew or MacPorts.
> 
>  
> Proposed
>  Solution
> 
> We propose that SwiftPM gains the ability to use the cross-platform 
> pkg-config tool so that it can query pkg-config for the missing path and flag 
> arguments.
> 
> We propose that SwiftPM gains the ability to use the cross-platform 
> pkg-config tool to identify when the system package is not installed to a 
> /usr and in such a case preprocess the modulemap changing the prefix it uses.
> 
> We propose that Package.swift is supplemented with metadata that provides the 
> package-install-name for specific platforms.
> 
>  
> Detailed
>  Design
> 
>  
> Solving
>  Path/Flags Issues
> 
> Some of our problems can be solved by using the cross platform tool: 
> pkg-config.
> 
> A C package can provide a pkg-config file (.pc) which describes:
> 
> Its install location
> Supplementary C-flags that should be used when compiling against this library
> Supplementary C-flags that should be used when linking against this library
> If SwiftPM used the .pc file that comes with packages, this solves problems 1 
> through 3.
> 
> Of the tickets we currently have open describing issues using 
> Swift-system-module-packages, reading the .pc file would fix all of them.
> 
> It is a convention to name the .pc file after the library link-name, so we 
> can determine which .pc file to ask pkg-configfor by parsing the .modulemap 
> file in the Swift package. However sometimes this is not true, (eg. GTK-3 on 
> Ubuntu), so we will make it possible to specify the .pc file name in 
> Package.swift.
> 
> pkg-config is not currently a dependency of the Swift toolchain, and thus to 
> avoid depending on it we will schedule work to interpret .pc files without 
> requiring pkg-config to be installed. The file format for .pc files is simple 
> and standard so despite reinventing the wheel, this is a low risk choice.
> 
>  
> Providing
>  Package Install Names

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

[Howard Lovatt via swift-evolution]

Looking at other languages:


   1. A Java like API would be:
  - mutating func remove(T) -> Void
  - mutating func remove(all: S) -> Void
  - func removed(T) -> Self
  - func removed(all: S) -> Self
  - Similarly for retain and add
  2. In Scala they primarily use operators, so a Scala like API would
   be:
  - func -=(inout Self, T) -> Void
  - func -=(inout Self, S) -> Void
  - func -(T) -> Self
  - func -(all: S) -> Self
  - Similarly for & and +


Either of these naming patterns seems better than those proposed :(.

  -- Howard.

On 4 April 2016 at 15:49, Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 <
> swift-evolution@swift.org>:
>
> 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
>
>
> ___
> 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

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

Thank you for a helpful answer!
I like the idea of overriding precedence from another module. We won't need
to introduce additional keywords or visibility for operators. I will add it
to the proposal.

I assume you mean precedence inside braces of operator, then operator scope
makes sense. Self operator could be omit as well, following the idea that
we are introducing a new operator and want to compare it to others:

infix operator * {
associativity: left
precedenceLess: ^
precedenceEqual: /
precedenceGreater: +
}
infix operator / {
associativity: left
precedenceLess: ^
precedenceEqual: *
precedenceGreater: +
}

Equivalent precedence rules would be allowed for symmetry in the operator
definitions.
We would still be able to reopen the scope and add precedence and
associativity rules.
I agree that this scheme has advantage of being a smaller change.

I'm still concerned about syntax.
Is it OK to have "less, equal, greater" in precedence name?
Is it OK to have both curly brackets and dictionary syntax (a precedent, I
guess)?
Is it OK to leave prefix and postfix operators always with empty braces?

Would it be better to have multiple precedence comparisons at once:
precedenceGreater: +, -, *, /
Or one comparison per line will be more readable?

I will add this to alternatives, but will not swap it with currently stated
syntax for now, waiting for some more response.

What do you think?

- Anton

2016-04-04 8:06 GMT+03:00 Maximilian Hünenberger :

> See inline
>
> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution <
> swift-evolution@swift.org>:
>
> 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
>
> ___
> 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

[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 in Packages subdirectory

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 
> Lattnermailto:clatt...@apple.com)>wrote:
> >  
> > > 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 
>>> parentheses in such places, not get subtle bugs, and not ever have to look 
>>> 

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 its

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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution maili

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] [Pitch] Custom Namespaces

[Andrey Tarantsov via swift-evolution]

Yeah, I'd say the namespaces should take a form of submodules, possibly defined 
by subdirectories or something like that. I.e. not defined explicitly in code.

A.


> On Apr 2, 2016, at 5:15 AM, Howard Lovatt via swift-evolution 
>  wrote:
> 
> Yes something in this space might be useful, but, and this is a significant 
> but, we do have modules and files to break code into. So it wouldn't be a top 
> priority.
> 
> On Wednesday, 30 March 2016, Niels Andriesse via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> At the moment, it's not possible to define custom namespaces. They can be 
> emulated using static members on an enum:
> 
> enum Foo {
>   static var bar: Bar
>   static func baz() { }
> }
> 
> This is not ideal, because:
> The case shown above is semantically speaking obviously not an enum and 
> shouldn't be presented as such.
> The members are required to be static unnecessarily.
> Not all top-level declarations can be nested like this (e.g. protocols).
> If we allow namespaces to be reused in different files within the same 
> module, this could potentially be used as a custom scope for access control 
> (e.g. using the proposed private(...) syntax, so in this case private(Foo)).
> Are there any plans to allow custom namespaces (for example as shown below)?
> 
> namespace Foo {
>   var bar: Bar
>   func baz() { }
> }
> 
> Alternatively, a similar situation could be achieved by introducing 
> submodules.
> 
> 
> -- 
> -- 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] 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 
> mailto: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 
>> > > 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] Feature proposal: Range operator with step

[Milos Rankovic via swift-evolution]

Thanks Xiaodi for so kindly bringing me up to speed. 

> This thread is really long and hard to follow
To my great embarrassment, I have only subsequent to my post realised that 
people kept returning to this thread and that I have as a result only seen the 
first burst of activity. Sincere apologies!!

> See if you like where things are headed.
Yes. Especially Dave A’s brainwave that:

Hmm, instead of defining a new protocol (Countable), 
what if we just use “Strideable where Stride : Integer”

> An older syntax is being restored in Swift 3: `stride(from: 1, to: 5, by: 2)` 
> and `stride(from: 1, through: 5, by: 2)`
This is ok. But it is also *only* ok… It does not mach the sheer sweetness of 
interval operators or the nil coalescing operator. It is not so Switly that 
such a common pattern makes me think of equivalent syntax in other languages 
with longing… In other words, I definitely think an operator-only syntax would 
be an irresistible alternative in almost every use case – if we could only come 
up with such operators without trespassing over existing API.

>> 3. The direction in which we advance from one end to another of the interval 
>> is provided twice: once by the order of the bounds and then again by the 
>> sign of the stride argument.
> The stride direction is strictly given by the sign of the last argument; 
> `stride(from: 1, to: -5, by: 2)` is an empty sequence, because you cannot get 
> from start to end by -2. See next comment for why I think this is a feature, 
> not a bug.
Personally, I think that both semantics are valid – i.e. I’m not persuaded that 
the latter is necessarily more intuitive or practical. There is some merit too 
in starting with an interval (requiring interval.start <= interval.end), that 
the stride argument is of type Self.Distance not Self.Stride, so that the 
stride direction is explicitly opted for once at the call site – e.g. alongs 
the lines of (with a better choice of the operator eventually):

for i in 1...5 > 2 {
i // 1, 3, 5
}

for i in 1...5 < 2 {
i // 5, 3, 1
}

This would still produce empty sequences when the stride is not taking you 
towards the end bound, but it might be argued that it also simplifies the 
mental model of what is going on: “there is this interval and I want to loop 
through it forwards or backwards with that step size”. Omitting the second 
operator and the last argument would default to the unit definition for the 
bound type (e.g. “where Stride : Integer”), else this would emit a compile time 
error.

> Dave A is making some big changes to Range (and Intervals are going away, 
> leaving only Range)
and
> `Range.striding(by:)` … 
I like this in principle, depending on what `Range` ends up becoming… For Swift 
2, I definitely prefer never touching the `Range` struct:

extension ClosedInterval where Bound : Strideable {
func stride(by stride: Bound.Stride) -> StrideThrough {
let (s, e) = stride < 0 ? (end, start) : (start, end)
return s.stride(through: e, by: stride)
}
}

extension HalfOpenInterval where Bound : Strideable {
func stride(by stride: Bound.Stride) -> StrideTo {
let (s, e) = stride < 0 ? (end, start) : (start, end)
return s.stride(to: e, by: stride)
}
}

(1...5).stride(by: 2)  // 1, 3, 5
(1..<5).stride(by: 2)  // 1, 3

(1...5).stride(by: -2) // 5, 3, 1
(1..<5).stride(by: -2) // 5, 3

Again, many thanks for your kind reply.

milos

> On 3 Apr 2016, at 06:17, Xiaodi Wu  wrote:
> 
> Milos, you make good points. This thread is really long and hard to
> follow, so I'll reply inline below with some observations that have
> been made in the past, which I think address some of them. See if you
> like where things are headed.
> 
> On Sat, Apr 2, 2016 at 8:05 PM, Milos Rankovic via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
>> `Strideable` types represent an often needed generalisation of `Range` and
>> `IntervalType`s. However, `Strideable`’s two `stride` methods are far too
>> verbose and unbalanced (in contrast to the natural look and feel of the two
>> interval operators). Examples like the following raise a number of issues:
>> 
>>1.stride(through: 5, by: 2)  // 1, 3, 5
>> 
>>1.stride(through: 5, by: -2) // []
>> 
>> 1. The method's verbosity keeps the bounds too far apart.
>> 
>> 2. The dot syntax suggests that something is being done to the start bound,
>> with the end bound playing the role of an argument, all of which does not
>> really reflect the semantics of the call.
> 
> An older syntax is being restored in Swift 3: `stride(from: 1, to: 5,
> by: 2)` and `stride(from: 1, through: 5, by: 2)`, and dot syntax is
> being removed. Bounds are now next to each other, and the start and
> end values are now visually equals.
> 
>> 3. The direction in which we advance from one end to another of the interval
>> is provided twice: once by the order of t

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 and / – only to arithm

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

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. Then, for 
> infix operators, go

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 precedence is defined between all
> op

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 |> { precedence 138 associa

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

[swift-evolution] [Proposal] Custom operators

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

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. Then, for
infix operators, goes optional associativity parameter that can be left or
right.
Comparative
precedence

Remove precedence property from operator definitions. Instead, introduce
#precedence directive:

#precedence(+, lessThan: *)
#precedence(*, equalTo: /)

Omission of parentheses is allowed only when precedence between the two
operators is defined.

1 + 2 * 3  // ok1 + 2 - 3  // error!
#precedence(-, equalTo: +)1 + 2 - 3  // now ok

Precedence equality can only be defined for operators with same
associativity.
Conflict
resolution

Precedence rules can be added freely across modules. Ability to omit
parentheses around more operators will not break any code in included
modules. On the other hand, conflicting precedence rules result in an error:

#precedence(*, lessThan: +)  // error, previously defined `+` < `*`

Operator definitions do nut cause conflicts, 

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

On Sat, Apr 2, 2016 at 8:30 PM, Stephen Canon  wrote:
> General numerics comments:
> We’ll want internal state and computation to be Double for Float or Double,
> and Float80 for Float80.

One argument why Float for Float might be sufficient:

1. Given that `Float(-20) + Float(1) * Float(19.9) ==
Float(-0.09375)`, -0.09375 *should* be a value in the sequence when
striding from Float(-20) to Float(1) by Float(0.1). Otherwise, it
could be astonishing for users that StrideTo is somehow more
accurate than bare arithmetic using Float, since the documentation
explains explicitly how the values are being calculated (for stride as
it is now, the documentation says "self, self + stride, self + stride
+ stride ... last", which I changed for floating point types to "self,
self + stride, self + stride * 2 ... last"). A user that wants
double-precision accuracy in that computation should explicitly cast
stride arguments to Double.

2. While there are definitely useful loops with more than 2**31 steps,
and I agree that we should ensure at least 2**53 steps for
`stride(...)` even on 32-bit systems, loops using
`stride(...)` with more than 2**24 steps should be rare. Users
who wish to go beyond 2**24 steps can always cast stride arguments to
Double, which has the benefit of being more explicit and less magical.

I've played with using Double for Double and Float for Float (which
confers, I think, the rest of the advantages over Int named below),
but Double for Float is definitely a new twist. One disadvantage is
that using Double internally for Float would require Float bounds to
be represented internally as Double bounds. I was trying to be clever
with the generics so that any stride(...) would be non-error-accumulating, but I can't think
of a way to do this while also avoiding catastrophic cancellation for
Float because the generic algorithm does not care that T and T.Stride
have the same precision or, for that matter, whether T is a floating
point type at all. Thoughts?

> This confers a couple significant advantages:
>
> - There are useful loops with more than 2**31 steps, which means having
> _step be Int is insufficient on 32-bit systems.  By contrast, 2**53 steps is
> indistinguishable from “infinite loop” for consumer systems (tens of days
> for a loop that does no actual work).  At some point, we will want to use a
> wider state, but Double is sufficient for the foreseeable future, and this
> can be an internal detail so it’s easy to change if/when we need to so.
>
> - Using Double is preferable to using Int64 because it allows us to avoid
> extra Int -> FP conversions, and avoids multi-word arithmetic on 32-bit
> systems.
>
> - Using Double internally for Float loops avoids catastrophic cancellation
> for loops that cross zero, e.g.:
>
> for x in stride(from: Float(-20), through: Float(1), by: Float(0.1)) {
> }
>
> If computed in Float, the last 20 values produced by this are:
>
> -0.09375, 0, 0.109375, 0.203125, 0.296875, 0.40625, 0.5, 0.609375, 0.703125,
> 0.796875, 0.90625, 1, 1.109375, 1.203125, 1.296875, 1.40625, 1.5, 1.609375,
> 1.703125, 1.796875, 1.90625
>
> Of course, it’s still possible to construct such examples for Double, but
> they require step size of such wildly disparate scale from the endpoints
> that you have to loop “forever” (hours/days) before the catastrophic
> cancellation becomes a significant concern.
>
> - Double is no less computationally efficient than Float on modern x86 or
> ARM.
>
> We should also make sure that we codegen _start + _step*_stride to a
> fused-multiply add when we have hardware support (x86 Haswell and later, all
> arm64, most current armv7).  This eliminates the catastrophic cancellation
> issue *entirely*, and is faster than a separate mul and add to boot.
>
> One specific question:
> I don’t see any reason to enforce that stride isn’t subnormal (and good
> reasons to allow it).  Why did you add that restriction?

The restriction was poorly thought out based on a vague notion that
"typically sized" ranges and very small strides would be somehow "not
good." I can also now think of some good reasons to change that as
well, such that what's enforced is only `stride.isFinite &&
!stride.isZero`.

> Other than those notes, this approach seems perfectly workable to me.

Hurray!

> – Steve
>
> On Apr 2, 2016, at 3:26 PM, Xiaodi Wu via swift-evolution
>  wrote:
>
> All righty, here's a proof-of-concept for non-error-accumulating
> stride based on the swift-3-indexing-model branch. I tried to
> incorporate the feedback received in the interim. Namely:
>
> 1. Only floating point types get this slightly more computationally
> intensive "new" stride; all other types get the "classic" stride. If
> accepted, this new code could be appended to Stride.swift and exist
> alongside current code, which doesn't need to be modified.
>
> 2. Based on discussions about UnsafePointer, etc., it dawned on me
> that what really determines whether a StrideTo accumulates error
>