Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0077: Improved operator declarations

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

Good news for me! I will surely submit a pull request today.

- Anton

2016-06-23 7:56 GMT+03:00 Chris Lattner :

>
> On Jun 22, 2016, at 8:24 PM, Joe Groff  wrote:
>
> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Hello Swift Community,
>
> The review of SE-0077: "Improved operator declarations" ran from May
> 17...23. On June 22, 2016, the core team decided to *return* the first
> version of this proposal for revision. The core design proposed is a clear
> win over the Swift 2 design, but the core team feels that revisions are
> necessary for usability and consistency with the rest of the language:
>
>
> One clarification: we still consider this to be in scope for Swift 3.
> Anton, we would appreciate it if you could revise the proposal, but if not,
> let us know.
>
> Thanks!
>
> -Chris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] State of @noescape ?

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

IIRC, there were at least the following counter-arguments:
1. One must break API and ABI compatibility to add @escaping to an existing
function
2. @nonescaping case is actually quite as common as @escaping

Frankly speaking, I support both of this arguments. I'll also add another
counter-argument.

Lazy map and filter will be marked as @escaping. Now consider the following
code:

func sum(_ array: [T], transform: (T) -> Int) -> Int {
return array.lazy.map(func).reduce(0, combine: +)
}

`transform` will be marked as @escaping, despite that `transform` never
actually escapes `sum`.

I believe that we should not accept nonescaping-by-default until we get a
powerful lifetimes system, as in Rust.

I think it makes sense to create a mini-proposal just for renaming of
@noescape to @nonescaping.

- Anton

2016-06-20 20:37 GMT+03:00 Austin Zheng :

> Trent Nadeau had prepared a proposal on Chris Lattner's recommendation,
> and there was a discussion thread a few weeks back:
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/19756.
>
> Not sure what the outcome was. I don't see any open PRs to merge the
> proposal into the swift-evolution repo.
>
> Austin
>
> On Mon, Jun 20, 2016 at 9:06 AM, Антон Жилин 
> wrote:
>
>> Hmm, I guess you are right, there would be no point keeping @nonescaping,
>> then.
>>
>> - Anton
>>
>> 2016-06-20 18:55 GMT+03:00 David Waite :
>>
>>>
>>> On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> * Rename @noescape to @nonescaping, and make @nonescaping the default
>>> case
>>>
>>> Do you mean replace @noescape with its opposite, @escaping?
>>>
>>> -DW
>>>
>>>
>>
>> ___
>> 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] State of @noescape ?

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

Hmm, I guess you are right, there would be no point keeping @nonescaping,
then.

- Anton

2016-06-20 18:55 GMT+03:00 David Waite :

>
> On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
> * Rename @noescape to @nonescaping, and make @nonescaping the default case
>
> Do you mean replace @noescape with its opposite, @escaping?
>
> -DW
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] State of @noescape ?

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

There were at least two possible solutions:
* Rename @noescape to @nonescaping
* Rename @noescape to @nonescaping, and make @nonescaping the default case

Everyone agrees that we would better resolve issues with @noescape until
Swift 3.
Has anyone prepared a proposal? Has anyone submitted a pull request?

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

Re: [swift-evolution] [Proposal] Fix lazy filter

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

I tested that behavior a bit more.
When lazy is called on non-collection that is converted to Array, it is
iterated once. `underestimatedCount` is not used.
When lazy is called on collection that is converted to Array, `count`
computed property is retrieved. Lazy collection types define `count` as
iterating and filtering through the underlying collection.

I think there are two issues:
1. underestimatedCount should require O(1) complexity. Array initializer
should always call it, as it perfectly suits its purpose
2. For collections, there should be choice to either use underestimateCount
(safe default) or count

The "right" interface should look like:

init(_ s: S)
init(_ c: C, preciseCount: Bool = false)

If getting precise count requires computations (otherwise it would be in
underestimatedCount), but programmer is sure that computations are cheap in
the specific case, he can opt in explicitly.

- Anton

Sun Jun 19 13:03:03 CDT 2016, Haravikk  wrote:

> I think I agree that it’s a bug; as stated in the proposal the current
> behaviour allows .underestimatedCount to consume the entire sequence
> because sequences are potentially destructive (so its only possible to
> guarantee access to each element once). Actually, the fact that this hasn’t
> been discovered sooner suggests the current tests don’t include the use of
> destructive sequences, which may need to be considered too, as all Sequence
> methods should work correctly with both destructive and non-destructive
> sequences.
> So yeah, I think having lazy sequences of this type return 0 for
> underestimateCount is the right solution for the time being.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Fix lazy filter

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

I've written a simple wrapper sequence that should be optimized out, and
performed a couple of microbenchmarks. Code:

===begin===
struct WrapperSequence : Sequence {
let base: S
init(_ base: S) { self.base = base }
func makeIterator() -> S.Iterator { return base.makeIterator() }
}

func predicate(num: Int) -> Bool {
return true
}

let sequence = WrapperSequence(1...4).lazy.filter(predicate)  // or
remove WrapperSequence
let array = Array(sequence)
===end===

Results:

1. Double-pass wins: num % 2 == 0
2. Single-pass wins: num % 2 == 0 && num % 3 == 0
3. Double-pass wins: num % 2 == 0 || num % 3 == 0
4. Double-pass wins: num % 2 == 0 || num % 3 == 0 || num % 5 == 0 || num %
7 == 0 || num % 11 == 0
5. Single-pass wins: num % 2 == 0 || num % 3 == 0 || num % 5 == 0 || num %
7 == 0 || num % 11 == 0 || num % 13 == 0

But I have to admit that double-pass algorithm CAN be faster if the one
knows what he is doing.
I conclude that we need an API to choose between the two algorithms, and
single-pass should be the safe default.

- Anton

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

> It's not a bug.  Measuring the length of the source before allocating
>> the destination array is usually a big win when compared to repeatedly
>> growing the array's memory and copying all its elements.
>> --
>> -Dave
>
>
> Usually yes, but not in the case of lazy filter. If predicate contains
> anything more than a dozen CPU instructions, single-pass version is faster.
>
> We often want the predicate to have side effects, but we cannot with
> current implementation: the side effects will be doubled.
>
> I also wonder if it's possible to allocate array with capacity of
> underlying collection (before all lazy stuff) and shrink it in the end.
>
> - Anton
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Fix lazy filter

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

>
> It's not a bug.  Measuring the length of the source before allocating
> the destination array is usually a big win when compared to repeatedly
> growing the array's memory and copying all its elements.
> --
> -Dave


Usually yes, but not in the case of lazy filter. If predicate contains
anything more than a dozen CPU instructions, single-pass version is faster.

We often want the predicate to have side effects, but we cannot with
current implementation: the side effects will be doubled.

I also wonder if it's possible to allocate array with capacity of
underlying collection (before all lazy stuff) and shrink it in the end.

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

[swift-evolution] [Proposal] Remove eager `map` and `filter`

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

1. Make sure that

Array(sequence.lazy.map { ... })   and   sequence.map { ... }
Array(sequence.lazy.filter { ... })   and   sequence.filter { ... }

are just as fast (with -O). "Fix lazy filter" proposal should help with
this.

2. Remove eager `map` and `filter`

3. Remove `lazy` property

sequence.map { ... }  will call lazy `map`, which is at least as fast as
eager version

4. Re-add `array` property to LazySequence

So that we can more easily convert to multipass sequence when needed.

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

[swift-evolution] [Proposal] Fix lazy filter

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

The proposal fixes LazyFilterSequence-to-Array conversion that calls
predicate twice for each element.

https://github.com/Anton3/swift-evolution/blob/fix-underestimate-count/proposals/-fix-underestimate-count.md

What do you think?

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

[swift-evolution] [Discussion] A Problem With SE-0025?

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

I believe that current keyword for that (private) is very confusing.
It's different from meaning in other languages.
Even when trying to describe its behaviour, we repeatedly use `scope`, not
`private`

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

Re: [swift-evolution] Nil coalescing operator precedence

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

What do you think about arithmetic and bitwise operators? Arithmetic and
casting? Should they have defined precedence?

- Anton

2016-06-15 21:17 GMT+03:00 Saagar Jha :

> We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous
> because they are borrowed, in this case from math. The same thing applies
> to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from
> the C-type languages) and behaves likewise. There is no need for
> parentheses-the only people who will think this is ambiguous is those who
> haven’t been introduced to it before. IMHO, requiring parentheses would be
> *more* ambiguous because you’re breaking precedent, people already know
> how it should work, without parentheses. Forcing them to use it breaks
> their prior knowledge. We don’t need to hand-hold people who *know* how
> it works. For those who don’t know, it’s a simple matter of reading it up
> (which they would be doing anyways to learn about it!)
>
> As for nil coalescing, it’s visually similar to the ternary operator and
> as such has similar behavior. Having a reminder in the Swift guide about
> its precedence should be enough, once users have learned it they don’t need
> to be reminded every time they use it through a warning.
>
>
> On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Maybe wise to wait to see if that proposal is accepted. FWIW, my last
>> interaction with the core team on operator precedence suggested that they
>> believed that they had arrived at the correct relative precedence values
>> and were not receptive to changing them.
>> On Wed, Jun 15, 2016 at 12:54 Антон Жилин  wrote:
>>
>>> I wonder if it's worth it to start a new thread right now.
>>> We could start discussing, what precedence relationships between
>>> opeartors should be, even *before* that proposal is accepted.
>>> If it's rejected though, that discussion is going to trash bin.
>>>
>>> - Anton
>>>
>>> 2016-06-15 19:52 GMT+03:00 Антон Жилин :
>>>
>>>> Back to associativity, I see nothing wrong with what  a ?? b ?? c
>>>>  does. Analogous constructions are found in Ruby, for example. Right
>>>> associativity exists so that we can do lazy evaluation, computing fallback
>>>> values only when required. Nothing terrible, again.
>>>>
>>>> - Anton
>>>>
>>>> 2016-06-15 19:15 GMT+03:00 Xiaodi Wu :
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution <
>>>>> swift-evolution@swift.org> wrote:
>>>>>
>>>>>> >  If precedence between two operators is undefined, we cannot omit
>>>>>> > parentheses.
>>>>>>
>>>>>> Hm.. Probably the initial problem could be solved with this? I.e. if
>>>>>> we'll have *no* defined precedence between math operators and between ??
>>>>>> and between ?: (and probably something else?)  ?
>>>>>>
>>>>>
>>>>> Sorry, I don't see it. The initial question was about chaining of ??
>>>>> operators. That's a problem with expectations about associativity and not
>>>>> about precedence, right?
>>>>>
>>>>>
>>>>>>
>>>>>> As for rules of precedence, I think it is really not important what
>>>>>> precedence will be assigned for ??/?: as in any case IMO most devs will 
>>>>>> not
>>>>>> remember this for sure in situation when one need to write/read such
>>>>>> complex expression.
>>>>>>
>>>>>> For me, probably I have some extreme opinion: if we have a mix of
>>>>>> operators from different domains (math and ?? for example) we need
>>>>>> parentheses to exclude any kind of ambiguity.
>>>>>>
>>>>>> On 15.06.2016 17:53, Антон Жилин wrote:
>>>>>>
>>>>>>> Nice points, I also think that unless operators are from the same
>>>>>>> domain,
>>>>>>> more parentheses is better.
>>>>>>> Other than that, what rules do we need? I can name these:
>>>>>>> 1. Assignment operators have lower precedence than most operators
>>>>>>> 2. Arithmetics has higher precedence than comparative and logical
>>>>>>> operators. I don't think that ??

Re: [swift-evolution] Nil coalescing operator precedence

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

I wonder if it's worth it to start a new thread right now.
We could start discussing, what precedence relationships between opeartors
should be, even *before* that proposal is accepted.
If it's rejected though, that discussion is going to trash bin.

- Anton

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

> Back to associativity, I see nothing wrong with what  a ?? b ?? c  does.
> Analogous constructions are found in Ruby, for example. Right associativity
> exists so that we can do lazy evaluation, computing fallback values only
> when required. Nothing terrible, again.
>
> - Anton
>
> 2016-06-15 19:15 GMT+03:00 Xiaodi Wu :
>
>>
>>
>> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> >  If precedence between two operators is undefined, we cannot omit
>>> > parentheses.
>>>
>>> Hm.. Probably the initial problem could be solved with this? I.e. if
>>> we'll have *no* defined precedence between math operators and between ??
>>> and between ?: (and probably something else?)  ?
>>>
>>
>> Sorry, I don't see it. The initial question was about chaining of ??
>> operators. That's a problem with expectations about associativity and not
>> about precedence, right?
>>
>>
>>>
>>> As for rules of precedence, I think it is really not important what
>>> precedence will be assigned for ??/?: as in any case IMO most devs will not
>>> remember this for sure in situation when one need to write/read such
>>> complex expression.
>>>
>>> For me, probably I have some extreme opinion: if we have a mix of
>>> operators from different domains (math and ?? for example) we need
>>> parentheses to exclude any kind of ambiguity.
>>>
>>> On 15.06.2016 17:53, Антон Жилин wrote:
>>>
>>>> Nice points, I also think that unless operators are from the same
>>>> domain,
>>>> more parentheses is better.
>>>> Other than that, what rules do we need? I can name these:
>>>> 1. Assignment operators have lower precedence than most operators
>>>> 2. Arithmetics has higher precedence than comparative and logical
>>>> operators. I don't think that ?? belongs to arithmetics, it's more like
>>>> control flow.
>>>> 3. Unary operators obviously have higher precedence than everything
>>>>
>>>> I didn't read se-0077 in details, so have no opinion. Probably you can
>>>>>
>>>> describe main ideas of it here in two words.
>>>> Replace numeric precedence with precedence relationships between pairs
>>>> of
>>>> operators. If precedence between two operators is undefined, we cannot
>>>> omit
>>>> parentheses.
>>>>
>>>> My thought was basically: "parentheses between some operators must be
>>>> enforced by the language" <=> "SE-0077 is needed"
>>>>
>>>> - Anton
>>>>
>>>> 2016-06-15 17:17 GMT+03:00 Vladimir.S >>> <mailto:sva...@gmail.com>>:
>>>>
>>>>
>>>>
>>>> On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:
>>>>
>>>> `b + c * d / e` is not, obviously.
>>>>
>>>>
>>>> obviously, for math operators it seems like we don't need any
>>>> clarifications
>>>>
>>>> `a ? b : c + x + y` -- I'd also say not, because, well, it's
>>>> ternary
>>>> operator, the special case that everyone should know (otherwise
>>>> it
>>>> looks
>>>> like a mess with ? and : operators).
>>>>
>>>>
>>>> Yes, it's ternary operator.  But is it
>>>> a ? b : (c + x + y)
>>>> or
>>>> (a ? b : c) + x + y
>>>>
>>>> IMO ambiguous.
>>>>
>>>> `a ?? x + y + z` -- maybe. If not for analogies with || and &&
>>>> and
>>>> knowing
>>>> about @autoclosure, I'd say that priority of ?? should be very
>>>> high.
>>>>
>>>>
>>>> The same, is it
>>>> a ?? (x + y + z)
>>>> or
>>>> (a ?? x) + y + z
>>>>
>>>> ? I.e. I'm not asking, just show that the question is not if we know
>>>>   

Re: [swift-evolution] Nil coalescing operator precedence

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

Back to associativity, I see nothing wrong with what  a ?? b ?? c  does.
Analogous constructions are found in Ruby, for example. Right associativity
exists so that we can do lazy evaluation, computing fallback values only
when required. Nothing terrible, again.

- Anton

2016-06-15 19:15 GMT+03:00 Xiaodi Wu :

>
>
> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> >  If precedence between two operators is undefined, we cannot omit
>> > parentheses.
>>
>> Hm.. Probably the initial problem could be solved with this? I.e. if
>> we'll have *no* defined precedence between math operators and between ??
>> and between ?: (and probably something else?)  ?
>>
>
> Sorry, I don't see it. The initial question was about chaining of ??
> operators. That's a problem with expectations about associativity and not
> about precedence, right?
>
>
>>
>> As for rules of precedence, I think it is really not important what
>> precedence will be assigned for ??/?: as in any case IMO most devs will not
>> remember this for sure in situation when one need to write/read such
>> complex expression.
>>
>> For me, probably I have some extreme opinion: if we have a mix of
>> operators from different domains (math and ?? for example) we need
>> parentheses to exclude any kind of ambiguity.
>>
>> On 15.06.2016 17:53, Антон Жилин wrote:
>>
>>> Nice points, I also think that unless operators are from the same domain,
>>> more parentheses is better.
>>> Other than that, what rules do we need? I can name these:
>>> 1. Assignment operators have lower precedence than most operators
>>> 2. Arithmetics has higher precedence than comparative and logical
>>> operators. I don't think that ?? belongs to arithmetics, it's more like
>>> control flow.
>>> 3. Unary operators obviously have higher precedence than everything
>>>
>>> I didn't read se-0077 in details, so have no opinion. Probably you can
>>>>
>>> describe main ideas of it here in two words.
>>> Replace numeric precedence with precedence relationships between pairs of
>>> operators. If precedence between two operators is undefined, we cannot
>>> omit
>>> parentheses.
>>>
>>> My thought was basically: "parentheses between some operators must be
>>> enforced by the language" <=> "SE-0077 is needed"
>>>
>>> - Anton
>>>
>>> 2016-06-15 17:17 GMT+03:00 Vladimir.S >> <mailto:sva...@gmail.com>>:
>>>
>>>
>>>
>>> On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:
>>>
>>> `b + c * d / e` is not, obviously.
>>>
>>>
>>> obviously, for math operators it seems like we don't need any
>>> clarifications
>>>
>>> `a ? b : c + x + y` -- I'd also say not, because, well, it's
>>> ternary
>>> operator, the special case that everyone should know (otherwise
>>> it
>>> looks
>>> like a mess with ? and : operators).
>>>
>>>
>>> Yes, it's ternary operator.  But is it
>>> a ? b : (c + x + y)
>>> or
>>> (a ? b : c) + x + y
>>>
>>> IMO ambiguous.
>>>
>>> `a ?? x + y + z` -- maybe. If not for analogies with || and &&
>>> and
>>> knowing
>>> about @autoclosure, I'd say that priority of ?? should be very
>>> high.
>>>
>>>
>>> The same, is it
>>> a ?? (x + y + z)
>>> or
>>> (a ?? x) + y + z
>>>
>>> ? I.e. I'm not asking, just show that the question is not if we know
>>> what does ?? mean, but how all the expression will be treated.
>>>
>>> IMO it's totally false assumption that most of developers(and poor
>>> beginners) do remember the the correct precedence in such expressions
>>> and in most cases will not make a bug and so we should not require
>>> the
>>> parentheses. Imagine how each such expression will be crystal clear
>>>     about the order of processing in *any* Swift source code you could
>>> find
>>> anywhere. IMO this will be great advantage of the language.
>>>
>>> Now that I think about it, if job of SE-0077 could be done with a
>>> lin

Re: [swift-evolution] Nil coalescing operator precedence

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

Nice points, I also think that unless operators are from the same domain,
more parentheses is better.
Other than that, what rules do we need? I can name these:
1. Assignment operators have lower precedence than most operators
2. Arithmetics has higher precedence than comparative and logical
operators. I don't think that ?? belongs to arithmetics, it's more like
control flow.
3. Unary operators obviously have higher precedence than everything

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

My thought was basically: "parentheses between some operators must be
enforced by the language" <=> "SE-0077 is needed"

- Anton

2016-06-15 17:17 GMT+03:00 Vladimir.S :

