[swift-evolution] API Guidelines: dropFirst?

What is the rationale behind the name dropFirst()? Being a non-mutating method it should clearly be e.g. droppingFirst() according to the API Naming Guidelines. I can't seem to find the SE thread dealing with this. ___ swift-evolution mailing list swift-

Re: [swift-evolution] [Idea] Set variables to "_" in two-stage init; remove IUO

I don’t remember a proposal for that, but I would definitely support one. I use this pattern all the time (usually by initializing to a default value first), and it would be nice to have an explicit/safe way to handle it, (and to avoid waisting cycles creating an object I never use). Perhaps w

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

My understanding of the proposal was that the unannotated properties/methods inside of a scope have the same *visibility* as their surrounding scope, or internal, whichever is less. That is slightly different than having the same access level. Thus: private struct Outer { var inner:Int

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

I think this was the original intent of SE-0025, but it is subject to the issue I raised in the root: If the entire decl is declaration-private, then it cannot be constructed because its members are also declaration-private. We can forbid it at the top level but that doesn't solve the problem f

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

Wouldn't this get solved by ditching fileprivate (which would be /is right now/ the default behavior for private) and introduce a more private level instead, e.g. "declaration" or "scope" /// File A public struct MyStruct { declaration var x: Int private var y: Int inter

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

Yes, we agree. Can we please discuss what to do about SE-0025? ~Robert Widmann 2016/06/15 21:18、Charles Srstka のメッセージ: >> On Jun 15, 2016, at 11:04 PM, Charles Srstka via swift-evolution >> wrote: >> >> Result is that the property is only accessible from inside its parent type. > > *inside

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

> On Jun 15, 2016, at 11:04 PM, Charles Srstka via swift-evolution > wrote: > > Result is that the property is only accessible from inside its parent type. *inside the type’s parent type Charles ___ swift-evolution mailing list swift-evolution@swift

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

Charles we've diverged from the actual issue at hand to nitpick my English. Read the code (that std::min tho!). We have a problem here and no obvious solution that doesn't involve special-casing parts of this proposal. Do you have a solution or shall we take this offline? I can provide you m

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

> On Jun 15, 2016, at 10:46 PM, Robert Widmann wrote: > > That is a different discussion entirely. Once you fall below internal then > we do not default to internal, we default to the maximum access level of the > outer decl. Read that linked part of the type checker if you don't believe > m

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

> On Jun 15, 2016, at 11:27 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Wed, Jun 15, 2016 at 4:14 PM, Matthew Johnson >> wrote: >> >>> On Jun 15, 2016, at 4:08 PM, Xiaodi Wu wrote: >>> On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson wrote: > On Jun 15, 2016, a

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

Also consider what would happen if we did allow access control to escalate here: Suppose that code did not emit a diagnostic, then the member is still private because you cannot reference the class outside of file scope. You see, even if we did escalate access control for unannotated members, e

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

That is a different discussion entirely. Once you fall below internal then we do not default to internal, we default to the maximum access level of the outer decl. Read that linked part of the type checker if you don't believe me. I also had to fix several hundred lines of SwiftPM and corelib

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

Sent from my iPad > On Jun 15, 2016, at 8:48 PM, Erica Sadun via swift-evolution > wrote: > > Perhaps the proposal can be amended with this information with the approval > of the core team. I imagine that a list of rules and a chart might be > valuable. Even if adding to the proposal is the

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

Perhaps the proposal can be amended with this information with the approval of the core team. I imagine that a list of rules and a chart might be valuable. Even if adding to the proposal is the wrong way to go, a publicly accessible and vetted document would be useful to refer people to. Maybe s

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

> On Jun 15, 2016, at 8:36 PM, Robert Widmann wrote: > > Point 3 is *not* how member lookup applies access control levels to > unannotated properties of outer structures (see > https://github.com/CodaFi/swift/blob/fb9f9536a5760369457d0f9c49599415cbc36e07/lib/Sema/TypeCheckDecl.cpp#L1470 > > <

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

Point 3 is *not* how member lookup applies access control levels to unannotated properties of outer structures (see https://github.com/CodaFi/swift/blob/fb9f9536a5760369457d0f9c49599415cbc36e07/lib/Sema/TypeCheckDecl.cpp#L1470) and makes no sense. They do not default to "internal" when unannota

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

Sent from my iPad > On Jun 15, 2016, at 6:51 PM, Charles Srstka wrote: > > I think you guys are making this more complicated than it is. The rules here > seem fairly simple: > > 1. The default access level is “internal”. > > 2. A type declared “private” at the top level will be visible to t

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

I think you guys are making this more complicated than it is. The rules here seem fairly simple: 1. The default access level is “internal”. 2. A type declared “private” at the top level will be visible to the file only. 3. If they are not given an access level, properties declared on the type w

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

Sent from my iPad > On Jun 15, 2016, at 5:17 PM, Robert Widmann wrote: > > I await their opinions, but even with that change we still have a problem > with the philosophy here. The motivation behind the fileprivate/private > distinction is, as you say in the proposal "[a] reliable way to hi

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

Sent from my iPad > On Jun 15, 2016, at 5:17 PM, Robert Widmann wrote: > > I await their opinions I as well. :) > , but even with that change we still have a problem with the philosophy here. > The motivation behind the fileprivate/private distinction is, as you say in > the proposal "[a

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

On Wed, Jun 15, 2016 at 4:58 PM, Dany St-Amant via swift-evolution < swift-evolution@swift.org> wrote: > > > Le 15 juin 2016 à 17:23, Jean-Daniel Dupas via swift-evolution < > swift-evolution@swift.org> a écrit : > > > > > >> Le 13 juin 2016 à 17:26, Erica Sadun via swift-evolution < > swift-evolu

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

I await their opinions, but even with that change we still have a problem with the philosophy here. The motivation behind the fileprivate/private distinction is, as you say in the proposal "[a] reliable way to hide implementation details...". Why would you want any members you're trying to hid

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

> Le 15 juin 2016 à 17:23, Jean-Daniel Dupas via swift-evolution > a écrit : > > >> Le 13 juin 2016 à 17:26, Erica Sadun via swift-evolution >> a écrit : >> >> >>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution >>> wrote: >>> >>> I am 100% with Charlie on this. Expressivene

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

On Wed, Jun 15, 2016 at 4:30 PM, Matthew Johnson wrote: > > On Jun 15, 2016, at 4:27 PM, Xiaodi Wu wrote: > > On Wed, Jun 15, 2016 at 4:14 PM, Matthew Johnson > wrote: > >> >> On Jun 15, 2016, at 4:08 PM, Xiaodi Wu wrote: >> >> On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson >> wrote: >> >>

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

> On Jun 15, 2016, at 4:27 PM, Xiaodi Wu wrote: > > On Wed, Jun 15, 2016 at 4:14 PM, Matthew Johnson > wrote: > >> On Jun 15, 2016, at 4:08 PM, Xiaodi Wu > > wrote: >> >> On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson >

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

On Wed, Jun 15, 2016 at 4:14 PM, Matthew Johnson wrote: > > On Jun 15, 2016, at 4:08 PM, Xiaodi Wu wrote: > > On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson > wrote: > >> >> On Jun 15, 2016, at 2:55 PM, Xiaodi Wu wrote: >> >> On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evoluti

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

> Le 13 juin 2016 à 17:26, Erica Sadun via swift-evolution > a écrit : > > >> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution >> wrote: >> >> I am 100% with Charlie on this. Expressiveness has to do with the >> *effectiveness* of conveying a thought or a feeling. >> >> Keep "w

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

> On Jun 15, 2016, at 4:08 PM, Xiaodi Wu wrote: > > On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson > wrote: > >> On Jun 15, 2016, at 2:55 PM, Xiaodi Wu > > wrote: >> >> On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evol

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

On Wed, Jun 15, 2016 at 3:09 PM, Matthew Johnson wrote: > > On Jun 15, 2016, at 2:55 PM, Xiaodi Wu wrote: > > On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org>wrote: > >> >> On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution < >> swi

[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 swift-evolu

Re: [swift-evolution] Normalizing operator's types

Function currying wasn’t removed, just some of the confusing syntax for it. This works fine in the Xcode 8 beta: infix operator <> {} // random operator that doesn’t do anything else func <> (op: (T, U) -> V, rhs: U) -> ((T) -> V) { return { op($0, rhs) } } func <> (lhs: T, op: (T, U) -> V) ->

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

> On Jun 15, 2016, at 2:53 PM, Adrian Zubarev via swift-evolution > wrote: > > Its my bad habit describing everything as a ‘bug’. Don’t judge me for that. I > fully agree with you about the whole issue. > > No problem. :) > You probably missed // 2. file scope (Level 0), but it’s okay. So my

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

> On Jun 15, 2016, at 2:55 PM, Xiaodi Wu wrote: > > On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>>wrote: > >> On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I was re

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

On Wed, Jun 15, 2016 at 2:48 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote: > > I was referencing to the issue Robert discovered in his implementation. > > I do un

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

Its my bad habit describing everything as a ‘bug’. Don’t judge me for that. I fully agree with you about the whole issue. You probably missed // 2. file scope (Level 0), but it’s okay. So my second example was indeed correct. I described ‘levels’ starting from zero for each individual file, bec

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

> On Jun 15, 2016, at 2:43 PM, Adrian Zubarev via swift-evolution > wrote: > > Shouldn’t a file act like an individual scope? If so why would A be visible > in C? Is it because files act not a lexical scopes? > > Did you mean that `C` is in a different file? That wasn’t clear to me. Maybe

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

> On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution > wrote: > > I was referencing to the issue Robert discovered in his implementation. > > I do understand what the proposal is all about, but thank you for > re-clarifying that to me. :) > > I don’t think it’s a bug, but it

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

I was referencing to the issue Robert discovered in his implementation. I do understand what the proposal is all about, but thank you for re-clarifying that to me. :) --  Adrian Zubarev Sent with Airmail Am 15. Juni 2016 um 21:40:37, Matthew Johnson (matt...@anandabits.com) schrieb: What see

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

