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

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

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

GMT+03:00 David Waite <da...@alkaline-solutions.com>: >> >>> >>> On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> * Rename @noes

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

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 <da...@alkaline-solutions.com>: > > On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

[swift-evolution] State of @noescape ?

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

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

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

[swift-evolution] [Proposal] Fix lazy filter

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

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

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

[swift-evolution] [Proposal] Fix lazy filter

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] [Discussion] A Problem With SE-0025?

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

Re: [swift-evolution] Nil coalescing operator precedence

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,

Re: [swift-evolution] Nil coalescing operator precedence

gt;>> 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 >>>> ope

Re: [swift-evolution] Nil coalescing operator precedence

perators. 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" &

[swift-evolution] Nil coalescing operator precedence

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

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

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

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

+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

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

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

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

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

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

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

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

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

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

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

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

ms 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 {

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

Two' 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:

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

==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 { }

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

nguage, 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 <bkn...@me.com>: > > On Jun 8, 2016, at 11:54 AM, Антон Жилин via

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

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.

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

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

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

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,

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

a separate proposal. - Anton 2016-06-06 22:40 GMT+03:00 Michael Peternell <michael.petern...@gmx.at>: > > > Am 06.06.2016 um 00:53 schrieb Charles Srstka <cocoa...@charlessoft.com > >: > > > >> On Jun 5, 2016, at 5:41 PM, Michael Peternel

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

> 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

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

-06 1:53 GMT+03:00 Charles Srstka <cocoa...@charlessoft.com>: > 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

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

lly 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

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

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

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

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

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

@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

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

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

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

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

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

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 {

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

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

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

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

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

> > > 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`,

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

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

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

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 pro

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

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

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

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

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

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

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

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

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

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

Re: [swift-evolution] [Draft] Mixins

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

[swift-evolution] Disambiguate Return Type With Void

+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

[swift-evolution] [Idea] Repurpose Void

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

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

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

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

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

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

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

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

+1, but this proposal need further work. Specification of the new function grammar is needed. Currently, it looks like: function-type → type

Re: [swift-evolution] [Draft] Mixins

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

[swift-evolution] [Draft] Mixins

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

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

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

[swift-evolution] [Proposal] Custom operators

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

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

ing versions of methods. > Correct me if this is a wrong conclusion. > > - Anton > > 2016-04-15 19:31 GMT+03:00 Erica Sadun <er...@ericasadun.com>: > >> >> On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution < >> swift-evolution@swift.or

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

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 <er...@ericasadun.com>: > > On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evol

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

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.

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

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 <dsa@icloud.com>: > > Le 14 avr. 2016 à 11:28, Антон Жилин via swift-evolution < > swift-evolution@swift.org> a écrit : > > As promis

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

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

[swift-evolution] [Proposal] Shadowing imported functions

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:

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

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

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

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

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

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

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

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 <mail...@xenonium.com>: > > Le 10 avr. 2016 à 15:01, Антон Жилин via swift-evolution &l

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

+swift...@gmail.com>: > 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 > <swift-evolution@swift.org> wrote: > > > > Le 10 avr. 2016 à 15:01, Анто

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

gue for complete removal of IUO. - Anton 2016-04-10 17:59 GMT+03:00 Chris Lattner <clatt...@apple.com>: > > 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

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

& (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

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

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

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

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

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

mmas 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, 20

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

;> 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 <clatt...@apple.com >>

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

@apple.com>: > > 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: > >

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

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

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

Added group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` signs would be allowed there. > Should we allow "precedence(... equalTo ...)" for operators

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

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

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

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

[swift-evolution] [Proposal] Custom operators

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

[swift-evolution] [Proposal] Custom operators

s cases, prompting the >>> user to use parenthesis. >>> >>> - I’d prefer instead of operator precedence groups just being implicit >>> by use of #precedence equalTo, that the operators are bound to a group >>> explicitly. Something like >>> #

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

cedence(“additive”, lessThan: “multiplicative”) > > However, this may create more issues than it solves (two frameworks > creating their own custom operators, putting them in custom precedence > groups, and the consumer decides the two precedence groups are really > equivalent) >

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

Thank you for a helpful answer! I like the idea of overriding precedence from another module. We won't need to introduce additional keywords or visibility for operators. I will add it to the proposal. I assume you mean precedence inside braces of operator, then operator scope makes sense. Self

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

Right, the proposal in its current form does not really aim to resolve such conflicts, although it makes them occur less often by "merging" precedence and associativity when possible. At first, I also tried to resolve such conflicts by naming operators. But I found that compiler instructions will

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

s, and IMO it’s actually > more readable despite the added noise. > > On 3 Apr 2016, at 10:36, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote: > > Swift 2.2 is out, and I restart discussion on syntax for custom operators. > I insist that this time we s

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

or use of *Pointer strictly inside Swift. It is mainly interaction with C that will become more verbose. 2016-03-28 20:45 GMT+03:00 Jordan Rose <jordan_r...@apple.com>: > > On Mar 26, 2016, at 9:15, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote: > >

[swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

UnsafePointer is most often used for interfacing with C libraries. They will almost never add nullability annotations. It means that UnsafePointer? will become an idiom. But we currently have a terser form, and it's arguably clear from it that Pointer can be null. 90% of programmers and 99.9% of

[swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

First of all, -1 for still not exposing @autounwrapped to the user as discussed. But there is a greater problem. If we move from current type syntax to attribute syntax, we should remove T!, because it can no longer be a type. Otherwise we will only bring more inconsistency into the language.

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I have to agree with you. Still "module" needs to be somewhere in the new access level for internal, and if possible, "file" in private. 2016-03-15 16:07 GMT+03:00 Ilya Belenkiy : > These names are very uniform, and the context is immediately clear, but > they are very

[swift-evolution] SE-0025: Scoped Access Level, next steps

My take at it: access(global) access(module) // default access(file) access(scope) Very uniform. Argument to `access` is visibility scope. ___ swift-evolution mailing list swift-evolution@swift.org

[swift-evolution] [Draft] Allow trailing commas in argument lists

-1 Trailing commas look urgly to me. We should not just borrow everything from C-family. I believe, there is a better way out. Separation by whitespace, on the other hand, seems interesting: sayHello(to: "John" and: "Jack") Can be used for multiline calls, as well as dense argument passing:

[swift-evolution] [META] Re-invigorating the compiler directive discussion

These directives (including current os thingy) don't have # in front of them. I think there is inconsistency here. Consider: #if 2 + 3 == 5 //... #end let v: Bool = #os(iOS) #if #os(iOS) //... #end I mean, #os and its suggested look-a-likes are not normal functions and so should have # in

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

Cleared up that interfaces can be used in static dispatch as well. Added other possible keyword variants instead of protocol/interface (there may still be more). Added some lines about interoperation with existentials proposal. I agree that current proposal is in opposition of it, and that

[swift-evolution] [Proposal] Separate protocols and interfaces

Introduction of interfaces will clean up the current blend of static and dynamic protocols, and solve at least three popular issues. Please see: https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md ___