>
> On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:
>
>> `b + c * d / e` is not, obviously.
>>
>
> obviously, for math operators it seems like we don't need any
> clarifications
>
> `a ? b : c + x + y` -- I'd also say not, because, well, it's ternary
>> operator, the special case that everyone should know (otherwise it looks
>> like a mess with ? and : operators).
>>
>
> Yes, it's ternary operator.  But is it
> a ? b : (c + x + y)
> or
> (a ? b : c) + x + y
>
> IMO ambiguous.
>
> `a ?? x + y + z` -- maybe. If not for analogies with || and && and knowing
>> about @autoclosure, I'd say that priority of ?? should be very high.
>>
>>
> The same, is it
> a ?? (x + y + z)
> or
> (a ?? x) + y + z
>
> ? I.e. I'm not asking, just show that the question is not if we know what
> does ?? mean, but how all the expression will be treated.
>
> IMO it's totally false assumption that most of developers(and poor
> beginners) do remember the the correct precedence in such expressions and
> in most cases will not make a bug and so we should not require the
> parentheses. Imagine how each such expression will be crystal clear about
> the order of processing in *any* Swift source code you could find anywhere.
> IMO this will be great advantage of the language.
>
> Now that I think about it, if job of SE-0077 could be done with a linter,
>> then... do we still need it?
>>
>
> I didn't read se-0077 in details, so have no opinion. Probably you can
> describe main ideas of it here in two words.
>
>
>> - Anton
>>
>> 2016-06-15 16:00 GMT+03:00 Vladimir.S > <mailto:sva...@gmail.com>>:
>>
>> As I understand, the question is if
>>
>> `a ?? x + y + z`
>> and
>> `a ? b : c + x + y`
>> (or `b + c * d / e`)
>>
>> an "ambiguous case" ?
>>
>>
>> On 15.06.2016 15:42, Антон Жилин via swift-evolution wrote:
>>
>> It's tempting to mention SE-0077 in this context. If it's
>> accepted,
>> we will
>> be able to make omission of parentheses an error in ambiguous
>> cases.
>>
>> - Anton
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Nil coalescing operator precedence

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

`b + c * d / e` is not, obviously.
`a ? b : c + x + y` -- I'd also say not, because, well, it's ternary
operator, the special case that everyone should know (otherwise it looks
like a mess with ? and : operators).
`a ?? x + y + z` -- maybe. If not for analogies with || and && and knowing
about @autoclosure, I'd say that priority of ?? should be very high.

Now that I think about it, if job of SE-0077 could be done with a linter,
then... do we still need it?

- Anton

2016-06-15 16:00 GMT+03:00 Vladimir.S :

> As I understand, the question is if
>
> `a ?? x + y + z`
> and
> `a ? b : c + x + y`
> (or `b + c * d / e`)
>
> an "ambiguous case" ?
>
>
> On 15.06.2016 15:42, Антон Жилин via swift-evolution wrote:
>
>> It's tempting to mention SE-0077 in this context. If it's accepted, we
>> will
>> be able to make omission of parentheses an error in ambiguous cases.
>>
>> - Anton
>>
>>
>> ___
>> 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] Nil coalescing operator precedence

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

It's tempting to mention SE-0077 in this context. If it's accepted, we will
be able to make omission of parentheses an error in ambiguous cases.

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

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

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

Ah, I see. Then for-each will be the only usage of `where`, aside from
generics. I'm even more in favour of the proposal being discussed, then.

- Anton

2016-06-13 23:03 GMT+03:00 Brent Royal-Gordon :

> > Also, we should think about removing `where` from `while` loops.
> > We can copy `if` syntax to `while` conditions.
>
> SE-0099 applies to all constructs which use condition clauses, including
> `while`. The "Detailed Design" section even specifically mentions the
> `while` grammar rule. <
> https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md#detailed-design
> >
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Make `default` function parameter values more transparent

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

-1 to default parameters in protocols.

Default parameters fall into a bad category of function features.
Since I'm bad at explaining things, I'll give an example.

protocol A {
func call(block: @autoclosure () -> ())
}
protocol B {
func call(block: () -> ())
}

Now it's impossible to conform to both of these protocols.

@noescape is good, because we can conform to both protocols with a
@noescape function.
`throws` is good, because we can conform to both protocols with a
non-throwing function.

On the other hand, consider a case with defaulted parameters:

protocol A {
func foo(x: Int = 1)
}
protocol B {
func foo(x: Int = 2)
}

It's impossible to conform to both protocols at once.
Therefore, default parameters is together with @autoclosure and on the
opposite side of @noescape and `throws`. That is, on "ambiguous" side.
I would prefer to have as few such features as possible.

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

[swift-evolution] [Pitch] Retiring `where` from for-in loops

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

+1 to the proposal.
All arguments and counter-arguments are simple and understandable.
I think, we should just schedule a review, and Core team will make final
decision.

Also, we should think about removing `where` from `while` loops.
We can copy `if` syntax to `while` conditions.

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

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

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

Right. If associated type has the same value for both conformances, then
everything should be fine. Fixed that example.

- Anton

2016-06-13 0:15 GMT+03:00 Dan Appel :

> >if our protocol conforms to a protocol with associated type requirements,
> then we still can't conform to our protocol multiple times.
>
> I don't think so:
>
> protocol A {
>
> associatedtype TypeA
>
> }
>
>
> protocol B: A {
>
> func convert(from: TypeB) -> TypeA
>
> }
>
>
> struct C: A {
>
> typealias TypeA = String
>
> }
>
> extension C: B {
>
> func convert(from int: Int) -> String {
>
> return String(int)
>
> }
>
> }
>
> extension C: B {
>
> func convert(from double: Double) -> String {
>
> return String(double)
>
> }
>
> }
>
> Seems to me like the above should work fine: the associated type is
> declared once, but the generic protocol is conformed to multiple times.
>
> On Sun, Jun 12, 2016 at 1:22 PM Антон Жилин 
> wrote:
>
>> Copy of link to the proposal:
>>
>> https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md
>>
>> Inline:
>>
>> 2016-06-12 21:51 GMT+03:00 Dan Appel :
>>
>>> Awesome that you guys started this! I've been meaning to pitch it for a
>>> while. Couple notes:
>>>
>>> - in the motivation, you're conforming to SequenceType while defining a
>>> From protocol (just a typo I think)
>>>
>>
>> Fixed
>>
>>
>>> - the proposal should mention Brent's comments since it doesn't have a
>>> rebuttal to the "unlikely" status generic protocols were given in the
>>> generic manifesto. Brent does a great job of doing that
>>>
>>
>> Added a bold link
>>
>>
>>> - is there a way for generic protocols to still have associated types? I
>>> think that could have some interesting use cases.
>>>
>>
>> Generic protocols can contain associated types, but no type can conform
>> to multiple instances of such protocols.
>>
>> Actually, this limitation is more restricting than it seems, because if
>> our protocol conforms to a protocol with associated type requirements, then
>> we still can't conform to our protocol multiple times.
>>
>>
>>> Dan Appel
>>>
>>> On Sun, Jun 12, 2016 at 11:28 AM Антон Жилин 
>>> wrote:
>>>
>> Yes, everything that works on generic types should work for generic
 protocols. I'll add that.

 What won't work is declaring that  MyComparable : Comparable  iff  T ==
 Self. The same won't work for current non-generic protocols as well.
 Although that feature is highly requested, it is discussed in a
 separate proposal.

 - Anton

 2016-06-12 21:16 GMT+03:00 Xiaodi Wu :

>
>
> On Sun, Jun 12, 2016 at 8:01 AM, Антон Жилин <
> swift-evolution@swift.org> wrote:
>
>> I've prepared a proper draft:
>>
>>
>> https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md
>>
>>
> When you propose this:
> Syntax in protocol extensions
>
> protocol MyComparable {
>   func < (left: Self, right: T)
> }extension MyComparable {
>   func > (left: T, right: Self) {
> return right < left
>   }
> }
>
>
> Would it be possible for me to write something like:
>
> ```
> extension MyComparable { ... }
> ```
>

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

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

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

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

Copy of link to the proposal:
https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md

Inline:

2016-06-12 21:51 GMT+03:00 Dan Appel :

> Awesome that you guys started this! I've been meaning to pitch it for a
> while. Couple notes:
>
> - in the motivation, you're conforming to SequenceType while defining a
> From protocol (just a typo I think)
>

Fixed


> - the proposal should mention Brent's comments since it doesn't have a
> rebuttal to the "unlikely" status generic protocols were given in the
> generic manifesto. Brent does a great job of doing that
>

Added a bold link


> - is there a way for generic protocols to still have associated types? I
> think that could have some interesting use cases.
>

Generic protocols can contain associated types, but no type can conform to
multiple instances of such protocols.

Actually, this limitation is more restricting than it seems, because if our
protocol conforms to a protocol with associated type requirements, then we
still can't conform to our protocol multiple times.


> Dan Appel
>
> On Sun, Jun 12, 2016 at 11:28 AM Антон Жилин 
> wrote:
>
>> Yes, everything that works on generic types should work for generic
>> protocols. I'll add that.
>>
>> What won't work is declaring that  MyComparable : Comparable  iff  T ==
>> Self. The same won't work for current non-generic protocols as well.
>> Although that feature is highly requested, it is discussed in a separate
>> proposal.
>>
>> - Anton
>>
>> 2016-06-12 21:16 GMT+03:00 Xiaodi Wu :
>>
>>>
>>>
>>> On Sun, Jun 12, 2016 at 8:01 AM, Антон Жилин 
>>> wrote:
>>>
 I've prepared a proper draft:


 https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md


>>> When you propose this:
>>> Syntax in protocol extensions
>>>
>>> protocol MyComparable {
>>>   func < (left: Self, right: T)
>>> }extension MyComparable {
>>>   func > (left: T, right: Self) {
>>> return right < left
>>>   }
>>> }
>>>
>>>
>>> Would it be possible for me to write something like:
>>>
>>> ```
>>> extension MyComparable { ... }
>>> ```
>>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> Dan Appel
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

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

Yes, everything that works on generic types should work for generic
protocols. I'll add that.

What won't work is declaring that  MyComparable : Comparable  iff  T ==
Self. The same won't work for current non-generic protocols as well.
Although that feature is highly requested, it is discussed in a separate
proposal.

- Anton

2016-06-12 21:16 GMT+03:00 Xiaodi Wu :

>
>
> On Sun, Jun 12, 2016 at 8:01 AM, Антон Жилин 
> wrote:
>
>> I've prepared a proper draft:
>>
>>
>> https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md
>>
>>
> When you propose this:
> Syntax in protocol extensions
>
> protocol MyComparable {
>   func < (left: Self, right: T)
> }extension MyComparable {
>   func > (left: T, right: Self) {
> return right < left
>   }
> }
>
>
> Would it be possible for me to write something like:
>
> ```
> extension MyComparable { ... }
> ```
>
>
> - Anton
>>
>> 2016-06-10 17:18 GMT+03:00 Brent Royal-Gordon :
>>
>>> > FWIW they're marked as 'unlikely' here:
>>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-protocols
>>> >
>>> > It would probably be useful to have counterarguments against the
>>> points raised in that document if you want to prepare a proposal.
>>>
>>> Here's my counterargument.
>>>
>>> * * *
>>>
>>> Firstly, I think they're underestimating the feature's utility. Generic
>>> protocols (real generic protocols, not Sequence) are already
>>> needed to make several existing or likely future features work better. For
>>> instance:
>>>
>>> * Pattern matching
>>>
>>> Currently, if you want to customize your type's behavior in a `switch`
>>> statement, you do it in an ad hoc, almost Objective-C-like way: You define
>>> a free `~=` operator and the compiler resolves the overloads to magically
>>> find and use it. There is no way to constrain a generic parameter to "only
>>> types that can pattern match against type X", which seems like a pretty
>>> useful thing to offer. For instance, in the past people have suggested some
>>> sort of expression-based switch alternative. The lack of a pattern matching
>>> protocol makes this impossible to implement in either the standard library
>>> or your own code.
>>>
>>> If we had generic protocols, we could define a protocol for this
>>> matching operator and fix the issue:
>>>
>>> protocol Matchable {
>>> func ~= (pattern: Self, value: MatchingValue) -> Bool
>>> }
>>>
>>> protocol Equatable: Matchable {
>>> func == (lhs: Self, rhs: Self) -> Bool
>>> }
>>> func ~= (lhs: T, rhs: T) -> Bool {
>>> return lhs == rhs
>>> }
>>>
>>> extension Range: Equatable, Matchable {}
>>> func ~= (pattern: Range, value: Bound)
>>> -> Bool {
>>> return pattern.lowerBound <= value && value <
>>> pattern.upperBound
>>> }
>>>
>>> Then you could write, for instance, a PatternDictionary which took
>>> patterns instead of keys and, when subscripted, matched the key against
>>> each pattern until it found a matching one, then returned the corresponding
>>> value.
>>>
>>> * String interpolation
>>>
>>> Currently, StringInterpolationConvertible only offers an
>>> `init(stringInterpolationSegment: T)` initializer. That means you
>>> absolutely *must* permit any type to be interpolated into your type's
>>> string literals. This blocks certain important use cases, like a
>>> `LocalizedString` type which requires all strings it interacts with to pass
>>> through a localization API, from being statically checked. It also would
>>> normally require any type-specific behavior to be performed through runtime
>>> tests, but just as in `~=`, the Swift compiler applies compile-time magic
>>> to escape this restriction—you can write an
>>> `init(stringInterpolationSegment:)` with a concrete type, and that will be
>>> preferred over the generic one.
>>>
>>> In theory, it should be possible in current Swift to redefine
>>> StringInterpolationConvertible to allow you to restrict the interpolatable
>>> values by doing something like this:
>>>
>>> protocol StringInterpolationConvertible {
>>> associatedtype Interpolatable = Any
>>> init(stringInterpolation: Self...)
>>> init(stringInterpolationSegment expr: Interpolatable)
>>> }
>>>
>>> (This is no longer generic because I believe Interpolatable would have
>>> to be somehow constrained to only protocol types to make that work. But you
>>> get the idea.)
>>>
>>> However, in many uses, developers will want to support interpolation of
>>> many custom types which do not share a common supertype. For instance,
>>> LocalizedString might want to support interpolation of any LocalizedString,
>>> Date, Integer, or FloatingPoint number. However, since Integer and
>>> FloatingPoint are protocols, you cannot use an extension to make them
>>> retroactively conform to a common protocol

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

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

I've prepared a proper draft:

https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md

- Anton

2016-06-10 17:18 GMT+03:00 Brent Royal-Gordon :

> > FWIW they're marked as 'unlikely' here:
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-protocols
> >
> > It would probably be useful to have counterarguments against the points
> raised in that document if you want to prepare a proposal.
>
> Here's my counterargument.
>
> * * *
>
> Firstly, I think they're underestimating the feature's utility. Generic
> protocols (real generic protocols, not Sequence) are already
> needed to make several existing or likely future features work better. For
> instance:
>
> * Pattern matching
>
> Currently, if you want to customize your type's behavior in a `switch`
> statement, you do it in an ad hoc, almost Objective-C-like way: You define
> a free `~=` operator and the compiler resolves the overloads to magically
> find and use it. There is no way to constrain a generic parameter to "only
> types that can pattern match against type X", which seems like a pretty
> useful thing to offer. For instance, in the past people have suggested some
> sort of expression-based switch alternative. The lack of a pattern matching
> protocol makes this impossible to implement in either the standard library
> or your own code.
>
> If we had generic protocols, we could define a protocol for this matching
> operator and fix the issue:
>
> protocol Matchable {
> func ~= (pattern: Self, value: MatchingValue) -> Bool
> }
>
> protocol Equatable: Matchable {
> func == (lhs: Self, rhs: Self) -> Bool
> }
> func ~= (lhs: T, rhs: T) -> Bool {
> return lhs == rhs
> }
>
> extension Range: Equatable, Matchable {}
> func ~= (pattern: Range, value: Bound)
> -> Bool {
> return pattern.lowerBound <= value && value <
> pattern.upperBound
> }
>
> Then you could write, for instance, a PatternDictionary which took
> patterns instead of keys and, when subscripted, matched the key against
> each pattern until it found a matching one, then returned the corresponding
> value.
>
> * String interpolation
>
> Currently, StringInterpolationConvertible only offers an
> `init(stringInterpolationSegment: T)` initializer. That means you
> absolutely *must* permit any type to be interpolated into your type's
> string literals. This blocks certain important use cases, like a
> `LocalizedString` type which requires all strings it interacts with to pass
> through a localization API, from being statically checked. It also would
> normally require any type-specific behavior to be performed through runtime
> tests, but just as in `~=`, the Swift compiler applies compile-time magic
> to escape this restriction—you can write an
> `init(stringInterpolationSegment:)` with a concrete type, and that will be
> preferred over the generic one.
>
> In theory, it should be possible in current Swift to redefine
> StringInterpolationConvertible to allow you to restrict the interpolatable
> values by doing something like this:
>
> protocol StringInterpolationConvertible {
> associatedtype Interpolatable = Any
> init(stringInterpolation: Self...)
> init(stringInterpolationSegment expr: Interpolatable)
> }
>
> (This is no longer generic because I believe Interpolatable would have to
> be somehow constrained to only protocol types to make that work. But you
> get the idea.)
>
> However, in many uses, developers will want to support interpolation of
> many custom types which do not share a common supertype. For instance,
> LocalizedString might want to support interpolation of any LocalizedString,
> Date, Integer, or FloatingPoint number. However, since Integer and
> FloatingPoint are protocols, you cannot use an extension to make them
> retroactively conform to a common protocol with LocalizedString.
>
> With generic protocols, we could define StringInterpolationConvertible
> like this:
>
> protocol StringInterpolationConvertible {
> init(stringInterpolation: Self...)
> init(stringInterpolationSegment expr: Interpolatable)
> }
>
> And then say:
>
> extension LocalizedString:
> StringInterpolationConvertible,
> StringInterpolationConvertible,
> StringInterpolationConvertible {
> init(stringInterpolationSegment expr: LocalizedString) {
> self.init()
> self.components = expr.components
> }
> init(stringInterpolationSegment expr: Integer) {
> self.init()
> self.components.append(.integer(expr))
> }
> init(stringInterpolationSegment expr: FloatingPoint) {
> self.components.

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

I'm starting to worry about the proposal, too. Any news?

- Anton

2016-05-31 1:07 GMT+03:00 Антон Жилин :

> I assume that Core team is scheduling a discussion or already discussing
> the proposal, and that really takes time in our case.
>
> In reply to Brent, I think that we can start requiring `public` if (when?)
> operator visibility levels are added.
>
> - Anton
>
> 2016-05-24 13:53 GMT+03:00 Brent Royal-Gordon :
>
>> > > Can you qualify them with module names?
>> > Right now, I guess, no, although that would be nice to have. I agree
>> that this can be discussed later.
>>
>> I wonder if we should force people today to put a `public` keyword on
>> their `operator` and `precedence` (or whatever) declarations, so that when
>> we eventually *do* stop doing the weird global thing we're currently doing,
>> existing code won't break (as much).
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

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

use associated types
>> instead", so it seems natural to express concrete type as associated
>> type for protocol in generic syntax 
>>
>> Probably alternative syntax could look like:
>>
>> extension Int : From where .FromType = Float { }
>>
>> Also, it seems like this proposal could help to solve a problem with
>> the same name of associated type in different protocols:
>>
>> protocol One {
>>  associatedtype Element
>>      func foo(t: Element)
>>  }
>>
>> protocol Two {
>>  associatedtype Element
>>  func bar(t: Element)
>>  }
>>
>> struct OneTwo : One, Two {
>> func foo(t: Int) {}
>> func bar(t: String) {}
>> }
>> // type 'OneTwo' does not conform to protocol 'Two'
>> // candidate has non-matching type '(t: String) -> ()' [with Element =
>> Element]
>>
>> So, as I understand, will be possible
>> struct OneTwo : One, Two {
>> func foo(t: Int) {} // OneTwo.Element will be Int
>> func bar(t: String) {}
>>
>> }
>>
>> On 08.06.2016 22:07, Антон Жилин via swift-evolution wrote:
>>
>> ==Motivation==
>>
>> protocol From {
>> associatedtype FromType
>> init(_ value: FromType)
>> }
>>
>> The problem is, one type cannot implement multiple From
>> "conversions".
>>
>> ==Proposed solution==
>>
>> Allow specifying all associated types using generic syntax.
>>
>> extension Int : From { }
>> extension Int : From { }
>>
>> This is only allowed in conformance declarations.
>>
>> ==Future directions==
>>
>> We can replace all *Convertible protocols with From and Into,
>> which
>> will be
>> defined similarly to Rust.
>>
>> - Anton
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

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

A problem with my solution is that there is a conflict between
associatedtype declarations inherited from From and From.
Or in your example, associatedtype Element = Int  and  associatedtype
Element = String  are in conflict.
Another example:

protocol Computer {
associatedtype Internal
mutable func prepare() -> Internal
mutable func compute(input: Internal)
}

extension MyType : Computer { }
extension MyType : Computer { }

func test(input: inout T) {
let internal: T.Internal = input.prepare()
input.compute(internal)
}

What is T.Internal , Int or Double? I showed the problem very eplicitly,
but it would exist hidden in a much greater number of cases.

It's not that such resolution is impossible, but solution of Chris does not
have this problem at all: generic types do not create associated type
requirements.
In this case, there is no ambiguity:

protocol Computer {
mutable func prepare() -> Internal
mutable func compute(input: Internal)
}

extension MyType : Computer { }
extension MyType : Computer { }

func test>(input: inout T) {
let internal: I = input.prepare()
input.compute(internal)
}

test(MyType() as Computer)  // no ambiguity
test(MyType() as Computer)  // no ambiguity

- Anton

2016-06-09 17:25 GMT+03:00 Vladimir.S :

> I like the idea as associatedtype is playing the role of generic type and
> in extension we conforms to the protocol with some specific generic type as
> associated type.
>
> I mean the first idea probably could be
> protocol From {
>  init(_ value: T)
>  }
> but "protocols do not allow generic parameters; use associated types
> instead", so it seems natural to express concrete type as associated type
> for protocol in generic syntax 
>
> Probably alternative syntax could look like:
>
> extension Int : From where .FromType = Float { }
>
> Also, it seems like this proposal could help to solve a problem with the
> same name of associated type in different protocols:
>
> protocol One {
>  associatedtype Element
>  func foo(t: Element)
>  }
>
> protocol Two {
>  associatedtype Element
>  func bar(t: Element)
>  }
>
> struct OneTwo : One, Two {
> func foo(t: Int) {}
> func bar(t: String) {}
> }
> // type 'OneTwo' does not conform to protocol 'Two'
> // candidate has non-matching type '(t: String) -> ()' [with Element =
> Element]
>
> So, as I understand, will be possible
> struct OneTwo : One, Two {
> func foo(t: Int) {} // OneTwo.Element will be Int
> func bar(t: String) {}
>
> }
>
> On 08.06.2016 22:07, Антон Жилин via swift-evolution wrote:
>
>> ==Motivation==
>>
>> protocol From {
>> associatedtype FromType
>> init(_ value: FromType)
>> }
>>
>> The problem is, one type cannot implement multiple From "conversions".
>>
>> ==Proposed solution==
>>
>> Allow specifying all associated types using generic syntax.
>>
>> extension Int : From { }
>> extension Int : From { }
>>
>> This is only allowed in conformance declarations.
>>
>> ==Future directions==
>>
>> We can replace all *Convertible protocols with From and Into, which will
>> be
>> defined similarly to Rust.
>>
>> - Anton
>>
>>
>> ___
>> 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] Remove nil and NilLiteralConvertible

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