Shouldn’t a file act like an individual scope? If so why would A be visible in C? Is it because files act not a lexical scopes? --  Adrian Zubarev Sent with Airmail Am 15. Juni 2016 um 21:34:23, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: Your example #2 is just incorrect.  `A`

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

> On Jun 15, 2016, at 2:34 PM, Adrian Zubarev via swift-evolution > wrote: > > Ok I already see side effects in my idea which breaks the entire scoped > access level thing :/ > > class A { >// incrementTwice() is not visible here > } > > extension A { >private func incrementTwice() {

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

> On Jun 15, 2016, at 2:29 PM, Robert Widmann wrote: > > The meaning of private according to the proposal is not scope-dependent, it > is decl-dependent. The mental gymnastics we are both going through right now > are not in the proposal. I would like them to be. I agree that the proposal i

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

Ok I already see side effects in my idea which breaks the entire scoped access level thing :/ class A { // incrementTwice() is not visible here } extension A { private func incrementTwice() { } } In my model incrementTwice would be visible in A which it shouldn’t (I agree to that). T

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

> On Jun 15, 2016, at 2:25 PM, Adrian Zubarev via swift-evolution > wrote: > > How about this, it might make more sense and relax the behavior a little: > > // 1. file scope (Level 0) > > // Level 0 because its declared at file scope > private struct A { > > /* implicit private */ i

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

The meaning of private according to the proposal is not scope-dependent, it is decl-dependent. The mental gymnastics we are both going through right now are not in the proposal. I would like them to be. ~Robert Widmann 2016/06/15 12:26、Matthew Johnson のメッセージ: > >> On Jun 15, 2016, at 2:19

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

> On Jun 15, 2016, at 2:19 PM, Robert Widmann wrote: > > We have diagnostics specifically to prohibit this case. You cannot raise the > access level of members. > > private struct Foo { > internal var x : String = "" > } > > warning: declaring an internal var for a private struct. > > H

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

How about this, it might make more sense and relax the behavior a little: // 1. file scope (Level 0) // Level 0 because its declared at file scope private struct A { /* implicit private */ init() {} // Level 1 } // Level 0 struct B { // `A` is visible here and is seen as `fil

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

We have diagnostics specifically to prohibit this case. You cannot raise the access level of members. private struct Foo { internal var x : String = "" } warning: declaring an internal var for a private struct. Hence, the highest allowable level of access for x is private and it becomes i

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

> On Jun 15, 2016, at 2:04 PM, Robert Widmann wrote: > > > > 2016/06/15 11:47、Matthew Johnson > のメッセージ: > >> >>> On Jun 15, 2016, at 1:37 PM, Robert Widmann >>> wrote: >>> >>> The scope of the *declaration* is not the issue. The scope of its >>> *members*

Re: [swift-evolution] Arbitrary-sized integers

> On Jun 15, 2016, at 10:58 AM, Félix Cloutier via swift-evolution > wrote: > > I know that one, but I merely need fixed-size big integers. Backing all of my > integers with an array seems overly expensive. > > Félix > >> Le 14 juin 2016 à 23:25:16, T.J. Usiyan >

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

Sent from my iPad > On Jun 15, 2016, at 1:51 PM, Robert Widmann wrote: > > Then it is no different from fileprivate. Yes, at file scope this is true. A reasonable argument can be made for prohibiting it at file scope for the sake of clarity, but if it is allowed it should behave the same a

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

2016/06/15 11:47、Matthew Johnson のメッセージ: > >> On Jun 15, 2016, at 1:37 PM, Robert Widmann wrote: >> >> The scope of the *declaration* is not the issue. The scope of its *members* >> is. > > Let’s consider an example: > > private struct Foo { >var bar: Int > } > > // elsewhere in the

[swift-evolution] Normalizing operator's types

Hi Swift, Since the "removal" of curried function, I am looking for some elegant ways to work with partial functions (and reduce creation of closure and nested func for the developper). And now I am asking myself if it's not better to align operator's types to the arrow style instead of using

Re: [swift-evolution] Nil coalescing operator precedence

I was asking about only bitwise operators, but the reply was more general. One reply from Chris Lattner: > On Feb 13, 2016, at 6:32 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Not sure if this is intentional, a bug, and/or a topic for evolution: > > > > In Swift

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

Then it is no different from fileprivate. ~Robert Widmann 2016/06/15 11:47、Matthew Johnson のメッセージ: > >> On Jun 15, 2016, at 1:37 PM, Robert Widmann wrote: >> >> The scope of the *declaration* is not the issue. The scope of its *members* >> is. > > Let’s consider an example: > > private s

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

On Wed, Jun 15, 2016 at 1:47 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun 15, 2016, at 1:37 PM, Robert Widmann > wrote: > > > > The scope of the *declaration* is not the issue. The scope of its > *members* is. > > Let’s consider an example: > > private

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

Yes, and it does, and this is not the issue. The problem is that when we generate the initializer for a private type it is invisible to those outside its scope (which is, by definition, everybody else). X cannot be initialized and cannot declare any initializer that can possibly be visible bec

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

On Wed, Jun 15, 2016 at 1:37 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > The scope of the *declaration* is not the issue. The scope of its > *members* is. > Oy, if we're to have both `fileprivate` and `private`, then the previously visually appealing rule about m

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

> On Jun 15, 2016, at 1:37 PM, Robert Widmann wrote: > > The scope of the *declaration* is not the issue. The scope of its *members* > is. Let’s consider an example: private struct Foo { var bar: Int } // elsewhere in the same file: var foo = Foo(bar: 42) foo.bar = 44 `Foo` is declared

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu wrote: > On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha wrote: > >> Yes. They’re all operators we know about already, and the same argument >> applies. Just like you wouldn’t change + to have a higher precedence than >> *, bitwise operators already have th

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

Shouldn’t it act theoretically something like this: // Begin file A (which acts like a scope) // where `type` can be enum, struct, class or protocol private type X {} fileprivate type Y {} public struct Z { var x: X var y: Y } // End file A private should always behave the same

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

The scope of the *declaration* is not the issue. The scope of its *members* is. ~Robert Widmann 2016/06/15 11:36、Matthew Johnson のメッセージ: > The scope for a top-level declaration is the file itself. This means that > top-level declarations with `private` and `fileprivate` should have the same

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

The scope for a top-level declaration is the file itself. This means that top-level declarations with `private` and `fileprivate` should have the same behavior. They should not be uninstantiable or unusable. -Matthew > On Jun 15, 2016, at 1:31 PM, Robert Widmann via swift-evolution > wrote:

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha wrote: > Yes. They’re all operators we know about already, and the same argument > applies. Just like you wouldn’t change + to have a higher precedence than > *, bitwise operators already have their own, uniform precedences. I can’t > see any reason not

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 1:17 PM, Saagar Jha wrote: > 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 languag

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

> On Jun 15, 2016, at 7:53 PM, Vladimir.S wrote: > >> On 15.06.2016 18:42, L. Mihalkovic via swift-evolution wrote: >> >> On Jun 15, 2016, at 5:04 PM, Austin Zheng > > wrote: >> >>> On Jun 14, 2016, at 7:12 AM, L. Mihalkovic via swift-evolution mailto:s

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

While implementing SE-0025 (fileprivate), I noticed an interesting bug in the proposal. Under the implementation outlined there, any top-level structure, class, or enum declared private cannot possibly be instantiated and so cannot be used in any way. Because of this, private top-level declara

Re: [swift-evolution] Nil coalescing operator precedence

Yes. They’re all operators we know about already, and the same argument applies. Just like you wouldn’t change + to have a higher precedence than *, bitwise operators already have their own, uniform precedences. I can’t see any reason not to have one, other than confusion from those who aren’t comp

Re: [swift-evolution] Nil coalescing operator precedence

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

Re: [swift-evolution] Nil coalescing operator precedence

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

[swift-evolution] libdispatch renaming feedback

Here’s some feedback after translating some Dispatch-heavy code for the new Dispatch module. 1. I like the result. Thanks for the effort! 2. Omissions - Can't initialize a new queue or obtain a global queue using a DispatchQoS instance. [SR-1770] One thing I have previously done was the follo

Re: [swift-evolution] Nil coalescing operator precedence

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 Антон Жилин

Re: [swift-evolution] Nil coalescing operator precedence

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 Антон Жилин

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

On 15.06.2016 18:42, L. Mihalkovic via swift-evolution wrote: On Jun 15, 2016, at 5:04 PM, Austin Zheng mailto:austinzh...@gmail.com>> wrote: On Jun 14, 2016, at 7:12 AM, L. Mihalkovic via swift-evolution mailto:swift-evolution@swift.org>> wrote: On Jun 14, 2016, at 11:31 AM, Patrick Smith

Re: [swift-evolution] Nil coalescing operator precedence

On 15.06.2016 19:15, Xiaodi Wu wrote: On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: > If precedence between two operators is undefined, we cannot omit > parentheses. Hm.. Probably the initial problem could be solved wi

Re: [swift-evolution] Nil coalescing operator precedence

On 15.06.2016 19:00, Xiaodi Wu wrote: On Wed, Jun 15, 2016 at 10:51 AM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 15.06.2016 17:19, Sean Heber wrote: On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution mailto:swift-evolution

Re: [swift-evolution] Nil coalescing operator precedence

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

Re: [swift-evolution] Property with class and protocol type

Judging from doug's email, i was thinking that the format of the ideal proposal should be somewhere in between what Austin did and what i played with so far. It is still a small exercise in trying to show how things do not have to be so complicated, but 3.0 is still very much today's focus. ht

Re: [swift-evolution] Nil coalescing operator precedence

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

Re: [swift-evolution] Nil coalescing operator precedence

> 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?) ? As for rules of pre

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 10:51 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On 15.06.2016 17:19, Sean Heber wrote: > >> >> On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution >>> wrote: >>> >>> I believe we should not take into account any IDE features when >>>

Re: [swift-evolution] [idea] Quick Help working for Keywords

On Wed, Jun 15, 2016 at 5:15 AM, Jo Albright via swift-evolution < swift-evolution@swift.org> wrote: > Creating a new thread for this, to gain more interest. > > I am proposing that we extend Quick Help in Xcode to include keywords > (with context). This will allow for quick access to information

Re: [swift-evolution] Arbitrary-sized integers

I know that one, but I merely need fixed-size big integers. Backing all of my integers with an array seems overly expensive. Félix > Le 14 juin 2016 à 23:25:16, T.J. Usiyan a écrit : > > There is also a fairly robust implementation of arbitrary size integers here > https://github.com/lorentey

Re: [swift-evolution] Property with class and protocol type

+1 -- Adrian Zubarev Sent with Airmail Am 15. Juni 2016 um 16:56:44, Austin Zheng (austinzh...@gmail.com(mailto:austinzh...@gmail.com)) schrieb: > > > > On Jun 15, 2016, at 3:35 AM, L. Mihalkovic via swift-evolution > > mailto:swift-evolution@swift.org)> wrote: > > > > > > On Jun