(No joking)
Points:

1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }

Now it looks like this:
if x != .none { ... }

If at this point we had a proposal to add nil as a replacement for .none,
would we accept it?

2. nil is very generic, it only approximately allows to express the
intentions.
In case of Optional, .none is clearer. In case of JSON processing, .null is
clearer. In case of a semantically nullable struct, NilLiteralConvertible
usually goes to default constructor.

3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.

4. There should be a single consistent terminology: no value in Swift
equals none.

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

[swift-evolution] [Draft] Allow multiple conformances to the same protocol

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

==Motivation==

protocol From {
associatedtype FromType
init(_ value: FromType)
}

The problem is, one type cannot implement multiple From "conversions".

==Proposed solution==

Allow specifying all associated types using generic syntax.

extension Int : From { }
extension Int : From { }

This is only allowed in conformance declarations.

==Future directions==

We can replace all *Convertible protocols with From and Into, which will be
defined similarly to Rust.

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

Re: [swift-evolution] Discussion: Why is "nil" not "none"

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

I think you should explore the direction of removing NilLiteralConvertible
entirely, together with nil. My example could instead use:

let tree: JSON = ["name": "Alex", "age": 20, "email": .null]

Rationale would be that when nil was added to the language, enum
constructors could not omit their types. Now there is no reason for nil,
especially that it makes developers use only approximately suitable terms.

- Anton

2016-06-08 19:12 GMT+03:00 Brandon Knope :

>
> On Jun 8, 2016, at 11:54 AM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The difference between  nil  and  .none  is that the former is more
> "generic" than the latter.
>
> NilLiteralConvertible protocol expresses types that can contain "null" as
> legal values. `nil` does not have a type, it's just a token that is casted
> to whatever NilLiteralConvertible type is expected. It is used in JSON
> libraries, for example:
>
> let tree: JSON = ["name": "Alex", "age": 20, "email": nil]
>
> Here, nil would be inferred to have our custom JSON type.
> The same example with  none  would look a bit more weird:
>
> let tree: JSON = ["name": "Alex", "age": 20, "email": none]
>
> None of what type? Of String? Of Int? Of JSON? There are no optionals in
> this code. And a "null" present in JSON is different than no JSON in Swift.
>
>
> I have seen an example like this several times. In every case, I find the
> “none” one to be clearer. Why? Because it indicates that there is no email.
> nil to me looks like it could be a null pointer that could have bad
> consequences when accessed
>
> nil is special word that we are use to from other languages. It *sounds*
> natural in this case because it is familiar.
>
> I am not familiar with JSON libraries, but I don’t think that should guide
> the direction on which way to go.
>
> Also,* I am more specifically referring to nil with the use of optionals,
> not NilLiteralConvertible:*
>
> let i: Int? = nil
> let i: Int? = .none
>
> There are two ways to write the same thing with one being far clearer in
> my opinion. What does nil mean in this case? It precisely represents
> Optional.none making it somewhat redundant and surprising considering
> how nil is used in other languages.
>
> More specifically, what is nil? 0? A pointer? A representation of nothing
> (again implying none!)?
>
> I am very curious how new programmers coming to Swift as their first
> language would react to using nil in other languages. I think they would be
> very surprised.
>
>
> Optional is the most significant example of NilLiteralConvertible, but
> there are other users that would suffer from renaming. We could remove
> NilLiteralConvertible at all, but look at the example in this case:
>
> let tree: JSON = ["name": "Alex", "age": 20, "email": JSON.nullValue]
>
>
> This is somewhat more explicit and clearer in my opinion. Again, I am not
> familiar with JSON libraries so this could be why it looks clearer to me.
>
> From your response, I see the words “nil”, “null”, and “none”. Doesn’t
> this seem a little excessive and maybe confusing for people?
>
> Thanks,
> Brandon
>
>
> That would hurt immersion of the DSL.
>
> I think some Core team member told that they intentionally keep two ways
> of handling Optional: one using nil, and the other treating it like other
> enums.
>
> - Anton
> ___
> 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] Discussion: Why is "nil" not "none"

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

The difference between  nil  and  .none  is that the former is more
"generic" than the latter.

NilLiteralConvertible protocol expresses types that can contain "null" as
legal values. `nil` does not have a type, it's just a token that is casted
to whatever NilLiteralConvertible type is expected. It is used in JSON
libraries, for example:

let tree: JSON = ["name": "Alex", "age": 20, "email": nil]

Here, nil would be inferred to have our custom JSON type.
The same example with  none  would look a bit more weird:

let tree: JSON = ["name": "Alex", "age": 20, "email": none]

None of what type? Of String? Of Int? Of JSON? There are no optionals in
this code. And a "null" present in JSON is different than no JSON in Swift.

Optional is the most significant example of NilLiteralConvertible, but
there are other users that would suffer from renaming. We could remove
NilLiteralConvertible at all, but look at the example in this case:

let tree: JSON = ["name": "Alex", "age": 20, "email": JSON.nullValue]

That would hurt immersion of the DSL.

I think some Core team member told that they intentionally keep two ways of
handling Optional: one using nil, and the other treating it like other
enums.

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

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

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

By Void I meant Haskell's Void, or Swift's Never type. Swift's Void is
Haskell's ().

And I had an error there. Integer -> Void  contains two elements: a
function that always returns _|_, and an _|_. In Swift, the first case
corresponds to crash while executing function, and second case corresponds
to crash while computing a result of function type.

- Anton

2016-06-08 11:28 GMT+03:00 Антон Жилин :

> I'll talk about how "bottom" mechanic works there. (I'm not a Haskell
> expert, but I'll at least try ;) )
>
> Firstly, there is a Void type in standard library, which is exactly what
>  enum Never {}  in Swift is.
> Pretty trivial: it is useful as a parameter of higher kinded types, e.g.
> Either.
>
> Then, there is bottom. Long story short, each type in Haskell includes an
> undefined (bottom, _|_) value. That corresponds to partially defined
> functions in set theory.
>
> Example 1: Integer -> Integer  function can either return a Z number, or
> be undefined at that input (return bottom)
> Example 2: ()  type actually contains two elements: () and _|_
> Example 3: Void  contains one element: _|_
>
> Bottom value results in an error on most occasions.
>
> What does returning Void mean? In set theory, set of  Integer -> Void  is
> an empty set. In type theory,  Integer -> Void  can contain a single
> element that returns bottom.
>
> Applying that to Swift, we express bottom value by not returning on a
> particular input (due to a crash or an infinite loop). We are going to
> express bottom type by Never (or aliases). The only way to return bottom
> type is as well going to be returning bottom value (in Swift meaning).
>
> There is also such a function in Haskell:  absurd :: forall a. Void -> a
> Of course, it just returns bottom value of type a. The philosophy of this
> is "from false follows anything" or like, "if we are going to crash, then
> we can do anything".
> Based on this, we can implement conversions from Void to any type in
> Swift. It would look like:
>
> func implementContract() -> Int {
> return fatalError("unimplemented")
> }
>
> `return` is crucial here.
> This is what I suggest to change in the proposal.
>
> - Anton
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Draft] Change @noreturn to unconstructible return type

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

I'll talk about how "bottom" mechanic works there. (I'm not a Haskell
expert, but I'll at least try ;) )

Firstly, there is a Void type in standard library, which is exactly what
 enum Never {}  in Swift is.
Pretty trivial: it is useful as a parameter of higher kinded types, e.g.
Either.

Then, there is bottom. Long story short, each type in Haskell includes an
undefined (bottom, _|_) value. That corresponds to partially defined
functions in set theory.

Example 1: Integer -> Integer  function can either return a Z number, or be
undefined at that input (return bottom)
Example 2: ()  type actually contains two elements: () and _|_
Example 3: Void  contains one element: _|_

Bottom value results in an error on most occasions.

What does returning Void mean? In set theory, set of  Integer -> Void  is
an empty set. In type theory,  Integer -> Void  can contain a single
element that returns bottom.

Applying that to Swift, we express bottom value by not returning on a
particular input (due to a crash or an infinite loop). We are going to
express bottom type by Never (or aliases). The only way to return bottom
type is as well going to be returning bottom value (in Swift meaning).

There is also such a function in Haskell:  absurd :: forall a. Void -> a
Of course, it just returns bottom value of type a. The philosophy of this
is "from false follows anything" or like, "if we are going to crash, then
we can do anything".
Based on this, we can implement conversions from Void to any type in Swift.
It would look like:

func implementContract() -> Int {
return fatalError("unimplemented")
}

`return` is crucial here.
This is what I suggest to change in the proposal.

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

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

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

>
> @noreturn func error(msg: String = "") -> T {
> fatalError("bottom: \(msg)")
> }
> has to be written as
> func error(msg: String = "") -> T {
> fatalError("bottom: \(msg)")
> }
> It still returns bottom, but there is no way to say so in the declaration.
> The proposal just made the language less expressive!


Do we need to? One of use cases of this feature is to prototype using
unimplemented functions, i.e. lying about return type. In other cases,
return type of this function should be NoReturn/Never, as well.

You can write a foo-function that is really unintuitive:
> func foo() -> NoReturn {
>let x = fatalError("crash please")
>print("1+1=2")
>return x
> }


This is called "unreachable code", and this should give the same warning as
is currently given in such cases. Also you can currently create
sufficiently complex unreachable code that does not trigger a warning, and
nothing will change in that aspect.

Thinking about bottom-like behaviour, it would be a strict extension of
functionality of Never, so it can be discussed later in a separate proposal.

- Anton

2016-06-06 22:40 GMT+03:00 Michael Peternell :

>
> > Am 06.06.2016 um 00:53 schrieb Charles Srstka  >:
> >
> >> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution <
> swift-evolution@swift.org>:
> >>>
> >>> The following names were suggested: NoReturn, Bottom, None, Never.
> >>> I would pick None, because it looks like opposite to Any and fits
> nicely in generic types.
> >>
> >> I would like to call the type `Void`. `Void` is a type with zero
> possible values. The current `Void` would have to be renamed to `Unit`, the
> data type with exactly one possible value. Less C, More Haskell :) But
> wait, that's not really Haskell-ish, and it's not C-ish either.
> >
> > That is the most confusing possible thing that this could possibly be
> called. Seeing a Void return will cause anyone coming from a C, C++, ObjC,
> etc. background to think of something that is definitely *not* a no-return
> function.
>
> I agree. For this reason, my email continued after that paragraph. I
> deliberately ended the last sentence of that paragraph with "But wait,
> that's not really..."
>
> There is a really really good reason why Haskell doesn't have a named
> "bottom type" like "None" or "Void". The bottom type has type `forall a.
> a`, corresponding to the mathematical fact that from "false" follows
> anything. Assigning a bottom type to a variable makes only sense in
> Haskell, because it uses lazy evaluation. With strict evaluation, a bottom
> type is just confusing at best. And a `Nothing` type corresponds to
> Haskell's `Void` type, not to its bottom type - a really exotic type that
> is seldom used. Its not consistent to have a @noreturn-function return
> `Nothing` instead, because `Nothing` that's not a proper type. You can
> write a foo-function that is really unintuitive:
>
> func foo() -> NoReturn {
>let x = fatalError("crash please")
>print("1+1=2")
>return x
> }
>
> Shouldn't we all just try to understand the rationale for the current
> language behavior before we try to propose changes?
>
> E.g. with the proposal, the following function:
>
> @noreturn func error(msg: String = "") -> T {
> fatalError("bottom: \(msg)")
> }
>
> has to be written as
>
> func error(msg: String = "") -> T {
> fatalError("bottom: \(msg)")
> }
>
> It still returns bottom, but there is no way to say so in the declaration.
> The proposal just made the language less expressive!
>
> See also:
> https://en.wikibooks.org/wiki/Haskell/Denotational_semantics
> for a more in-depth explanation why "bottom" is not an ordinary type with
> a name.
>
> -Michael
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

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

> Why? The compiler flags an error if it can statically prove a trapping
overflow will occur. Why shouldn't it flag an error if it can statically
prove a force unwrap will fail?
> If one of the associated values is Bottom/None/Never, how is my code
improved by the fact that I still need a case for it in a `switch`
statement?

Nice points! I tried to keep things as simple as possible, but it looks
like such special cases would really help here.

> I wonder if perhaps your experience with Haskell has given you a false
impression of how this would work in Swift. Haskell is a pervasively lazy
language. Every operation in Haskell is lazy and you have little control
over when anything executes. Because of this, `undefined` values can
persist for long periods of time and spread deep into your code. But Swift
is not pervasively lazy; it is (relatively) simple and obvious to figure
out when a given piece of code will run. When you run a
Bottom/None/Never-returning expression, it does not return. Period. There
is no "it does not return six files away from where you wrote it".

We need Never to be subtype of any type, including structs and final
classes, but it's difficult to wrap my head around this while we don't have
subtypes in Swift.
Anyway, I see little to no problems with this. Just the proposal is going
to become longer than I expected :)

- Anton

2016-06-06 11:12 GMT+03:00 Brent Royal-Gordon :

> > The following names were suggested: NoReturn, Bottom, None, Never.
> > I would pick None, because it looks like opposite to Any and fits nicely
> in generic types.
>
> I discussed all of these options and more. The issue I see with None is
> that it could easily be interpreted as Void to those without a C
> background. (Actually, it's probably the most *natural* name for what we
> call Void.) `func x() -> None` reads like it returns nothing. `func x() ->
> Never` reads like it does not return.
>
> > I would prefer the type to be simple, and be implemented as a case-less
> enum (not a bottom value, as in Haskell).
> >
> > None should be a usual enum, with no compiler magic except that
> functions returning None are equivalent to current @noreturn.
>
> Could you elaborate on this? I think it would be really useful to have a
> bottom type—useful to the point that, within minutes of deciding to think
> of examples, I quickly came up with some really good ones. Why don't you
> like having a bottom type?
>
> > Example 1.
> > let x: None?
> > // ...
> > let y = x!
> >
> > It will trap in runtime not because we discover scary bottom thing, as
> in Haskell, but because x had value Optional.none at that moment and we
> asserted otherwise.
>
> I'm not sure what you mean by this. There is no "scary bottom thing";
> Bottom or None or Never or whatever you call it is still an empty type, and
> the unwrap still fails because the value is `.none`, not `.some`. The only
> difference is that you can say something like `let total = basicBooks +
> fatalError("implement pro books counting")` in an expression and it will
> compile, since Bottom/None/Never is a subtype of `basicBooks`'s type—it's
> simply one that will never actually be created.
>
> I wonder if perhaps your experience with Haskell has given you a false
> impression of how this would work in Swift. Haskell is a pervasively lazy
> language. Every operation in Haskell is lazy and you have little control
> over when anything executes. Because of this, `undefined` values can
> persist for long periods of time and spread deep into your code. But Swift
> is not pervasively lazy; it is (relatively) simple and obvious to figure
> out when a given piece of code will run. When you run a
> Bottom/None/Never-returning expression, it does not return. Period. There
> is no "it does not return six files away from where you wrote it".
>
> > We could prove that it is always true in this case, but compiler must be
> stupid about this.
>
> Why? The compiler flags an error if it can statically prove a trapping
> overflow will occur. Why shouldn't it flag an error if it can statically
> prove a force unwrap will fail?
>
> > Example 2.
> > Compiler should allow including None in structures. Error will show up
> in constructor, when we will not be able to initialize the field.
>
> Well, you can assign the field from a call to something like
> `fatalError()`, but of course that will crash at runtime. (That's true
> whether we use a bottom type or an empty type, by the way.)
>
> > Example 3.
> > None in an enum case makes that case never appear in values of such a
> type. But compiler can not know about that.
>
> Again: Why? If one of the associated values is Bottom/None/Never, how is
> my code improved by the fact that I still need a case for it in a `switch`
> statement? What's the advantage of not being able to eliminate dead code,
> or call out code that will inevitably fail? We already want these things
> for other uses of Bottom/None/Never, like dead code elimination after a
> preconditio

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

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

Bringing up an old idea, we could rewrite `rethrows` using Never and throws
type specification:

func call(block: () throws E -> T) throws E -> T

But this requires some compiler magic: non-throwing functions should
effectively become functions throwing Never.

- Anton

2016-06-06 1:53 GMT+03:00 Charles Srstka :

> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution <
> swift-evolution@swift.org>:
>
> The following names were suggested: NoReturn, Bottom, None, Never.
> I would pick None, because it looks like opposite to Any and fits nicely
> in generic types.
>
>
> I would like to call the type `Void`. `Void` is a type with zero possible
> values. The current `Void` would have to be renamed to `Unit`, the data
> type with exactly one possible value. Less C, More Haskell :) But wait,
> that's not really Haskell-ish, and it's not C-ish either.
>
>
> That is the most confusing possible thing that this could possibly be
> called. Seeing a Void return will cause anyone coming from a C, C++, ObjC,
> etc. background to think of something that is definitely *not* a no-return
> function.
>
> Charles
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

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

I have to agree with Never. None is for Optional.none, and it looks like
Void in function signature.
I would argue that Never could not be mistaken as a synonym for Void.

protocol Nothing {}
is exactly how Any could be defined, so it's an opposite entity.
We could define that as a protocol that nothing can confirm to, but
approach with empty enum seems more natural to me, because it does not
require any extra work from the compiler.

- Anton

2016-06-05 23:54 GMT+03:00 T.J. Usiyan :

> *please* let us not repeat the mostly avoidable
> challenging-to-explain-to-newcomers-and-vetarans-alike situation that we
> had in Obj-C with regard to `nil`.
>
> nil
> Nil
> NULL
> NSNull
> nullptr
> kCFNull
> __DARWIN_NULL
>
> are the representations of 'don't have' that come to mind.
>
>
>
> On Sun, Jun 5, 2016 at 2:39 PM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> While None is probably the best way to describe the opposite of Any, it
>> would be often mistaken for .None (i.e. Optional) by newcomers to the
>> language.
>>
>> I'd personally prefer calling it "Nil" (capital N), which really means
>> "nonexistent". The same way ObjC had "nil" for "id" and "Nil" for Class.
>> Possibly, to avoid confusion with nil, calling it Null? Though that might
>> get confused with NSNull, once the NS prefix gets dropped.
>>
>> Or "Nothing" as in Scala.
>>
>> > On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > The following names were suggested: NoReturn, Bottom, None, Never.
>> > I would pick None, because it looks like opposite to Any and fits
>> nicely in generic types.
>> >
>> > I would prefer the type to be simple, and be implemented as a case-less
>> enum (not a bottom value, as in Haskell).
>> >
>> > None should be a usual enum, with no compiler magic except that
>> functions returning None are equivalent to current @noreturn.
>> >
>> > Example 1.
>> > let x: None?
>> > // ...
>> > let y = x!
>> >
>> > It will trap in runtime not because we discover scary bottom thing, as
>> in Haskell, but because x had value Optional.none at that moment and we
>> asserted otherwise.
>> > We could prove that it is always true in this case, but compiler must
>> be stupid about this.
>> >
>> > Example 2.
>> > Compiler should allow including None in structures. Error will show up
>> in constructor, when we will not be able to initialize the field.
>> >
>> > Example 3.
>> > None in an enum case makes that case never appear in values of such a
>> type. But compiler can not know about that.
>> >
>> > - Anton
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Draft] Change @noreturn to unconstructible return type

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

The following names were suggested: NoReturn, Bottom, None, Never.
I would pick None, because it looks like opposite to Any and fits nicely in
generic types.

I would prefer the type to be simple, and be implemented as a case-less
enum (not a bottom value, as in Haskell).

None should be a usual enum, with no compiler magic except that functions
returning None are equivalent to current @noreturn.

Example 1.
let x: None?
// ...
let y = x!

It will trap in runtime not because we discover scary bottom thing, as in
Haskell, but because x had value Optional.none at that moment and we
asserted otherwise.
We could prove that it is always true in this case, but compiler must be
stupid about this.

Example 2.
Compiler should allow including None in structures. Error will show up in
constructor, when we will not be able to initialize the field.

Example 3.
None in an enum case makes that case never appear in values of such a type.
But compiler can not know about that.

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

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

I assume that Core team is scheduling a discussion or already discussing
the proposal, and that really takes time in our case.

In reply to Brent, I think that we can start requiring `public` if (when?)
operator visibility levels are added.

- Anton

2016-05-24 13:53 GMT+03:00 Brent Royal-Gordon :

> > > Can you qualify them with module names?
> > Right now, I guess, no, although that would be nice to have. I agree
> that this can be discussed later.
>
> I wonder if we should force people today to put a `public` keyword on
> their `operator` and `precedence` (or whatever) declarations, so that when
> we eventually *do* stop doing the weird global thing we're currently doing,
> existing code won't break (as much).
>
> --
> Brent Royal-Gordon
> Architechies
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

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

> Then, the protocol author is responsible for providing a generic global
trampoline operator that is constrained by the protocol type and delegates
to the static operator on that type:

This feels like an unnatural "hack" to me. This proposal definitely needs
more discussion.

Personally, I'd prefer the following:
* allow `self` internal parameter name in functions
* move `prefix` and `postfix` to external parameter name

Example:

begin

protocol SomeProtocol {
mutating func +(left self: Self, right: Self)
func ~(prefix self: Self) -> Self
func -(postfix self: Self) -> Self
}

struct SomeStruct : SomeProtocol {
func +(left self: SomeStruct, right: SomeStruct)
func ~(prefix self: Self) -> Self
}

func -(postfix nonSelf: SomeStruct)

end


* What is your evaluation of the proposal?
As it stands, -1

* 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?
No, I find that it is obscure and brings more "magic" into the language.

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

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

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

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

> While I’m a little apprehensive about the implementation

It was simple in the beginning, then two additions were made:
1. Global transitivity checking
2. Precedence relationships that, by transitivity rule, create relationship
between two imported groups, is an error (John McCall)

I don't know how to do any of these checks without nxn connectivity table.
Is that even possible?

> Are they in a separate scope from normal names?
Yes, otherwise Range would be a conflict with standard library structure.

> Can you qualify them with module names?
Right now, I guess, no, although that would be nice to have. I agree that
this can be discussed later.

- Anton

2016-05-24 6:14 GMT+03:00 Jordan Rose :

>
> On May 23, 2016, at 13:10, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> @CoreTeam Please, don't forget to merge pull request with fixes and
> alternatives from review period.
>
> @AnyoneElse Today is (formally) the last day of review. It may be your
> last chance!
>
> Apple repo link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> My repo with some latest changes:
>
> https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
>
> Thanks for doing this. While I’m a little apprehensive about the
> implementation, I don’t expect it to be a problem in practice; a DAG is a
> pretty safe data structure, and the size of the graph (i.e. the number of
> precedence groups in a program) probably won’t be that big in practice. And
> it’s so much better than arbitrary precedence numbers.
>
> To discuss later: what are the naming guidelines for precedence groups?
> (What part of speech? Why UpperCamelCase?) Are they in a separate scope
> from normal names? Can you qualify them with module names?
>
> (Operator declarations in general are weirdly global right now, because
> they need to be resolvable without doing full lookup work, and because it
> was easier to implement them that way. So making precedence groups special
> as well is probably fine, at least for now.)
>
> Jordan
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

@CoreTeam Please, don't forget to merge pull request with fixes and
alternatives from review period.

@AnyoneElse Today is (formally) the last day of review. It may be your last
chance!

Apple repo link:
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

My repo with some latest changes:
https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md

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

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

Sorry, "upper" and "lower" was my mistake that I copy-pasted all over the
place. Just in case, I added those alternate word variants, as well.

- Anton

2016-05-21 16:31 GMT+03:00 Matthew Johnson :

>
>
> Sent from my iPad
>
> On May 21, 2016, at 7:48 AM, Антон Жилин  wrote:
>
> Updated the proposal:
>
> https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> I included many of alternate solutions. Please, reply, if I missed any.
>
> Still I do not hurry to swap any of alternate solution with syntax used
> throughout the proposal, although many of them are objectively better.
>
>
> Looks good.  I really hope we do go with one of the better syntax forms
> though.
>
> The one thing I don't like is "upper" and "lower".  Those don't make sense
> to me in this context.  Any of < and >, above and below, greaterThan and
> lessThan, gt and lt would be better IMO.
>
>
> - Anton
>
> 2016-05-21 1:17 GMT+03:00 Matthew Johnson :
>
>>
>> On May 20, 2016, at 5:06 PM, Brandon Knope  wrote:
>>
>>
>>
>> On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> My working version is still the one in the proposal, but I'm planning to
>> add the alternative versions we discussed, including your and Brent's
>> variants.
>>
>> IMHO, original version is heavy, but clear (not to confuse with "clean").
>> Your lighter version looks more clean, but somewhat less consistent and
>> more free in terms of grammar.
>>
>> Also, I've got another version, which is considerably ligher than current
>> one, while being as structured:
>>
>> precedence Multiplicative {
>> associativity(left)
>> above(Additive)
>> below(Exponentiative)
>> }
>>
>>
>> Why not:
>>
>> precedence Multiplicative {
>> associativity left
>> above Additive
>> below Epxonentiative
>> }
>>
>>
>> Just seeing if removing the parens reduces some of the noise.
>>
>>
>> I would be happy with this.  It is almost the same as what I had
>> suggested, just using > and < rather than above and below (because that was
>> what the proposal was using).  Using words instead is fine with me.  The
>> parens are my biggest objection in this version.  In the original version I
>> also didn’t like the verbosity of `precedencegroup` and the redundant
>> statement `precedence` inside the braces.
>>
>>
>> Sorry if I missed this suggestion earlier and it was denied :P
>>
>> Brandon
>>
>>
>>
>>
>> - Anton
>>
>> 2016-05-21 0:25 GMT+03:00 Matthew Johnson :
>>
>>>
>>> On May 20, 2016, at 4:22 PM, Антон Жилин  wrote:
>>>
>>> Yes, in this case it should be allowed, because this relationship
>>> already existed in imported modules. I will add that, too, thanks!
>>>
>>>
>>> Cool.
>>>
>>> What is the latest syntax you are using?  Did you consider any of the
>>> lighter weight options?  That subthread died without conclusion (unless I
>>> missed something somehow).
>>>
>>>
>>>
>>> - Anton
>>>
>>> 2016-05-21 0:01 GMT+03:00 Matthew Johnson :
>>>
>>>>
>>>> On May 20, 2016, at 3:51 PM, John McCall  wrote:
>>>>
>>>> On May 20, 2016, at 1:25 PM, Антон Жилин 
>>>> wrote:
>>>> Inline:
>>>>
>>>> 2016-05-20 20:58 GMT+03:00 John McCall :
>>>>
>>>>> The transitivity rule plus the ability to define precedence
>>>>> relationships in both directions on a new precedence group allows a new
>>>>> precedence group to create a precedence relationship between existing
>>>>> unrelated precedence groups.  This should be forbidden.
>>>>>
>>>>
>>>> Agreed, although there is an alternate solution to allow global-scope
>>>> relationship definition.
>>>> Trying to write it formally:
>>>>
>>>> begin
>>>> Precedence relationships that, by transitivity rule, create
>>>> relationship between two imported groups, is an error. Example:
>>>>
>>>> // Module X
>>>> precedencegroup A { }
>>>> precedencegroup C { }
>>>>
>>>> // Module Y
>>>> import X
>&

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

Updated the proposal:
https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md

I included many of alternate solutions. Please, reply, if I missed any.

Still I do not hurry to swap any of alternate solution with syntax used
throughout the proposal, although many of them are objectively better.

- Anton

2016-05-21 1:17 GMT+03:00 Matthew Johnson :

>
> On May 20, 2016, at 5:06 PM, Brandon Knope  wrote:
>
>
>
> On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> My working version is still the one in the proposal, but I'm planning to
> add the alternative versions we discussed, including your and Brent's
> variants.
>
> IMHO, original version is heavy, but clear (not to confuse with "clean").
> Your lighter version looks more clean, but somewhat less consistent and
> more free in terms of grammar.
>
> Also, I've got another version, which is considerably ligher than current
> one, while being as structured:
>
> precedence Multiplicative {
> associativity(left)
> above(Additive)
> below(Exponentiative)
> }
>
>
> Why not:
>
> precedence Multiplicative {
> associativity left
> above Additive
> below Epxonentiative
> }
>
>
> Just seeing if removing the parens reduces some of the noise.
>
>
> I would be happy with this.  It is almost the same as what I had
> suggested, just using > and < rather than above and below (because that was
> what the proposal was using).  Using words instead is fine with me.  The
> parens are my biggest objection in this version.  In the original version I
> also didn’t like the verbosity of `precedencegroup` and the redundant
> statement `precedence` inside the braces.
>
>
> Sorry if I missed this suggestion earlier and it was denied :P
>
> Brandon
>
>
>
>
> - Anton
>
> 2016-05-21 0:25 GMT+03:00 Matthew Johnson :
>
>>
>> On May 20, 2016, at 4:22 PM, Антон Жилин  wrote:
>>
>> Yes, in this case it should be allowed, because this relationship already
>> existed in imported modules. I will add that, too, thanks!
>>
>>
>> Cool.
>>
>> What is the latest syntax you are using?  Did you consider any of the
>> lighter weight options?  That subthread died without conclusion (unless I
>> missed something somehow).
>>
>>
>>
>> - Anton
>>
>> 2016-05-21 0:01 GMT+03:00 Matthew Johnson :
>>
>>>
>>> On May 20, 2016, at 3:51 PM, John McCall  wrote:
>>>
>>> On May 20, 2016, at 1:25 PM, Антон Жилин  wrote:
>>> Inline:
>>>
>>> 2016-05-20 20:58 GMT+03:00 John McCall :
>>>
>>>> The transitivity rule plus the ability to define precedence
>>>> relationships in both directions on a new precedence group allows a new
>>>> precedence group to create a precedence relationship between existing
>>>> unrelated precedence groups.  This should be forbidden.
>>>>
>>>
>>> Agreed, although there is an alternate solution to allow global-scope
>>> relationship definition.
>>> Trying to write it formally:
>>>
>>> begin
>>> Precedence relationships that, by transitivity rule, create relationship
>>> between two imported groups, is an error. Example:
>>>
>>> // Module X
>>> precedencegroup A { }
>>> precedencegroup C { }
>>>
>>> // Module Y
>>> import X
>>> precedencegroup B { precedence(> A) precedence(< C) }
>>>
>>> This results in compilation error "B uses transitivity to define
>>> relationship between imported groups A and C".
>>> The rationale behind this is that otherwise one can create relationships
>>> between standard precedence groups that are confusing for the reader.
>>>
>>> end
>>>
>>>
>>> Seems good to me.
>>>
>>>
>>> Would this be allowed if Module X already defined precedence group C > A
>>> (it would not be defining a *new* relationship between A and C in that
>>> case)?
>>>
>>>
>>> What's the purpose of equality relationships between precedence groups?
>>>>
>>>
>>> Agreed, will remove.
>>>
>>>
>>> Ok.
>>>
>>>
>>> Your proposal should call out the special treatment of the Assignment
>>>> and Ternary groups.
>>>>
>>>
>>> Do you mean that most operators should define greater precedence than
>>> Assignment / Ternary? Or there should be some other special treatment?
>>>
>>>
>>> Just that they have implicit members.
>>>
>>> John.
>>>
>>>
>>>
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

My working version is still the one in the proposal, but I'm planning to
add the alternative versions we discussed, including your and Brent's
variants.

IMHO, original version is heavy, but clear (not to confuse with "clean").
Your lighter version looks more clean, but somewhat less consistent and
more free in terms of grammar.

Also, I've got another version, which is considerably ligher than current
one, while being as structured:

precedence Multiplicative {
associativity(left)
above(Additive)
below(Exponentiative)
}

- Anton

2016-05-21 0:25 GMT+03:00 Matthew Johnson :

>
> On May 20, 2016, at 4:22 PM, Антон Жилин  wrote:
>
> Yes, in this case it should be allowed, because this relationship already
> existed in imported modules. I will add that, too, thanks!
>
>
> Cool.
>
> What is the latest syntax you are using?  Did you consider any of the
> lighter weight options?  That subthread died without conclusion (unless I
> missed something somehow).
>
>
>
> - Anton
>
> 2016-05-21 0:01 GMT+03:00 Matthew Johnson :
>
>>
>> On May 20, 2016, at 3:51 PM, John McCall  wrote:
>>
>> On May 20, 2016, at 1:25 PM, Антон Жилин  wrote:
>> Inline:
>>
>> 2016-05-20 20:58 GMT+03:00 John McCall :
>>
>>> The transitivity rule plus the ability to define precedence
>>> relationships in both directions on a new precedence group allows a new
>>> precedence group to create a precedence relationship between existing
>>> unrelated precedence groups.  This should be forbidden.
>>>
>>
>> Agreed, although there is an alternate solution to allow global-scope
>> relationship definition.
>> Trying to write it formally:
>>
>> begin
>> Precedence relationships that, by transitivity rule, create relationship
>> between two imported groups, is an error. Example:
>>
>> // Module X
>> precedencegroup A { }
>> precedencegroup C { }
>>
>> // Module Y
>> import X
>> precedencegroup B { precedence(> A) precedence(< C) }
>>
>> This results in compilation error "B uses transitivity to define
>> relationship between imported groups A and C".
>> The rationale behind this is that otherwise one can create relationships
>> between standard precedence groups that are confusing for the reader.
>>
>> end
>>
>>
>> Seems good to me.
>>
>>
>> Would this be allowed if Module X already defined precedence group C > A
>> (it would not be defining a *new* relationship between A and C in that
>> case)?
>>
>>
>> What's the purpose of equality relationships between precedence groups?
>>>
>>
>> Agreed, will remove.
>>
>>
>> Ok.
>>
>>
>> Your proposal should call out the special treatment of the Assignment and
>>> Ternary groups.
>>>
>>
>> Do you mean that most operators should define greater precedence than
>> Assignment / Ternary? Or there should be some other special treatment?
>>
>>
>> Just that they have implicit members.
>>
>> John.
>>
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

Yes, in this case it should be allowed, because this relationship already
existed in imported modules. I will add that, too, thanks!

- Anton

2016-05-21 0:01 GMT+03:00 Matthew Johnson :

>
> On May 20, 2016, at 3:51 PM, John McCall  wrote:
>
> On May 20, 2016, at 1:25 PM, Антон Жилин  wrote:
> Inline:
>
> 2016-05-20 20:58 GMT+03:00 John McCall :
>
>> The transitivity rule plus the ability to define precedence relationships
>> in both directions on a new precedence group allows a new precedence group
>> to create a precedence relationship between existing unrelated precedence
>> groups.  This should be forbidden.
>>
>
> Agreed, although there is an alternate solution to allow global-scope
> relationship definition.
> Trying to write it formally:
>
> begin
> Precedence relationships that, by transitivity rule, create relationship
> between two imported groups, is an error. Example:
>
> // Module X
> precedencegroup A { }
> precedencegroup C { }
>
> // Module Y
> import X
> precedencegroup B { precedence(> A) precedence(< C) }
>
> This results in compilation error "B uses transitivity to define
> relationship between imported groups A and C".
> The rationale behind this is that otherwise one can create relationships
> between standard precedence groups that are confusing for the reader.
>
> end
>
>
> Seems good to me.
>
>
> Would this be allowed if Module X already defined precedence group C > A
> (it would not be defining a *new* relationship between A and C in that
> case)?
>
>
> What's the purpose of equality relationships between precedence groups?
>>
>
> Agreed, will remove.
>
>
> Ok.
>
>
> Your proposal should call out the special treatment of the Assignment and
>> Ternary groups.
>>
>
> Do you mean that most operators should define greater precedence than
> Assignment / Ternary? Or there should be some other special treatment?
>
>
> Just that they have implicit members.
>
> John.
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

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

Inline:

2016-05-20 20:58 GMT+03:00 John McCall :

> The transitivity rule plus the ability to define precedence relationships
> in both directions on a new precedence group allows a new precedence group
> to create a precedence relationship between existing unrelated precedence
> groups.  This should be forbidden.
>

Agreed, although there is an alternate solution to allow global-scope
relationship definition.
Trying to write it formally:

begin
Precedence relationships that, by transitivity rule, create relationship
between two imported groups, is an error. Example:

// Module X
precedencegroup A { }
precedencegroup C { }

// Module Y
import X
precedencegroup B { precedence(> A) precedence(< C) }