Re: [swift-evolution] Nil coalescing operator precedence

On 15.06.2016 17:19, Sean Heber wrote: On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution wrote: I believe we should not take into account any IDE features when discussing the *language*. One will write Swift script code in vim on linux, other will read in web browser on github etc.

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 9:19 AM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I believe we should not take into account any IDE features when > discussing the *lang

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 9:53 AM, Антон Жилин wrote: > Nice points, I also think that unless operators are from the same domain, > more parentheses is better. > I agree. I would, however, advocate for defining 'domains' widely. For instance, the precedence between comparison operators and arithme

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

> On Jun 15, 2016, at 5:04 PM, Austin Zheng wrote: > > >> On Jun 14, 2016, at 7:12 AM, L. Mihalkovic via swift-evolution >> wrote: >> >> >> On Jun 14, 2016, at 11:31 AM, Patrick Smith via swift-evolution >> wrote: >> >>> Thanks Xiaodi. Interesting arguments there. It possibly seems a sha

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

> On Jun 14, 2016, at 7:12 AM, L. Mihalkovic via swift-evolution > wrote: > > > On Jun 14, 2016, at 11:31 AM, Patrick Smith via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> Thanks Xiaodi. Interesting arguments there. It possibly seems a shame to me, >> because it has kno

Re: [swift-evolution] Property with class and protocol type