This results in compilation error "B uses transitivity to define
relationship between imported groups A and C".
The rationale behind this is that otherwise one can create relationships
between standard precedence groups that are confusing for the reader.
end

What's the purpose of equality relationships between precedence groups?
>

Agreed, will remove.


> Your proposal should call out the special treatment of the Assignment and
> Ternary groups.
>

Do you mean that most operators should define greater precedence than
Assignment / Ternary? Or there should be some other special treatment?

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0077: Improved operator declarations

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

OK, question 2 closed, we do need unlimited relationships.
Some critique to Brent's options:
1. No separators, with multiple relations it becomes unobvious, which
comparison corresponds to which group
2. `left` appears suddenly, it may not be clear that it is associativity
3. Where is declaration of the precedence group? It looks like two
relationship declarations, but in Swift, all entities tend to be
pre-declared
4. Remove @, otherwise not that bad
5. Actually, that was the very first version of the proposal. Over time, it
morphed to version in alternative solutions:

precedencegroup B : associativity(left)
precedencerelation B > A
precedencerelation B < C

The specific syntax is discussable:

precedencegroup associativity(left) B
precedence B > A
precedence B < C

We could also stretch inheritance-like syntax:

precedence B : associativity(left), above(A), below(C)

That is my current favourite among one-liners, if we don't want separate
relationship declaration.


On Matthew's version: I like that it is lightweight, but I don't like that
`left` is a "sudden" word again, and that relationships turn into a mess
when written on a single line.

- Anton

2016-05-19 23:36 GMT+03:00 Brent Royal-Gordon :

> > I managed to confuse at least two people! I've stated it in the grammar,
> but forgot to give an example:
> >
> > ===begin===
> > Multiple precedence relationships can be stated for a single precedence
> group. Example:
> > ```swift
> > precedencegroup A { }
> > precedencegroup C { }
> > precedencegroup B { precedence(> A) precedence(< C) }
> > ```
> > By transitivity, precedence of C becomes greater than precedence of A.
> > ===end===
> >
> > As you can see, your suggested syntax would not look good, because there
> can be any number of precedence declarations.
>
> Ah, I see.
>
> > 2. Limit precedence relationships.
> >
> > Do we really need a full-blown Directed Acyclic Graph?
> > Could `above` and `between` be enough?
> >
> > Example:
> >
> > precedencegroup B : between(A, C)
> >
> > This is one of dark places of the proposal, obviously underdiscussed.
> > Are there practical situations other than `above` and `between`?
> > Do we really need unlimited relationships per one precedencegroup?
>
> We probably do if you're serious about having operators whose precedence
> relative to each other is undefined. Moreover, you actually have to be
> prepared for *more than* two relationships, or two relationships which are
> both on the same "side", so "between" doesn't cut the mustard.
>
> I can see three ways to fit multiple relationships on one line:
>
> 1.  precedence Multiplicative > Additive < BitwiseShift left
> 2.  precedence Multiplicative > Additive, < BitwiseShift left
> 3.  precedence Multiplicative > Additive, Multiplicative <
> BitwiseShift left
>
> Another option would be to have `precedence` lines declare-or-redeclare
> *all* of the precedence levels in them, not just the one on the left of the
> operator. Then you would write something like:
>
> 4.  precedence @associativity(left) Multiplicative > Additive
> precedence Multiplicative < BitwiseShift
>
> It would be an error to have two `precedence` lines which marked the same
> precedence level with a different `@associativity`. Of course, we could
> instead put associativity on its own line, perhaps allowing multiple
> declarations for compactness:
>
> 5.  precedence Multiplicative > Additive
> precedence Multiplicative < BitwiseShift
> associativity left Cast, Comparative, Multiplicative, Additive
>
> I think 5 is my preference, but if we want a single-line syntax, I'd
> probably favor 2.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [swift-evolution-announce] [Review] SE-0077: Improved operator declarations

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

Thanks Brent,

I managed to confuse at least two people! I've stated it in the grammar,
but forgot to give an example:

===begin===
Multiple precedence relationships can be stated for a single precedence
group. Example:
```swift
precedencegroup A { }
precedencegroup C { }
precedencegroup B { precedence(> A) precedence(< C) }
```
By transitivity, precedence of C becomes greater than precedence of A.
===end===

As you can see, your suggested syntax would not look good, because there
can be any number of precedence declarations.

But I agree that bulkiness of my syntax is a problem.
I can think of two solutions:

1. Global-scope precedence relationships. Example:

precedencegroup B : associativity(left)
precedencerelation B > A
precedencerelation B < C
infix operator <$> : B

It's already included as an alternate solution.

2. Limit precedence relationships.

Do we really need a full-blown Directed Acyclic Graph?
Could `above` and `between` be enough?

Example:

precedencegroup B : between(A, C)

This is one of dark places of the proposal, obviously underdiscussed.
Are there practical situations other than `above` and `between`?
Do we really need unlimited relationships per one precedencegroup?

- Anton

Brent Royal-Gordon wrote:

> I like this proposal, except for the `precedencegroup` syntax, which I
> think is a bit overwrought. Rather than this proposal's:
> precedencegroup Multiplicative {
> associativity(left)
> precedence(> Additive)
> }
> I would prefer to see:
> precedence Multiplicative > Additive left
> (Or possibly, if the `left` is deemed too inexplicable by itself,
> `associativity(left)`.) I don't really think the `precedence` keyword or
> the curly brackets bring much to the declaration, and dropping them allows
> us to replace the awkward compound `precedencegroup` with the shorter and
> equally explanatory `precedence`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0077: Improved operator declarations

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

Jeremy, inline:

By the way, in the future directions version of the BitwiseShift group we
> have
>  members(<<, >>)
> Is that a typo?


Thanks, will try to fix it.

Also, just to confirm that my understanding of how this will work is
> correct, the proposal seems to suggest that future directions definitions
> of the bitwise operators will forbid combining bitwise operators in
> expressions with arithmetic operators e.g.
>  a << b + c
> will be illegal because there is no relationship defined between the
> additive group and the bitwise groups (when it comes up for review, I will
> definitely be opposed to that, but it doesn’t affect  my assessment of this
> proposal).


Right, and another discussion will follow.


Leonardo:

Just forgive me if I didn't see this but I expect that I
> cannot declare an operator belonging to more than one group or compare
> to more than one group for precedence (thou I see some situations
> being able to asset precedence against more than one group could be
> useful).


Currently, any operator can belong to only one precedence group.
But one precedence group can contain multiple precedence() comparisons.

It follows from the grammar, but is not mentioned anywhere else.
That was my oversight. I'll try to add it.

By the way, I had asked if some simpler set of tools would suffice, e.g.
parent() instead of precedence().
It seemed that people preferred to have full power of directed graph at
their disposal.
For example, we can insert a precedence group between Additive and
Multiplicative:

precedencegroup Between {
precedence(> Additive)
precedence(< Multiplicative)
}

And by the way, if Additive and Multiplicative were not connected, this
Between would connect them by transitivity.

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

[swift-evolution] [Review] SE-0077: Improved operator declarations

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

I underline that I very much rely on the Core team to pick the "right"
version of syntax.
The only opinion I have is that `greaterThan` and `above` are probably
better than `>`.

- Anton

Trent Nadeau wrote:

> Although I would prefer something like:
> precedence(greaterThan: LogicalAnd)
> to:
> precedence(> LogicalAnd)
> I think the latter is more difficult to read, and I just find the idea of
> using an operator in an operator/precendencegroup definition strange.


Xiaodi Wu wrote:

> * `precedencegroup` defines both associativity and precedence, so the
> naming isn't great. Maybe `operatorgroup`?
> * I'm not sure about the parentheses used between the braces. To me, it
> would fit better with the language to use colons.
> * It may be confusing that relative precedence levels are themselves
> described using operators or words that describe operators. I'd suggest
> simpler words that aren't self-referential, such as "above" and "below".
> So to put it all together, here's the color of my bikeshed:
> ```
> operatorgroup Comparative {
>   associativity: left,
>   precedence: above(LogicalAnd)
> }
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [swift-evolution-announce] [Review] SE-0087: Rename lazy to @lazy

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

>
> > Swift's rule for attribues/keywords is that keywords usually modify type
> of variable; attributes do not.
> [citation needed]
> As far as I can tell, this is not true at all. Most declaration modifiers
> do *not* change the type of anything; as far as I can tell, only
> `mutating`, `nonmutating`, and possibly `optional` do. Meanwhile, several
> attributes—particularly `@noescape` and `@autoclosure`—*do* change the
> type. So where is this belief coming from?


When I wrote "modify type", I did not mean distinction between declaration
and type modifiers.

For example, if  @autoclosure  was used as  @autoclosure Int , then I'd say
that it "changes" its base type.
On the other hand, I'd say that  @autoclosure () -> Int  "keeps" its base
type.

In the same sense, `lazy` does not have any visible changes on type of its
property.
On the other hand, `weak` effectively changes property type from T to T?
`unowned` effectively changes T to T!

The main driver was actually property behaviours proposal, and I think the
discussion stopped at attribute syntax being most appropriate.
If that changes later, and property behaviours is accepted, we will have to
move @lazy, along with @NSCopying and others, to the new syntax.

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

[swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

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

> * What is your evaluation of the proposal?

-1

I prefer "newlines as commas" to the solution being suggested, but see
below.

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

Probably, not. I haven't ever had a case where I lost something without
this feature.

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

No. A recent proposal standardized function call grammar. I wouldn't want
to grow it or add optional special cases.

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

I've seen people use trailing commas for arrays, but never use it myself
even with arrays.

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

Just following the thread.

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

[swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

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

Following my current cpp guidelines, I would suggest the following:

1. Make all letters of the abbreviation downcase
2. Make first letter uppercase if required

Examples: NanWrapper, getNan, nanGet, NextEmulator, emulateNext,
nextEmulate.

Although, this convention plays pretty hard on NeXT, I have to admit.

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

Re: [swift-evolution] [Idea] Make lazy an attribute

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

I'm ready to submit a pull request:

https://github.com/Anton3/swift-evolution/blob/lazy-attribute/proposals/-lazy-attribute.md

- Anton

2016-05-03 0:25 GMT+03:00 David Sweeris :

> Yeah, I was just thinking that we should get the “call-site” syntax
> settled for property behaviors, for exactly that reason.
>
> > On May 2, 2016, at 3:39 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > One of proposals that will probably be submitted for Swift 4, will be
> Property Behaviors propoal.
> >
> > It aims to generalize @IBOutlet, @synchronized, @delayedinit, and of
> course, @lazy.
> > (Side note: it would be great if it also included unowned)
> >
> > Because we aim for less breaking changes in Swift 4, we should prepare
> ground for it.
> > The suggestion is to rename `lazy` to `@lazy`.
> >
> > Besides the aforementioned reason, I think, lazy really has its place
> among attributes.
> > It does not change type of property, it just helps to delay side effects
> of initialization.
> >
> > - Anton
> > ___
> > 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] [Idea] Make lazy an attribute

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

One of proposals that will probably be submitted for Swift 4, will be
Property Behaviors propoal.

It aims to generalize @IBOutlet, @synchronized, @delayedinit, and of
course, @lazy.
(Side note: it would be great if it also included unowned)

Because we aim for less breaking changes in Swift 4, we should prepare
ground for it.
The suggestion is to rename `lazy` to `@lazy`.

Besides the aforementioned reason, I think, lazy really has its place among
attributes.
It does not change type of property, it just helps to delay side effects of
initialization.

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

Re: [swift-evolution] [Idea] Remove optional pattern binding

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

I absolutely agree with John, and I think, we should push this through
evolution process.

That old voting wasn't public, or "official".
I insist that we decide this via a formal review. Even if it means that the
proposal will be explicitly rejected.

- Anton

2016-05-02 22:07 GMT+03:00 John McCall :

> > On May 2, 2016, at 11:47 AM, Chris Lattner  wrote:
> > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>  On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
> > Pattern binding for optionals will look like:
> >
> > if let x? = y { ... }
> 
>  I suggested precisely this in February. The core team shot it down:
> 
> > We tried this* and got a lot of negative feedback. Optionals are
> unwrapped too often for people to be comfortable writing "if let name? =
> optionalCondition".
> 
> 
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008964.html
> 
>  Having said that, this still seems like a good idea to me, but
> they're the ones with implementation experience; all I have is an elegant
> idea.
> >>>
> >>> Yeah, as nice as it sounds, it didn’t work out in practice. I’ll add
> it to the frequently-suggested list.
> >>
> >> Yeah.  My take on it is that 'if let' was probably a mistake, but once
> we made it, it was really hard to back out.
> >
> > I understand that you (and probably a ton of other people on this list)
> feel that way, but I disagree pretty strongly.  I think we have the right
> design here.
> >
> > Context: As was mentioned up-thread, in the Swift 2 development cycle,
> we significantly extended pattern matching (this is when we added ‘if
> case’, etc).  One of the things we implemented - but then backed out - was
> exactly the proposal above. We did this because we found it to be the
> *wrong* thing to do.
> >
> > The reason is simple: most developers don’t grok pattern matching.
> Particularly for people new to swift, “if let” is taught as a magic for
> dealing with optionals (which it is). This is a very useful mechanic when
> working in Swift, and this way of thinking is fine.  Optionals are very
> prominent, and having special sugar for dealing with them is important,
> even as people grow to become swift experts in time.
> >
> > Going with the proposal would definitely simplify the language ('if
> case’ could probably go away), but would force everyone, all the time, to
> think about pattern matching.  This would be a barrier to entry that many
> programmers should never have to face.  The fact that many people don’t
> think about things in terms of pattern matching is the root cause for the
> comments about “it seems weird that the question mark is on the LHS of the
> assignment”.
> >
> > Finally, some may argue that making pattern matching more prominent
> would help teach pattern matching and get more people to use it.  That may
> be true, but our goal here is to build a pragmatic language that helps
> people get things done, not push to one specific language feature.  I
> personally love pattern matching (and was the one who drove and implemented
> the Swift 2 pattern matching enhancements), but it is an esoteric and
> special case feature.  It makes sense for it to be “buried” under “if
> case”: those who are unfamiliar with the syntax have something they can
> google for.
>
> I understand what you're saying here, but I don't think your conclusions
> follow.  You wouldn't teach "if let x? = whatever" as an aspect of a
> generic pattern-matching feature just because "x?" happens to be a
> pattern.  You would still introduce it as magic for dealing with optionals,
> and the syntax would nicely reinforce a general impression that "? is how I
> deal with optionals".  Instead, it feels more magical because nothing about
> the syntax suggests optionals; it's just something you have to know.
>
> Meanwhile the "if let" syntax has proven to compose poorly, and in
> particular it makes compound conditions unnecessarily limited/awkward
> because you can't bind a non-optional value and then test something about
> it without doing something like "if let x = Optional(whatever) where
> x.isBeautiful".
>
> Anyway, like I said, I don't think it's something we can change.
>
> John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Remove optional pattern binding

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

Currently,

if case let x? = y { ... }

is a sugared version of:

if case let .some(x) = y { ... }

which is in turn a sugared version of:

if case .some(let x) = y { ... }

Pattern matching in `if` works like this: left hand side of `=` contains
supposed structure of value at right hand side.
If we omit `case`, we get:

if let x? = y { ... }

Another example: checks if tuple contains two `.some`:

if let (x?, y?) = z { ... }

- Anton

2016-05-02 13:25 GMT+03:00 Haravikk :

>
> On 1 May 2016, at 09:12, Антон Жилин  wrote:
>
> Pattern binding for optionals will look like:
>
> if let x? = y { … }
>
>
> Would take a little getting used to, but I think I’d be fine with it, as
> the way things are now is inconsistent with regular assignments (which
> remain optional).
>
> My only concern is why the question mark on the left hand side? I don’t
> really have any concrete reason against it, but it just feels kind of odd
> to me, I’m just hoping for some reasoning why some of the alternatives
> aren’t better fits like:
>
> if let x = y? { … } // More like optional chaining, which is familiar as
> an “if non-nil proceed” behaviour
> if let x ?= y { … } // More obviously a special type of assignment that
> could fail if y is nil
>
> Again, I’m in favour, I’m just curious why the mentioned format, were
> others considered previously, or is just because that’s how the
> case-keyword form does it? (I don’t use it as I’ve never liked that form,
> and it doesn’t seem that well known anyway).
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

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

Then why not rename stride(from:to:by:) to range(from:to:by:) ?
I think, range is closer to what people coming from other languages expect
to see.

- Anton

> With the renaming proposed above, stride(of:) will appear to be related
> to stride(from:to:by:). This conflict arises from a pre-existing issue;
> namely, the term "stride" is used to mean two different things. Although
> moving the preposition only highlights the issue, one possible resolution
> is to rename strideof(_:) to strideSize(of:) and strideofValue(_:)
> tostrideSize(ofValue:).
> I wonder if it might make sense to rename all of these, then?
> instanceSize(of:)
> instanceSize(ofValue:)
> alignmentSize(of:)
> alignmentSize(ofValue:)
> strideSize(of:)
> strideSize(ofValue:)
> --
> Brent Royal-Gordon
> Architechies
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Idea] Remove optional pattern binding

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

Generally, pattern binding in `if` looks like this:

if case *pattern* = *expression* { ... }

Pattern binding for optionals is currently usable as both of:

if case let .some(x) = y { ... }
if case let x? = y { ... }

Now, there is also an older optional-specific hack:

if let x = y { ... }

In terms of pattern binding, it should always be true, and it's illogical
inside `if`.

I suggest:
1) Remove optional pattern binding
2) Remove `case` in `if` pattern binding

Really, `case` should be an attribute of `switch`, not `if`.

Pattern binding for optionals will look like:

if let x? = y { ... }

It will become more explicit and consistent with the rest of the language.

We need to hurry until Swift 3 lands!

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

[swift-evolution] [Pitch] Richer function identifiers, simpler function types

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

Could you please publish it on Github? It is a bit difficult to read such
long posts in mailing lists.

1) I wouldn't like if ability to get function by name was removed.
Granted, it doesn't always work, but when it does, it's nice and concise.

2) SE-0066 and removal of tuple splat behaviour are caused by the fact that
Swift function argument lists are not tuples.
Inout, @noescape and others make sense only in function types.

Example:
(Int, Int) -> Int  will be a function that takes two Ints
((Int, Int)) -> Int  will be a function that takes one tuple
(((Int, Int))) -> Int  will be the same as ((Int, Int)) -> Int

3) Methods will be uncurried when used as closures.
Example:
[Int].map as ([Int], @noescape (Int) -> Int) -> [Int]

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

Re: [swift-evolution] Disambiguate Return Type With Void

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

Agreed. That would only allow to disambiguate call with unused result, but
would not solve this problem. Jordan pointed at it.
It would be consistent therefore to leave @discardableResult functions with
usual non-Void functions.

- Anton

2016-04-27 12:01 GMT+03:00 Andrew Bennett :

> I'm happy to add `@unusedResult`, with a little more discussion. I'm not
> sure when it would actually be used though.
>
> I'm not sure if you can define both of these functions:
>
>@unusedResult func example() -> Int
>func example() -> Int
>
> Either way, a method with @unusedResult should probably have a different
> name to one without.
>
> You can define both of these functions:
>
>@unusedResult func example() -> Int
>func example() -> String
>
> However, if the methods return different non-void values they should
> probably have different names.
>
>
> On Tue, Apr 26, 2016 at 11:57 PM, Антон Жилин 
> wrote:
>
>> +1
>>
>> > Also, technically we can assign a value to Void function
>> This proposal will not disallow that. Just non-Void functions will be
>> preferred when result is used.
>>
>> array.sort(..) // mutating
>> let array2 = array.sort(..) // non-mutating, instead of array.sorted()
>>
>> I think, that's actually the best solution to mutating / non-mutating 
>> convention!
>>
>> Andrew, why not generalize this proposal to functions with @unusedResult?
>>
>> In terms of "precedence" when result is used:
>> Non-Void > @unusedResult > Void (+warning)
>>
>> When unused:
>> Void > @unusedResult > Non-Void (+warning)
>>
>> - Anton
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Mixins

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

Yes, this is my proposal, and of course, I'm interested :)

I haven't read into the mentioned papers, but symmetric sum, asymmetric
sum, alias, exclusion and derived operations form a solid basis for
conflict resolution.
Mixins don't have all that tools and try to solve conflicts by being less
strict at composition.
I agree that Swift, as a compiled language, would benefit from the former
more.

In traits, I like how requirements and definitions are separated using
requirement of protocol conformance.
It follows Uniform Access Principle: noone can require conformance to a
trait.
Are there other benefits?

I believe there are situations where non-privateness of fields would help,
see my two examples.
This can be overridden by adding a "proxy" computed property. But why is
privateness needed?

Do traits have initializers? How do they work in diamond pattern?

Example: A -> (B, C) -> D
B.init calls A.super.init(1)
C.init calls A.super.init(2)
D.init calls B.super.init() and C.super.init()

Traits are flattened by default. Does it mean that A will be initialized
twice? in what state will A be?

- Anton

2016-04-27 2:50 GMT+03:00 Niall Young :

> On Fri, 22 Apr 2016, Антон Жилин wrote:
>
> This feature has been previously discussed. Search for Mixins on
>> swift-evolution archives.
>>
>> I believe it would help to read previous version of the proposal:
>> https://github.com/Anton3/swift-evolution/blob/mixins/proposals/-mixins.md
>>
>
> Cheers, already read through the thread - I'm more focused on implementing
> Traits, which I think is very similar but slightly different to what's been
> described in the thread to date.
>
> Is this your proposal?  I'd love to give you some feedback, throw ideas
> back and forth if you're interested?  If we can evolve the concept and
> implementation by Swift 4 that gives me enough time to brush up on C++ and
> start delving into Swift internals to see how best it could be done.
>
> Cheers,
>
> --
> Niall Young
> ni...@iinet.net.au
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Disambiguate Return Type With Void

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

Let's expand on that situation. Dictionary would have these methods:

@discardableResult func removeValue(forKey key: Key) -> Value?
func removeValue(forKey key: Key) -> Self

I would argue that these two versions are not semantically identical: (1)
returns removed value while (2) does not.
Therefore they should have different names. In this case, we can rename
them like this:

@discardableResult func removeValue(forKey key: Key) -> Value?
func remove(key key: Key) -> Self

Or like this:

func removeValue(forKey key: Key) -> Value?
func remove(key key: Key) -> Void
func remove(key key: Key) -> Self

- Anton

2016-04-26 19:26 GMT+03:00 Jordan Rose :

>
> On Apr 26, 2016, at 06:57, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1
>
> > Also, technically we can assign a value to Void function
> This proposal will not disallow that. Just non-Void functions will be
> preferred when result is used.
>
> array.sort(..) // mutating
> let array2 = array.sort(..) // non-mutating, instead of array.sorted()
>
> I think, that's actually the best solution to mutating / non-mutating 
> convention!
>
> There are mutating methods that have return values, like
> Dictionary.removeValue(forKey:). Admittedly there’s no non-mutating version
> of that at the moment, but that doesn’t mean there couldn’t be.
>
> Jordan
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Disambiguate Return Type With Void

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

+1

> Also, technically we can assign a value to Void function
This proposal will not disallow that. Just non-Void functions will be
preferred when result is used.

array.sort(..) // mutating
let array2 = array.sort(..) // non-mutating, instead of array.sorted()

I think, that's actually the best solution to mutating / non-mutating
convention!

Andrew, why not generalize this proposal to functions with @unusedResult?

In terms of "precedence" when result is used:
Non-Void > @unusedResult > Void (+warning)

When unused:
Void > @unusedResult > Non-Void (+warning)

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

[swift-evolution] [Idea] Repurpose Void

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

SE-0066 disallows Void to be used on left side of function types.

Some people, including me, argue that Void should be removed altogether,
because:
1) () is more consistent with curried functions: (Int) -> () -> Double
2) () follows functional programming traditions

Now, why don't we repurpose Void to follow functional programming
traditions as well?
Its definition will look like:
enum Void { }

Basically, Void is a type which cannot have values.
With it, we can eliminate at least two Swift special cases:

1. Noreturn functions

func exit(code: Int = 0) -> Void

>From this signature, it's obvious that `exit` cannot return normally

2. Rethrows

func call(block: () throws T -> U) throws T -> U

Non-throwing functions are functions throwing Void.
So if T=Void, we get the non-throwing version of `call`.

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

[swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

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

>
> Therefore the impermissible:
> (()) -> () Is identical to:
> (Void) -> () So to follow these rules, it must instead be:
> Void -> () … and we’re back to T1 -> T2 :* )*


Wrong! If we enforce parentheses in function types, we won't be able to write

Void -> ()

Parentheses will be required on the grammar level. The correct way to
write this will be:

() -> ()  or  () -> Void

The following will be legal:

(Void) -> ()  and  (()) -> ()

It is a function that takes a single parameter () and returns ().

I additionally propose that the following should be illegal, because
additional parentheses aren't needed there:

((())) -> ()  and  () -> (())  and just (Int) and (())

Hope it cleared up things a little bit.

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

[swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

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

We can disallow putting types in parentheses in single-element tuple
meaning.
For example, (Int) -> (Double) will be illegal because of (Double).
(Int) -> (Double) -> Bool will be legal, because parentheses mean function
type here.
(Int) -> () will be legal, because () means Void here.
This can be theme of a separate proposal.

- Anton

On 22.04.16, Vladimir.S wrote:

What I really don't like is that we can have all this:
func f1() -> (Void) {..}
func f2(Void) -> ((Void)) {..}
func f3() ->  {..}
func f4(((Void))) -> (Void) {..}
func f5() -> ((Void)) {..}
func f6((())) ->  {..}
and all is equivalent for
func f() -> () {..}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

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

Vladimir, I agree with Chris Lattner that function parameters are different
from function return value in Swift.

Firstly, syntax of function call allows for easy forwarding of values,
which came from different places, as parameters to a single function:
f(g(foo, 1), h(bar(buz)))

On the other hand, to play with multiple return values as freely, you need
to perform pattern matching, which finishes current expression.

Secondly, there is no special sugar for tuples in return values, and
function grammar does not need to know about it.

Thirdly, there are no special attributes for elements of tuple in function
return type (second implies this).

Now, to  typealias f4 = () -> ((()))
I think it's OK, but we can remove Void and reduce the number of possible
combinations.

The fact that () and (()) are equal types is a general limitation of Swift
type system: there are no single-element tuples.
But it is so for a reason: parentheses in expressions cannot be overloaded
to construct single-element tuples.

- Anton

2016-04-22 11:12 GMT+03:00 Антон Жилин :

> +1, but this proposal need further work.
> Specification of the new function grammar is needed.
>
> Currently, it looks like:
>
> function-type → type
> 
> ­throws­opt­->­type
> 
>
> It is already false, because some attributes can only be used in function
> types.
>
> I suggest to rewrite it to something like:
>
> *function-type* → ( *function-parameter-types*opt ) -> *type*
>
> *function-type* → ( *function-parameter-types*opt ) throws -> *type*
>
> *function-type* → ( *function-parameter-types*opt ) rethrows -> *type*
>
> *function-parameter-types* → *function-parameter-type*
>
> *function-parameter-types* → *function-parameter-type* ,
> *function-parameter-types*
>
> *function-parameter-type* → *function-parameter-attributes* *type*
> It will also eliminate situation when you can pass () argument to a () → T
> function.
> Function types Void->T will need to be migrated.
>
> - Anton
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

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

+1, but this proposal need further work.
Specification of the new function grammar is needed.

Currently, it looks like:

function-type → type

­throws­opt­->­type


It is already false, because some attributes can only be used in function
types.

I suggest to rewrite it to something like:

*function-type* → ( *function-parameter-types*opt ) -> *type*

*function-type* → ( *function-parameter-types*opt ) throws -> *type*

*function-type* → ( *function-parameter-types*opt ) rethrows -> *type*

*function-parameter-types* → *function-parameter-type*

*function-parameter-types* → *function-parameter-type* ,
*function-parameter-types*

*function-parameter-type* → *function-parameter-attributes* *type*
It will also eliminate situation when you can pass () argument to a () → T
function.
Function types Void->T will need to be migrated.

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

Re: [swift-evolution] [Draft] Mixins

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

Sorry, it has been delayed *from* Swift 3 to future versions.

2016-04-22 10:22 GMT+03:00 Антон Жилин :

> Hi Niall,
>
> This feature has been previously discussed. Search for Mixins on
> swift-evolution archives.
>
> I believe it would help to read previous version of the proposal:
>
> https://github.com/Anton3/swift-evolution/blob/mixins/proposals/-mixins.md
>
> This feature has been delayed to Swift 3 by Chris Lattner (at least, he
> told about it).
>
> - Anton
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Draft] Mixins

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

Hi Niall,

This feature has been previously discussed. Search for Mixins on
swift-evolution archives.

I believe it would help to read previous version of the proposal:
https://github.com/Anton3/swift-evolution/blob/mixins/proposals/-mixins.md

This feature has been delayed to Swift 3 by Chris Lattner (at least, he
told about it).

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

Re: [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3

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

What bothers me is that it won't be possible to opt into conversions during
imports.
I've created a proposal, which solves all related importing problems:

https://github.com/Anton3/swift-evolution/blob/shadowing-imported-functions/proposals/-shadowing-imported-functions.md

It passed largely unnoticed, as usual (I'm unlucky), although shadowing
import proposal was requested in a Core team discussion report.
Thank you for paying time!

Overall, +1 to the proposal being discussed. I think that all types should
be imported exactly as written in C/Objective-C, and functions should be
imported using exactly that "foreighn" types.

It's the right time to review importing rules of numerics.
NSInteger should be imported as NSInteger, not as Int.
`size_t` should be imported as UInt, not as Int.
These conversions simplify things, but sometimes the difference matters.

- thank you for paying time, Anton
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Custom operators

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

Sorry for the delay, please mail me a copy next time :)

Inline:

Антон Жилин:
> > No new suggestions have come in 2 days, and so I have created a pull
> request!
> > https://github.com/apple/swift-evolution/pull/253
> 1. Assignment operators in Swift 2.2 have an `assignment` keyword:
> infix operator += {
>   associativity right
>   precedence 90
>   assignment
> }
>

Right, it was planned to be removed anyway, and so I did not include it in
the new syntax on purpose. Added removal of `assignment` to "details".

2. If assignments can't be chained, should they be non-associative?
>

Agreed, these operators are actually non-associative right now. Fixed that,
thanks!


> 3. Instead of `precedencegroup`, I suggest an abstract declaration:
> operator Multiplicative {
>   associativity(left)
>   precedence(> Additive)
> }
> infix operator * : Multiplicative
>

Basically, change `precedencegroup` to `operator`?
In terms of keywords, operator will be only a local keyword in my proposal,
so I can say that each variant reserves one keyword.

In terms of name itself, I think, `precedencegroup` is more to the point.
Precedence groups are already mentioned in the standard.
On the other hand, I agree that we should not introduce new entities when
possible.
Overall, I'm inclined to leave currently proposed syntax.


> 4. In your proposal, `NilCoalesting` should be `NilCoalescing`.
> -- Ben


Fixed.

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

Re: [swift-evolution] [SR-933] Rename flatten to flattened

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

After hitting Send button, I remembered that "Enhanced floating-point
protocols" proposal uses `add`, `subtract`, `multiply` and `divide` names
for mutating versions.
They should be non-mutating by default, as well as other purely
mathematical terms. I don't know how it can be unobvious.

- Anton

2016-04-15 23:36 GMT+03:00 Антон Жилин :

> Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad.
> It's more a matter of what should be "default" in a specific domain.
>
> In imperative domain, mutating version usually feels as the most natural
> one.
> Think `sort`. Everyone knows that sort must modify the array (usually
> through a sequence of swaps) to be most efficient. (Heapsort is an
> exception there, I guess.)
> That's why it is mutating version should be the shorter one, and
> non-mutating should have a prefix or a suffix.
>
> In functional domain, non-mutating version usually feels as the most
> natural one.
> Think `filter`, `map`, `reduce`. This functions originated in functional
> languages. Functional languages usually have immutability by default.
> When we "map" these idioms to Swift, we should let non-mutating version be
> the "default" one.
> Of course, we can be strict with our own rules and inventive in terms of
> function names, but we just shouldn't.
>
> Think `union`, `intersection`. These terms originated from mathematics,
> where mutability just doesn't exist.
> Given such a domain area, it should be obvious that `union` on a set means
> non-mutating version, unless stated otherwise.
>
> So, I conclude that we should not enforce any guideline about naming
> mutating/non-mutating versions of methods.
> Correct me if this is a wrong conclusion.
>
> - Anton
>
> 2016-04-15 19:31 GMT+03:00 Erica Sadun :
>
>>
>> On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I've already expressed these concerns, but nobody noticed, apparently.
>> Here is it:
>>
>> I think current -ed/-ing convention is ugly. It breaks syntactic
>> correctness, experience from other languages, mathematical notation and
>> functional idioms.
>>
>> `InPlace` suffix was so far more correct in these terms. We can make
>> anything a convention, but should we?
>> I liked the proposal about new naming conventions, but overlooked this
>> change.
>>
>> Many people will agree with me. This still can be reviewed until Swift 3.
>> If so, I will create a proposal to correct "the big three" in this.
>>
>> What do you think?
>>
>>
>> I would like to see a formal proposal along these lines. My other
>> suggestions are here
>> <http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/>
>> .
>>
>> -- E
>>
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SR-933] Rename flatten to flattened

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

Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad.
It's more a matter of what should be "default" in a specific domain.

In imperative domain, mutating version usually feels as the most natural
one.
Think `sort`. Everyone knows that sort must modify the array (usually
through a sequence of swaps) to be most efficient. (Heapsort is an
exception there, I guess.)
That's why it is mutating version should be the shorter one, and
non-mutating should have a prefix or a suffix.

In functional domain, non-mutating version usually feels as the most
natural one.
Think `filter`, `map`, `reduce`. This functions originated in functional
languages. Functional languages usually have immutability by default.
When we "map" these idioms to Swift, we should let non-mutating version be
the "default" one.
Of course, we can be strict with our own rules and inventive in terms of
function names, but we just shouldn't.

Think `union`, `intersection`. These terms originated from mathematics,
where mutability just doesn't exist.
Given such a domain area, it should be obvious that `union` on a set means
non-mutating version, unless stated otherwise.

So, I conclude that we should not enforce any guideline about naming
mutating/non-mutating versions of methods.
Correct me if this is a wrong conclusion.

- Anton

2016-04-15 19:31 GMT+03:00 Erica Sadun :

>
> On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I've already expressed these concerns, but nobody noticed, apparently.
> Here is it:
>
> I think current -ed/-ing convention is ugly. It breaks syntactic
> correctness, experience from other languages, mathematical notation and
> functional idioms.
>
> `InPlace` suffix was so far more correct in these terms. We can make
> anything a convention, but should we?
> I liked the proposal about new naming conventions, but overlooked this
> change.
>
> Many people will agree with me. This still can be reviewed until Swift 3.
> If so, I will create a proposal to correct "the big three" in this.
>
> What do you think?
>
>
> I would like to see a formal proposal along these lines. My other
> suggestions are here
> <http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/>
> .
>
> -- E
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [SR-933] Rename flatten to flattened

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

I've already expressed these concerns, but nobody noticed, apparently. Here
is it:

I think current -ed/-ing convention is ugly. It breaks syntactic
correctness, experience from other languages, mathematical notation and
functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make
anything a convention, but should we?
I liked the proposal about new naming conventions, but overlooked this
change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?

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

Re: [swift-evolution] [Proposal] Shadowing imported functions

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

Yes, re-labelling is allowed, as well as reordering. I will add that to the
proposal.

2016-04-15 5:01 GMT+03:00 Dany St-Amant :

>
> Le 14 avr. 2016 à 11:28, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> As promised, I've created a proposal to add @shadowing attribute. Link to
> the proposal:
>
>
> https://github.com/Anton3/swift-evolution/blob/shadowing-imported-functions/proposals/-shadowing-imported-functions.md
>
> Example:
>
> // Imported function (implicit declaration)func dispatch_sync(queue: 
> dispatch_queue_t, block: (@convention(block) () -> Void)!)
> @shadowing(dispatch_sync(queue, block))func sync(queue: dispatch_queue_t, 
> @noescape block: @convention(block) () -> Void)
>
>
>
> It is unclear to me, if you plan to allow re-labelling, during the
> shadowing process.
>
> Could the:
>  dispatch_sync(_,block:)
> Be shadowed as either (if one disregard the API Guideline)
>  sync(_,block:)
>  sync(list:,task:)
>  sync(_,_)
>
> If the import got the function name wrong, and missed the annotations like
> @noescape; it may also mislabel the parameters.
>
> Dany
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Shadowing imported functions

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

As a side effect, we will be able to purge IUO from Swift abolutely,
completely.
And add a rule that we can shadow Optional parameter with T for some T.
But it is the theme of a separate proposal.

- Anton

2016-04-14 18:28 GMT+03:00 Антон Жилин :

> As promised, I've created a proposal to add @shadowing attribute. Link to
> the proposal:
>
>
> https://github.com/Anton3/swift-evolution/blob/shadowing-imported-functions/proposals/-shadowing-imported-functions.md
>
> Example:
>
> // Imported function (implicit declaration)func dispatch_sync(queue: 
> dispatch_queue_t, block: (@convention(block) () -> Void)!)
> @shadowing(dispatch_sync(queue, block))func sync(queue: dispatch_queue_t, 
> @noescape block: @convention(block) () -> Void)
>
>
> - Anton
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Shadowing imported functions

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

As promised, I've created a proposal to add @shadowing attribute. Link to
the proposal:

https://github.com/Anton3/swift-evolution/blob/shadowing-imported-functions/proposals/-shadowing-imported-functions.md

Example:

// Imported function (implicit declaration)func dispatch_sync(queue:
dispatch_queue_t, block: (@convention(block) () -> Void)!)
@shadowing(dispatch_sync(queue, block))func sync(queue:
dispatch_queue_t, @noescape block: @convention(block) () -> Void)


- Anton
___
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]

Just want to make sure the pull request is noticed.
The proposal is ready for merge. Note that we can now "squash and merge" on
Github.

- Anton
___
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]

No new suggestions have come in 2 days, and so I have created a pull
request! Here it is:
https://github.com/apple/swift-evolution/pull/253

If new glitches are suddenly discovered, Core team will still have the
ability to correct them.
So far we have mostly come to consensus.

- Anton

2016-04-10 13:18 GMT+03:00 Maximilian Hünenberger :

>
> Am 10.04.2016 um 11:48 schrieb Антон Жилин :
>
>
> 2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger :
>
>
> [...]
>
>
> The only minor syntax issue I have is that it is not immediately clear
>> which operators belong to a precedence group. The former syntax with the
>> "members(+, -)" solved this issue. However this has (currently) an
>> extensibility problem:
>>
> If you define a new operator and it should belong to a precedencegroup
>> where you have no access to its source (like Additive) then the whole
>> argument about having operators in one place.
>>
>
> My thoughts went as follows.
> We should be able to add operators to existing groups, for example,
> defined in the Standard Library.
> If so, then this this statement should belong to operator, not precedence
> group.
> But we have to declare the operator anyway, so adding `: Additive` or
> something to the declaration does not cause huge code bloat. Especially
> considering operators are not defined very often.
> Now, we have two ways to do the same thing. External declaration is
> necessary and not so bad. So, following a widely known principle, I remove
> `members`.
>
>
> [...]
>
>
> My issue can be solved by the IDE: It could display all operators which
> are contained in a precedencegroup with quick look or the new interface
> view in Xcode. However this excludes other IDEs which don't have such
> features.
>
> But as I said it is only a minor issue.
>
> Best regards
> - Maximilian
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Allow more operators as custom operators

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

Thank you Brent!
I forgot about the cases you described, where use of `->`, `!` or `?`
cannot be expressed as operator functions.
The question is closed now, I guess.

- Anton

2016-04-11 9:03 GMT+03:00 Brent Royal-Gordon :

> > `->`, `?` and `!` are used in types, but they are mostly unambiguous in
> expressions.
>
> Sure, but types can appear in the middle of expressions. If we drop the
> `.self` requirement, a type name will *be* an expression. I don't think you
> can just ignore type names.
>
> > The only use of `!` in expressions can be rewitten as a built-in
> operator function:
> > postfix func !  (left: T!) -> T
>
> This doesn't work because you can assign through an `!`. For instance:
>
> numberDictionary[key]! += 1
>
> Once we have inout return values, we might be able to make `!` a normal
> postfix operator. (Actually, the same goes for `&`, which just becomes a
> way to leverage the implicit `&`ing of operator arguments into an explicit
> `&`ing.)
>
> > `?` is used in optional method calls:
> > a.method?(b)
> > A parallel proposal is going to remove such syntax from Swift, so this
> will not be a problem.
>
>
> `?` is used for a lot more than that in expressions: optional chaining,
> the ternary operator, etc. None of them can be expressed as ordinary
> operators without significantly expanding operator syntax.
>
> Sorry, I don't think we can make any real progress in this space without
> additional language features.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Allow more operators as custom operators

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

`!` is already a de-facto postfix operator and is called optional
force-unwrapping.
Although it is currently defined not as an operator function, but, oddly
enough, as a special case in Swift grammar.
There are more things that may deserve this operator: for example,
Result would force-return T.

Operator `->` (Arrow) would find a great use in functional programming
libraries (hello Haskell lovers).

As for operator `?`, it can be used to turn some custom type into optional.
For example, Result into Optional.

I would also argue that such operators are unambiguous to their users.
If you define such custom operators and add operator functions for them,
then you definitely know what they mean for you.

- Anton

2016-04-11 0:03 GMT+03:00 Jean-Daniel Dupas :

>
> Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> & (as a prefix operator), ->, ?, and ! (as a postfix operator)
>
> This is the list of built-ins that look like operators, but are banned
> from use as Swift custom operators.
>
> We can review that list.
>
> `&` reserved as a prefix operators for a reason. It marks a variable use
> as `inout`, which currently cannot be done by any Swift operator function.
>
> Other three don't have such justification.
>
> `->`, `?` and `!` are used in types, but they are mostly unambiguous in
> expressions.
>
> The only use of `!` in expressions can be rewitten as a built-in operator
> function:
> postfix func !  (left: T!) -> T
>
> `?` is used in optional method calls:
> a.method?(b)
> A parallel proposal is going to remove such syntax from Swift, so this
> will not be a problem.
>
> `?` is also used in patterns:
> if case x? = optional { ... }
>
>
> While the use is unambiguous for the compiler, I’m not sure it’s going to
> be unambiguous for code readers. Having the same operator meaning different
> things depending the context is a bad idea IMHO.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Allow more operators as custom operators

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

You can already define custom operator `<-`. I'm talking about tokens which
are reserved, but look like operators. For example,
postfix operator ! { }
is an error, which seems illogical, because optional force-unwrapping
totally looks like an operator.

2016-04-11 0:14 GMT+03:00 :

> How about "<-"?
>
> I could see a few shorthands with that for Strings, etc. :-)
>
> On 10 April 2016 at 22:03, Jean-Daniel Dupas via swift-evolution
>  wrote:
> >
> > Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution
> >  a écrit :
> >
> > & (as a prefix operator), ->, ?, and ! (as a postfix operator)
> >
> > This is the list of built-ins that look like operators, but are banned
> from
> > use as Swift custom operators.
> >
> > We can review that list.
> >
> > `&` reserved as a prefix operators for a reason. It marks a variable use
> as
> > `inout`, which currently cannot be done by any Swift operator function.
> >
> > Other three don't have such justification.
> >
> > `->`, `?` and `!` are used in types, but they are mostly unambiguous in
> > expressions.
> >
> > The only use of `!` in expressions can be rewitten as a built-in operator
> > function:
> > postfix func !  (left: T!) -> T
> >
> > `?` is used in optional method calls:
> > a.method?(b)
> > A parallel proposal is going to remove such syntax from Swift, so this
> will
> > not be a problem.
> >
> > `?` is also used in patterns:
> > if case x? = optional { ... }
> >
> >
> > While the use is unambiguous for the compiler, I’m not sure it’s going
> to be
> > unambiguous for code readers. Having the same operator meaning different
> > things depending the context is a bad idea IMHO.
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Continue to abolish IUO

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

I agree and I'm keeping that in mind. So when I wrote:
> So I also propose that T! notation is reserved for entities imported from
Objective-C.
I meant that T! will still be used for unaudited imported APIs, not to
cause the bloat of function signatures you mentioned.
No, I'm not going to argue for complete removal of IUO.

- Anton

2016-04-10 17:59 GMT+03:00 Chris Lattner :

>
> On Apr 10, 2016, at 4:45 AM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> First of all, I tried to change the original proposal to add actual
> @autounwrapped attribute to Swift.
> Because "explicit is better than implicit" and consistency and so on.
>
> Its authors did not pay much attention, and so I'm going to create a
> separate proposal for that purpose.
>
> Next, implicitly unwrapped optional was designed purely for bridging to
> Objective-C (and now C).
> Notation T! that is still used in Swift code, is misleading, because it's
> not an actual type.
>
> So I also propose that T! notation is reserved for entities imported from
> Objective-C.
> Swift code, which needs that behaviour, such as delayed initialization,
> will use @autounwrapped.
> It's more clear and explicit about this being a property behaviour and not
> a type, with all consequences.
>
> What do you think?
>
>
> Hi Anton,
>
> I agree with you in theory, and this is definitely important to discuss.
> My main concern is about the readability impact that this will have on the
> readability of unaudited APIs.  Here are two random unaudited examples,
> with the rules we have today:
>
> JSValue / Darwin:
> func defineProperty(property: String!, descriptor: AnyObject!)
> func strcat(_: UnsafeMutablePointer!, _: UnsafePointer!)
> -> UnsafeMutablePointer!
>
> If we got rid of !, we’d end up with:
>
> func defineProperty(property: @autounwrapped String?, descriptor:
>  @autounwrapped AnyObject?)
> func strcat(_: @autounwrapped
> UnsafeMutablePointer?, _: @autounwrapped UnsafePointer?)
> -> @autounwrapped UnsafeMutablePointer?
>
> Here are some problems:
> a) @autounwrapped ends up dominating the signature, since it is longer
> than many type names.
>
> b) While it is appropriate for return values and properties, it isn’t the
> right attribute name for parameters.  There, a better name would be
> “@unaudited”.  When passing a parameter, there is no behavioral difference
> between T! and T? after all.
>
> I suppose that you could argue that we should just drop annotations
> completely for parameters.  My concern with doing that is that it would
> lose the distinction between audited APIs that accept nil and do something
> meaningful with it, and those that have been unaudited.
>
> -Chris
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Idea] Allow more operators as custom operators

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

& (as a prefix operator), ->, ?, and ! (as a postfix operator)

This is the list of built-ins that look like operators, but are banned from
use as Swift custom operators.

We can review that list.

`&` reserved as a prefix operators for a reason. It marks a variable use as
`inout`, which currently cannot be done by any Swift operator function.

Other three don't have such justification.

`->`, `?` and `!` are used in types, but they are mostly unambiguous in
expressions.

The only use of `!` in expressions can be rewitten as a built-in operator
function:
postfix func !  (left: T!) -> T

`?` is used in optional method calls:
a.method?(b)
A parallel proposal is going to remove such syntax from Swift, so this will
not be a problem.

`?` is also used in patterns:
if case x? = optional { ... }

Such use is also unambigious here, as expressions are not allowed in
patterns.

So my proposal is to allow `->`, `?` and potfix `!` as custom operators.
This proposal requires proposal of removing optional protocol requirements.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Idea] Continue to abolish IUO

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

First of all, I tried to change the original proposal to add actual
@autounwrapped attribute to Swift.
Because "explicit is better than implicit" and consistency and so on.

Its authors did not pay much attention, and so I'm going to create a
separate proposal for that purpose.

Next, implicitly unwrapped optional was designed purely for bridging to
Objective-C (and now C).
Notation T! that is still used in Swift code, is misleading, because it's
not an actual type.

So I also propose that T! notation is reserved for entities imported from
Objective-C.
Swift code, which needs that behaviour, such as delayed initialization,
will use @autounwrapped.
It's more clear and explicit about this being a property behaviour and not
a type, with all consequences.

What do you think?

- Anton
___
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]

Inline:

2016-04-10 2:27 GMT+03:00 Maximilian Hünenberger :

>
> Am 09.04.2016 um 19:43 schrieb Антон Жилин :
> [...]
>
> Now, I see only 1 large question/problem risen by David Waite:
> Should precedence relationships be defined inside or outside of precedence
> groups?
> That is: should we be able to add arbitrary relationships between existing
> groups?
> [...]
>
>
> I'm in favor of declaring precedence relationships inside precedencegroup
> declarations. So they have a fixed place where they are defined.
>

I'm inclined to agree, but still not completely sure. Maybe someone else
could add a vote? Chris? :)

The only minor syntax issue I have is that it is not immediately clear
> which operators belong to a precedence group. The former syntax with the
> "members(+, -)" solved this issue. However this has (currently) an
> extensibility problem:
>
If you define a new operator and it should belong to a precedencegroup
> where you have no access to its source (like Additive) then the whole
> argument about having operators in one place.
>

My thoughts went as follows.
We should be able to add operators to existing groups, for example, defined
in the Standard Library.
If so, then this this statement should belong to operator, not precedence
group.
But we have to declare the operator anyway, so adding `: Additive` or
something to the declaration does not cause huge code bloat. Especially
considering operators are not defined very often.
Now, we have two ways to do the same thing. External declaration is
necessary and not so bad. So, following a widely known principle, I remove
`members`.

Another minor issue regarding your implementation of the standard library
> operators: "Additive" and all "Bitwise" precedencegroups should be above
> "Range"
>
> // so this is also possible without parentheses
> (1+2) ... (3+5)
>
> This issue can be brought up again during another proposal which
> implements this proposal. So the standard library changes *should not*
> belong to this proposal (or least be clarified).
>

Agreed. I will edit that part to form a hierarchy that exactky matches
current state of things.


>
> Kind regards
> - Maximilian
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

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

Here is how I would like this to be implemented.

1. Optional method requirements will be represented in Swift as methods
having import-only attribute @optional and defaulted to be fatalError()

2. On the inside, this default implementation will not define a method.
These objects will not respond to corresponding selector unless the default
implementation is overridden.

3. Calls from Swift side will turn into checks with fatalError()

4. The only way to check existence of such method from Swift will be
`responds(to: Selector)`

Example:

// Objective-C protocol is imported as:
protocol NSTableViewDelegate {
@optional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int)
-> NSView?
@optional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
}
extension NSTableViewDelegate {
@optional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int)
-> NSView? {
fatalError("Unimplemented")
}
@optional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat {
fatalError("Unimplemented")
}
}

class MyDelegate : NSTableViewDelegate {
@optional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int)
-> NSView? {
//...
}
}

getTableViewDelegate().tableView(x, heightOfRow: y) // will fatalError() if
not responds to selector
if getTableViewDelegate().responds(to: #selector(...)) { ... }

- Anton
___
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]

As always, link to the proposal:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

Without further ado, I changed syntax for declaring that an operator
belongs to a group. It now looks like:
infix operator <> : Comparative

Next, I added a notion of default precedence group for infix operators:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md#default-precedence-group

Next, I added a notion of special operatrors that will allow nice
declarations in the Standard Library:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md#special-operators

I have a question on this: is that right? Because corresponding operator
functions still won't be declared anywhere.

Now, I see only 1 large question/problem risen by David Waite:
Should precedence relationships be defined inside or outside of precedence
groups?
That is: should we be able to add arbitrary relationships between existing
groups?

If we discuss this and no more problems are discovered, then I think, we
will be ready for review.

2016-04-09 16:40 GMT+03:00 Chris Lattner :

> > On Apr 9, 2016, at 6:36 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> > I do think it is useful to be able to specify precedence relationships
> without having to define a “group”, to avoid boilerplate when you have one
> operator at a logical level (“??” for example).
>
> Thought there is the obvious counterpoint: sugaring this one case doesn’t
> seem worthwhile, given how infrequently operators are defined.  It is quite
> reasonable to start simple and always require an operator to be a member of
> a group.  We could eliminate that boilerplate at some point down the road
> if it is an issue in practice.
>
> -Chris
___
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]

Inline:

2016-04-09 0:17 GMT+03:00 David Waite :

> Based on commit ‘01317e1a’:
>
> I think that it makes sense for membership to live outside of a precedence
> group. An example is if I wanted to add a new assignment operator ( maybe
> ??= 'assign if nil’), I would want it to have the same precedence as
> existing assignment operators, including precedence with other custom
> operators.
>

Right, the proposal currently allows defining membership both inside and
outside the precedence group, but I agree that with terse enough syntax,
"outside only" will suffice.

Secondly, I think the relationships between precedence groups should be
> defined outside of an existing precedence group. If I have two libraries
> that declare operators in their own custom groups, I may need to define a
> relationship between those groups.
>

This is a highly discussable question. "Outside" option makes it easy to
merge standard library operators into a single hierarchy again. Maybe this
question can be formulated as follows: should module creator have total
control over its operators, or can their behaviour be modified by user?


> This leads the group declaration itself being just of a name and
> associativity.
>
> If group precedence is declared externally, there isn’t a need to support
> ‘>’. Since we are declaring a relationship and not evaluating a
> relationship, there are side-effects that developers will need to
> understand if they are trying to comprehend precedence groups in aggregate.
> Having the groups appear consistently in the same order when defining
> precedence may help with this.
>

I don't think supporting `>` puts much burden on grammar and consistency,
but yeah, it gets some points for external precedence.


> I still assume these relationships are meant to be constrained to a DAG,
> although there might be cases where cycles (or even having multiple graphs)
> would still be unambiguous. I can’t wrap my head around implementation to
> the point of understanding evaluation if not a DAG yet, nor practical
> reasons to have cycles in relations.
>
> Two groups may be unable to be declared to be equivalent. First, they need
> to be of the same associativity. Second are also possibilities of graph
> cycles once the relationships of both groups are overlaid. This is actually
> the trouble I alluded to in my first email in the thread.
>

This time the proposal actually reflects these ideas.

Finally, an infix operator is part of one and only one group. It might make
> sense to have a default group (with no associativity) for operators to fall
> into if they do not declare a precedence group.
>

I have written about creating a separate unnamed group for each operator.
That is nonsense, of course, that should be a single named group without
associativity.

Oh wait, Yet another quasi-syntax based on the above:
>
> precedencegroup Additive, associativity: left
> precedencerelation Additive < Multiplicative
> precedencerelation Range < Additive
> infix operator +, group: Additive
>

I actually like this syntax (the absence of body, especially), but that
commas are inconsistent with the rest of the language. My take at it (hope
somebody can do better):

precedencegroup Additive : associativity(left)
precedencerelation Additive < Multiplicative
precedencerelation Range < Additive
infix operator + : Additive


>
> -DW
>
> On Apr 8, 2016, at 1:28 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The question 4 (`prefix operator ! { }` or `prefix operator !`) seems
> dead simple, because if we need to declare precedence group in body of
> infix operators, then other operators should have it for consistency.
>
> It's not.
> I suggest an alternative syntax for that:
> infix operator <> : Comparative
>
> Colon immediately after the operator may not look the best, but it's the
> only disadvantage I can find. It looks like inheritance and has similar
> meaning.
> So, in this scheme, all operators will have no body.
>
> I also described two methods to declare that operator belongs to a
> precedence group: in `members` and in operator declaration.
> I suggest that this new syntax looks brief/natural enough to remove
> `members` option entirely. "There should be one - and preferably only one -
> obvious way to do it."
>
> - Anton
> ___
> 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]

The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead
simple, because if we need to declare precedence group in body of infix
operators, then other operators should have it for consistency.

It's not.
I suggest an alternative syntax for that:
infix operator <> : Comparative

Colon immediately after the operator may not look the best, but it's the
only disadvantage I can find. It looks like inheritance and has similar
meaning.
So, in this scheme, all operators will have no body.

I also described two methods to declare that operator belongs to a
precedence group: in `members` and in operator declaration.
I suggest that this new syntax looks brief/natural enough to remove
`members` option entirely. "There should be one - and preferably only one -
obvious way to do it."

- Anton

2016-04-08 19:59 GMT+03:00 Антон Жилин :

> Thank you for your reply, Chris!
> I was thinking about purging directives from the proposal, and that was
> what I needed to do it.
> So, the proposal is now completely overhauled:
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Yes, Maximilian and I have considered operator/precedence groups and they
> have now moved from alternatives to main part of the proposal.
>
> Questions:
> 1. Is it OK that associativity is moved to precedence groups and that
> every operator must belong to a precedence group?
> 2. Dictionary-like or "functional keywords"? That is, `associativity:
> left` or `associativity(left)`? So far, only second form has been used
> somewhere inside declarations.
> 3. First-lower or first-upper? `additive` or `Additive`?
> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
>
> Just in case, some questions/concerns copied from previous discussion:
>
> 1. All precedence groups have a "parent".
> It means, all operators will want to have precedence higher than
> Comparative or Ternary, or, at least, Assignment.
>
> 2. Moreover, I could not find any case where I had to write anything other
> than precedence(>, ...)
> Of cause, I cheated, because I can control all these declarations.
> Mere people will have to use `<` to say that Additive, for example, should
> have less priority than their custom operator.
>
> But... can you build a custom operator where `<` will actually be needed?
> I have even stronger doubts on `=`.
> Maybe we can even contract this feature to `parent(Comparative)` or
> something without losing any expressivity?
>
> 3. Can we allow operators to have less priority than `=`?
> If yes, can you give an example of such operator?
>
> - Anton
>
> 2016-04-08 8:59 GMT+03:00 Chris Lattner :
>
>>
>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> First of all, sorry for the delay. I still hope to finish the discussion
>> and push the proposal to review for Swift 3.0.
>> Link for newcomers:
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Sadly, I've moved into the territory opposite to what I had in mind in
>> the beginning: absense of conflict resolution.
>> I wanted lightweight directives, but am moving to closed precedence
>> groups.
>>
>> It's just IMHO, and I think I just need input on this from more people. I
>> still have not heard anything from Core team.
>>
>>
>> Hi Антон,
>>
>> I’m sorry for the delay, I have been out of town recently.  I haven’t
>> read the upstream thread so I hope this isn’t too duplicative.  Here is my
>> 2c:
>>
>> - I completely agree that numeric precedences are lame, it was always the
>> “plan” that they’d be removed someday, but that obviously still hasn’t
>> happened :-)
>> - I definitely agree that a partial ordering between precedences is all
>> that we need/want, and that unspecified relations should be an error.
>>
>> That said, I feel like #operator is a major syntactic regression, both in
>> consistency and predictability.  We use # for two things: directives (like
>> #if) and for expressions (#file).  The #operator is a declaration of an
>> operator, not an expression or a directive.  For declarations, we
>> consistently use a keyword, which allows contextual modifiers before them,
>> along with a body (which is sometimes optional for certain kinds of
>> decls).  I feel like you’re trying to syntactically reduce the weight of
>> something that doesn’t occur very often, which is no real win in
>> expressiveness, and harms consistency.
>>
>> Likewise #pre

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

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

Right, `infix` operators without a precedence group logically should be
able to be used, just with parentheses everywhere.

But users will most likely want to use such operators with `=` without
parentheses. It means, such operators should still belong to some
precedence groups.

I suggest that for each such operator, an separate unnamed group should be
created. It will have no associativity and precedence greater than Ternary
(I actually agree this is the right choice).

I also think it is OK that other operators will not be able to specify
precedence relation with such "unprecedented" operators.

- Anton

8 Apr 2016, Ross O'Brien wrote:

> If I want to define a new operator, it seems like an unnecessary overhead
> to have to immediately decide which precedence group it should belong to
> before it can be used (assuming it doesn't interact with other operators).
> At the moment, new operators are implicitly assigned a 'default' precedence
> of 100; can we make it so that new operators are implicitly assigned to a
> 'default' group with an effective precedence of 100? (I believe this is
> currently the precedence of Ternary, but I'm not sure if I'd have Ternary
> be the default group).
>
> On Fri, Apr 8, 2016 at 5:59 PM, Антон Жилин  > wrote:
>
>> Thank you for your reply, Chris!
>> I was thinking about purging directives from the proposal, and that was
>> what I needed to do it.
>> So, the proposal is now completely overhauled:
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>
>> Yes, Maximilian and I have considered operator/precedence groups and they
>> have now moved from alternatives to main part of the proposal.
>>
>> Questions:
>> 1. Is it OK that associativity is moved to precedence groups and that
>> every operator must belong to a precedence group?
>> 2. Dictionary-like or "functional keywords"? That is, `associativity:
>> left` or `associativity(left)`? So far, only second form has been used
>> somewhere inside declarations.
>> 3. First-lower or first-upper? `additive` or `Additive`?
>> 4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?
>>
>> Just in case, some questions/concerns copied from previous discussion:
>>
>> 1. All precedence groups have a "parent".
>> It means, all operators will want to have precedence higher than
>> Comparative or Ternary, or, at least, Assignment.
>>
>> 2. Moreover, I could not find any case where I had to write anything
>> other than precedence(>, ...)
>> Of cause, I cheated, because I can control all these declarations.
>> Mere people will have to use `<` to say that Additive, for example,
>> should have less priority than their custom operator.
>>
>> But... can you build a custom operator where `<` will actually be needed?
>> I have even stronger doubts on `=`.
>> Maybe we can even contract this feature to `parent(Comparative)` or
>> something without losing any expressivity?
>>
>> 3. Can we allow operators to have less priority than `=`?
>> If yes, can you give an example of such operator?
>>
>> - Anton
>>
>> 2016-04-08 8:59 GMT+03:00 Chris Lattner > >:
>>
>>>
>>> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
>>> swift-evolution@swift.org
>>> > wrote:
>>>
>>> First of all, sorry for the delay. I still hope to finish the discussion
>>> and push the proposal to review for Swift 3.0.
>>> Link for newcomers:
>>>
>>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>>>
>>> Sadly, I've moved into the territory opposite to what I had in mind in
>>> the beginning: absense of conflict resolution.
>>> I wanted lightweight directives, but am moving to closed precedence
>>> groups.
>>>
>>> It's just IMHO, and I think I just need input on this from more people.
>>> I still have not heard anything from Core team.
>>>
>>>
>>> Hi Антон,
>>>
>>> I’m sorry for the delay, I have been out of town recently.  I haven’t
>>> read the upstream thread so I hope this isn’t too duplicative.  Here is my
>>> 2c:
>>>
>>> - I completely agree that numeric precedences are lame, it was always
>>> the “plan” that they’d be removed someday, but that obviously still hasn’t
>>> happened :-)
>>> - I definitely agree that a partial ordering between precedences is all
>>>

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

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

Thank you for your reply, Chris!
I was thinking about purging directives from the proposal, and that was
what I needed to do it.
So, the proposal is now completely overhauled:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

Yes, Maximilian and I have considered operator/precedence groups and they
have now moved from alternatives to main part of the proposal.

Questions:
1. Is it OK that associativity is moved to precedence groups and that every
operator must belong to a precedence group?
2. Dictionary-like or "functional keywords"? That is, `associativity: left`
or `associativity(left)`? So far, only second form has been used somewhere
inside declarations.
3. First-lower or first-upper? `additive` or `Additive`?
4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?

Just in case, some questions/concerns copied from previous discussion:

1. All precedence groups have a "parent".
It means, all operators will want to have precedence higher than
Comparative or Ternary, or, at least, Assignment.

2. Moreover, I could not find any case where I had to write anything other
than precedence(>, ...)
Of cause, I cheated, because I can control all these declarations.
Mere people will have to use `<` to say that Additive, for example, should
have less priority than their custom operator.

But... can you build a custom operator where `<` will actually be needed? I
have even stronger doubts on `=`.
Maybe we can even contract this feature to `parent(Comparative)` or
something without losing any expressivity?

3. Can we allow operators to have less priority than `=`?
If yes, can you give an example of such operator?

- Anton

2016-04-08 8:59 GMT+03:00 Chris Lattner :

>
> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> First of all, sorry for the delay. I still hope to finish the discussion
> and push the proposal to review for Swift 3.0.
> Link for newcomers:
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
> Sadly, I've moved into the territory opposite to what I had in mind in the
> beginning: absense of conflict resolution.
> I wanted lightweight directives, but am moving to closed precedence groups.
>
> It's just IMHO, and I think I just need input on this from more people. I
> still have not heard anything from Core team.
>
>
> Hi Антон,
>
> I’m sorry for the delay, I have been out of town recently.  I haven’t read
> the upstream thread so I hope this isn’t too duplicative.  Here is my 2c:
>
> - I completely agree that numeric precedences are lame, it was always the
> “plan” that they’d be removed someday, but that obviously still hasn’t
> happened :-)
> - I definitely agree that a partial ordering between precedences is all
> that we need/want, and that unspecified relations should be an error.
>
> That said, I feel like #operator is a major syntactic regression, both in
> consistency and predictability.  We use # for two things: directives (like
> #if) and for expressions (#file).  The #operator is a declaration of an
> operator, not an expression or a directive.  For declarations, we
> consistently use a keyword, which allows contextual modifiers before them,
> along with a body (which is sometimes optional for certain kinds of
> decls).  I feel like you’re trying to syntactically reduce the weight of
> something that doesn’t occur very often, which is no real win in
> expressiveness, and harms consistency.
>
> Likewise #precedence is a relationship between two operators.  I’d suggest
> putting them into the body of the operator declaration.
>
> OTOH, the stuff inside the current operator declaration is a random series
> of tokens with no apparent structure.  I think it would be reasonable to
> end up with something like:
>
> infix operator <> {
>   associativity: left
>   precedenceLessThan: *
>   precedenceEqualTo: -
>  }
>
> Or whatever.  The rationale here is that “infix” is primal on the operator
> decl (and thus is outside the braces) but the rest of the stuff can be
> omitted, so it goes inside.
>
> Just in terms of the writing of the proposal, in the "Change precedence
> mechanism” keep in mind that swift code generally doesn’t care about the
> order of declarations (it doesn’t parse top down in the file like C does)
> so the example is a bit misleading.
>
> Question for you: have you considered introducing named precedence groups,
> and having the relationships be between those groups?  For example, I could
> see something like:
>
> operator group additive {}
> operator group multiplicative { greaterThan: additive }
> operator group exponential { greaterThan

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

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

First of all, sorry for the delay. I still hope to finish the discussion
and push the proposal to review for Swift 3.0.
Link for newcomers:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

Sadly, I've moved into the territory opposite to what I had in mind in the
beginning: absense of conflict resolution.
I wanted lightweight directives, but am moving to closed precedence groups.

It's just IMHO, and I think I just need input on this from more people. I
still have not heard anything from Core team.

My main question would be: maximally "mergeable" directives or closed
declarations?

Now, another iteration of syntax discussion.
I've created a sample of definitions of precedence operators for standard
library, using precedence groups (at the end of the proposal).

There is no evidence that an operator could logically belong to multiple
precedence groups.
Really, precedence groups are just a way of writing multiple identical
operator declarations in a shorter way.

Precedence groups will be closed, meaning that no precedence relations can
be added to them outside of their bodies.
It will make merging all standard library operators in a giant hierarchy
less tempting, although possible.
Still, that would be possible. We could disallow that specifically as a
future direction (only for standard library).

Still, new operators must be able to be added to existing precedence groups.
Extensions cannot be used, because namespaces of types and precedencegroups
will not intersect.
So I have to return to declaration of operators, if noone finds a better
way and if noone objects:

precedencegroup Additive {
members(+, -)
associativity(left)
precedence(> Comparative)
}
infix operator +
infix operator -
infix operator &+ { precedencegroup(Additive) }

All operators must have precedence groups.
I thought of allowing operators to be single-operator precedence groups,
but it wouldn't give any real benefits.
I also thought of allowing operators without precedence, but almost all
operators will want at least `precedence(>Assignment)`.

Now, what questions did arise from standard library operator declarations?

1. All precedence groups have a "parent".
It means, all operators will want to have precedence higher than
Comparative or Ternary, or, at least, Assignment.

2. Moreover, I could not find any case where I had to write anything other
than precedence(>, ...)
Of cause, I cheated, because I can control all these declarations.
Mere people will have to use `<` to say that Additive, for example, should
have less priority than their custom operator.

But... can you build a custom operator where `<` will actually be needed? I
have even stronger doubts on `=`.
Maybe we can even contract this feature to `parent(Comparative)` or
something without losing any expressivity?

3. Can we allow operators to have less priority than `=`?
If yes, can you give an example of such operator?

4. Operators `is`, `as`, `as?`, `as!`, `?:`, `=` are not proper Swift
operators.
But we can still support these tokens for consistency.
Their only appearence would be in the standard library.
Alternatively, we can hide their precedence groups and make them a special
case.
It's more a question of implementation complexity.

5. I removed associativity from Ternary, removed BitwiseXor from bitwise
hierarchy.
And made numerous other changes that probably need to be reviewed.

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

>
>
> Am 05.04.2016 um 22:32 schrieb Антон Жилин :
>
> Added
> 
> group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` signs
> would be allowed there.
>
> > Should we allow "precedence(... equalTo ...)" for operators if we have
> precedence groups?
> I think no.
>
> I have a question to your group syntax.
> Since all operators in a precedence group must have equal associativity
> for parsing to work and look logically (right?), wouldn't it be better to
> declare associativity in groups?
> If so, then body of operator declaration won't contain anything, and we
> can remove it:
>
> precedenceGroup Additive {
> associativity(left)
> +, -
> }
> infix operator +
> infix operator -
>
> Does this body of precedenceGroup look OK from syntactic PoV?
>
>
> Associativity in precedence groups is fine however the operators should
> then be grouped possibly: "operators(+, -)"
>
>
> Now, I have another idea.
> As operator declarations themselves don't contain anything anymore, remove
> operator declarations at all. We don't need to pre-declare function names,
> for example.
> Next, `precedenceGroup` could be as well replaced with `precedenceLevel`,
> or just `precedence`, and I would not worry about additional keywords.
> So, our example would look like this:
>
> precedence Additive {
> associativity(left)
> +, -
> }
> precedence

Re: [swift-evolution] Notes from Swift core team 2016-04-05 design discussion

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

Great solution for C interop! Eventually, annotations for C language and
API notes could be replaced with such
automatically-generated-manually-correctable bridge files.
We could support a wide range of conversions for @shadowing_c, such as
convertion of IUO to optional or unwrapped type.
There could also be a CBridgeable protocol (like ObjectiveCBridgeable) to
convert Swift data types to ones imported from C. @shadowing_c should
support such convertions.
Better yet, just rename ObjectiveCBridgeable to Bridgeable, and call new
annotation @shadowingImport. Support for other languages, for example, C++,
can theoretically be added later.
___
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]

Added

group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` signs
would be allowed there.

> Should we allow "precedence(... equalTo ...)" for operators if we have
precedence groups?
I think no.

I have a question to your group syntax.
Since all operators in a precedence group must have equal associativity for
parsing to work and look logically (right?), wouldn't it be better to
declare associativity in groups?
If so, then body of operator declaration won't contain anything, and we can
remove it:

precedenceGroup Additive {
associativity(left)
+, -
}
infix operator +
infix operator -

Does this body of precedenceGroup look OK from syntactic PoV?

Now, I have another idea.
As operator declarations themselves don't contain anything anymore, remove
operator declarations at all. We don't need to pre-declare function names,
for example.
Next, `precedenceGroup` could be as well replaced with `precedenceLevel`,
or just `precedence`, and I would not worry about additional keywords.
So, our example would look like this:

precedence Additive {
associativity(left)
+, -
}
precedence Multiplicative {
associativity(left)
*, /
}
precedence(Additive < Multiplicative)

As a future direction, we could add extensions to precedence levels.
We could go further and replace `precedence` with `operator`, abandoning
the idea of priority for prefix and postfix operators (that I honestly
don't like).

infix operator Additive {
members(+, -)
associativity(left)
}
infix operator Multiplicative {
members(*, /)
associativity(left)
precedence(> Additive)
}

Some other questions:
Do we need transitive precedence propagation?
Do we need resolution of conflicts, i.e. merging multiple definitions of
same operators and groups, where possible?

2016-04-05 22:52 GMT+03:00 Maximilian Hünenberger :

>
> Am 05.04.2016 um 17:29 schrieb Антон Жилин :
>
> David Waite stated a major drawback of precedence groups.
>
> People will often create tiny precedence groups for their modules, and
> user will find that some of them should actually be the same. They will add
> precedenceEqualTo, but all these equivalent groups will still exist. This
> problem cannot occur with transitive precedence propagation. So precedence
> groups really create more problems than solve.
>
> - Anton
>
>
> Do you mean these drawbacks?
>
> "
>
> 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
>
> "
>
> What is the problem? Changing the relative precedence of external
> operators in your file? Doesn't the same "problem" occur in your proposal
> (only with one operator)?
>
> What is the difference between overriding an operator function like this:
>
> func + (l: Int, r: Int) -> Int {
>return 0
> }
>
> This can also mess up your code...
> I'm sorry if I haven't understood your point.
>
> From the other email:
>
> I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky?
> Maybe:
>
> associativity(left)
> precedence(lessThan: +)
> precedence(equalTo: +)
>
> It also solves my concern about dictionary inside braces.
>
>
> I prefer "precedence(+ lessThan *)". However I don't think it's Swift
> style since "lessThan" is like an infix operator *with letters *although
> the symmetry between "+" and "*" would be nicely handled by such operator.
>
> Precedence groups have a great benefit of additional symmetry. Transitive
> precedence propagation, on the other hand, also has benefits:
>
> 1. It does not introduce new entities, just some rules for compiler
> 2. It does not add new keywords. In your current wording, we have to take
> precedence and precedenceGroup as keywords, that's why I
> originally preferred directives
>
>
> Both 1 and 2 are true but I still prefer to use declarations since they
> provide exactly one location where to put operators with equal precedence.
>
> By the way "precedence" is already a keyword... One more to go :)
>
> 3. We actually think in terms of operators, not groups.
> If I want to say that my operator should have the same priority as `+`,
> I'd rather say that I want it to have priority of plus and minus, not
> "belong to multiplicative group".
> If I declare <$> and want it to have same priority as <*>, it would be
> more difficult to invent some name for their group like FunctorManipulator.
>
>
> I think this deserves more discussion:
> Should we allow "precedence(... equalTo ...)" for operators if we have
> precedence groups?
>
> Such a precedence declaration would be contrary to my argument above:
> declare equal operator precedences in one place, which is more maintainable.
>
> On the other hand, in your solution you have a list of global rules
> and don't re

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

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

David Waite stated a major drawback of precedence groups.

People will often create tiny precedence groups for their modules, and user
will find that some of them should actually be the same. They will add
precedenceEqualTo, but all these equivalent groups will still exist. This
problem cannot occur with transitive precedence propagation. So precedence
groups really create more problems than solve.

- Anton

Apr 5, 2016, Антон Жилин wrote:
>
> On the other hand, in your solution you have a list of global rules
> and don't really need braces. How about this?


> #precedenceGroup(Additive)
> #precedenceGroup(Multiplicative)
> #precedence(Additive, less, Multiplicative)
> #operator(+, infix, associativity: left, group: Additive)
> #operator(*, infix, associativity: left, group: Multiplicative)
> #operator(<>, infix)
>
> So precedence group is just a tag that can be used in precedence rules and
> assigned to operators at declaration.
>
___
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]

Apr 5, 2016, Maximilian Hünenberger wrote:

>
> Am 04.04.2016 um 08:06 schrieb Антон Жилин  >:
>
> Is it OK to have "less, equal, greater" in precedence name?
>
> What do you mean by OK? Other operators like == are weird:
>
> precedence(== == <)
> // in comparison to
> precedence(== equalTo <)
>

I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky?
Maybe:

associativity(left)
precedence(lessThan: +)
precedence(equalTo: +)

It also solves my concern about dictionary inside braces.

After thinking more about it I came to the conclusion that we should have
> something like "precedence groups" where all operators have the same
> precedence:
>
> precedenceGroup Additive {
> +, -
> }
>
> precedenceGroup Multiplicative {
> *, /
> }
>
> precedence(Additive lessThan Multiplicative)
>
> infix operator +- {
> associativity: left
> }
>
> extension Additive {
> +-, -+, ++, --
> }
>

Precedence groups have a great benefit of additional symmetry. Transitive
precedence propagation, on the other hand, also has benefits:

1. It does not introduce new entities, just some rules for compiler
2. It does not add new keywords. In your current wording, we have to take
precedence and precedenceGroup as keywords, that's why I
originally preferred directives
3. We actually think in terms of operators, not groups.
If I want to say that my operator should have the same priority as `+`, I'd
rather say that I want it to have priority of plus and minus, not "belong
to multiplicative group".
If I declare <$> and want it to have same priority as <*>, it would be more
difficult to invent some name for their group like FunctorManipulator.

On the other hand, in your solution you have a list of global rules
and don't really need braces. How about this?

#precedenceGroup(Additive)
#precedenceGroup(Multiplicative)
#precedence(Additive, less, Multiplicative)
#operator(+, infix, associativity: left, group: Additive)
#operator(*, infix, associativity: left, group: Multiplicative)
#operator(<>, infix)

So precedence group is just a tag that can be used in precedence rules and
assigned to operators at declaration.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Custom operators

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

Sorry for breaking the thread, next time please mail me a copy :)
Link to the proposal:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

1.  I strongly agree that the numeric precedence system is not great. From
> a implementation point of view, the way to specify them in your
> proposal
> essentially gave all visible operators a partial order, in which we can
> draw a directed gragh with operators being the nodes and their relation
> being arcs. A part of the graph might look like: '^' --> '*' --> '+',
> the
> nodes being the math operators. We can tell '*' has a higher precedence
> than '+', '^' has a higher precedence than '*' and '+', by follwing the
> arcs. If one operator is not reachable from another, and vice versa,
> then
> composing these two is illegal. We need to teach the compiler this
> concept.
>

Right, that semantics was actually the main driver of the proposal.

2.  Currently, it's not possible to specify precedence for pre- and postfix
> operators. Chris Lattner has mentioned that the
> following result is not desirable:
> ∆x + y
> … where ∆ has a lower precendence than + while it's required to have no
> space between ∆ and the operand. My understanding is that if spaces
> were
> to be allowed here, parsing such expression without ambiguity is a
> non-trivial challenge. So, will it be possible to specify precedence
> for
> pre/postfix operators under your proposal?
>

No, I currently leave prefix and postfix operators unchanged (apart from
syntax shuffling). I will add this as a future direction.
Prefix and postfix operators would behave the same as infix, but have
higher precedence than any infix operator by default.
This feature, if added, would be non-breaking.


> 3.  It may be a good exercise to work out how would each of the builtin
> operators would be defined with this change and mention it (not the
> entire
> definition, but the fact that it's possible, or reasons why it produces
> any difference) in the proposal.


Operators `is`, `as`, `as?`, `as!`, which are not actually Swift custom
operators (they contain letters), will not participate in this exercise.
(Let's not discuss allowing letters in operators here.)
That being said, great idea. I will add example declarations of standard
library operators.

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