> On Jun 15, 2016, at 3:35 AM, L. Mihalkovic via swift-evolution > wrote: > > > > On Jun 15, 2016, at 8:24 AM, Adrian Zubarev via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I guess you don’t understand that a so called proposal should have enough >> details to explain

Re: [swift-evolution] Nil coalescing operator precedence

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 operato

Re: [swift-evolution] Nil coalescing operator precedence

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 kno

Re: [swift-evolution] Nil coalescing operator precedence

> On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution > wrote: > > I believe we should not take into account any IDE features when discussing > the *language*. One will write Swift script code in vim on linux, other will > read in web browser on github etc. Unrelated to anything else

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 8:43 AM, Антон Жилин wrote: > `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` -- m

Re: [swift-evolution] Nil coalescing operator precedence

On Wed, Jun 15, 2016 at 5:35 AM, Jo Albright wrote: > I agree, precedence should be left for math operations that are known by > all. > Practically, this is largely the case, in that stdlib operators are more or less restricted to math operations. Previously, I raised the issue of bitwise operat

Re: [swift-evolution] Nil coalescing operator precedence

`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 @aut

Re: [swift-evolution] Nil coalescing operator precedence

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 parenthese

Re: [swift-evolution] [Idea] Set variables to "_" in two-stage init; remove IUO

I believe there was(was?) already a suggestion to introduce special methods that could be called from initializers. IMO this is a better solution to the problem as you really should not call 'usual' instance method until the instance is fully instantiated(super.init() called in your case): cla

[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 https://lists.swift.org/mailman/listinfo/s

Re: [swift-evolution] Nil coalescing operator precedence

+1 for all of your opinions. I also believe that wrong assumption on precedence is a reason of big number of errors. More, I believe precedence in complex expressions can confuse not less than removed ++/-- operators (or requirement to explicit type conversions for different integers types in e

Re: [swift-evolution] [Idea] Set variables to "_" in two-stage init; remove IUO

Maybe there are several initialisers, with different ways of calculating 'y' depending on what you give it. Karl > > On Jun 15, 2016 at 2:26 PM, (mailto:char...@charliemonroe.net)> wrote: > > > > Is there a particular reason for not using lazy var here?

  1   2   >