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

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

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

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

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

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

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

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,

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

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

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

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 >

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

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

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

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

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

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

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

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

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:

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

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

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:

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

[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] 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,

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 > >wrote: > >> On Jun 15, 2016, at 2:46 PM, Adrian Zubarev via swift-evolution >>

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

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,

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?

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

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

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.  

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.

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

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

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

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

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

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

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

[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

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

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

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

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

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

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)

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

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

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

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

[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

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

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,

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

[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

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 > wrote: On Jun 14, 2016, at 7:12 AM, L. Mihalkovic via swift-evolution >

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 > wrote: > If precedence between two operators is undefined, we cannot omit > parentheses. Hm.. Probably the

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 > wrote: On 15.06.2016 17:19, Sean Heber wrote: On Jun 15, 2016, at 7:21 AM, Vladimir.S via 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.

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

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

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 >

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

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

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

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 > > wrote: > >> Thanks Xiaodi. Interesting arguments there.

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

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 :

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

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

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

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?

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

Say you have the following code. There is a property on MyClass (‘y’) which is derived from other data via an instance method; Two-stage initialisation. class MySuperClass { init() {} } class MyClass : MySuperClass { let x : Int var y : String init(x: Int) {

Re: [swift-evolution] Nil coalescing operator precedence

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. And more, as I understand, in this mailing list we have no opportunity to move any IDE-related idea forward.

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

> On Jun 15, 2016, at 8:24 AM, Adrian Zubarev via swift-evolution > wrote: > > I guess you don’t understand that a so called proposal should have enough > details to explain the proposed behavior to someone who is not the author of > the proposal. You’re offering

Re: [swift-evolution] Nil coalescing operator precedence

I agree, precedence should be left for math operations that are known by all. Since this is not a normal operation, it should be left up to the developer to tell the computer what to do. The computer should not assume for you how to handle complex operations next to a nil coalescing operator.

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

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 about the keyword. But more importantly, it allows us to teach developers about the keyword in its

Re: [swift-evolution] Allow a typealias to be named after the corresponding type

> On 15 Jun 2016, at 09:35, Brent Royal-Gordon via swift-evolution > wrote: > >> public struct BinarySearchTree { >>typealias Node = Node >>var root: Node? >> } >> >> private class Node { } >> >> This code currently doesn’t compile because the

Re: [swift-evolution] Allow a typealias to be named after the corresponding type

> public struct BinarySearchTree { > typealias Node = Node > var root: Node? > } > > private class Node { } > > This code currently doesn’t compile because the Node typealias circularly > references itself. I’d like this syntax to just work, because this are the >

Re: [swift-evolution] Nil coalescing operator precedence

> On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution > wrote: > I don't know that it's feasible to warn on every use of operators with mixed > precedence. Doing so would effectively do away with the concept of precedence > at all, since everything would have to

Re: [swift-evolution] Nil coalescing operator precedence

> On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution > wrote: > I don't know that it's feasible to warn on every use of operators with mixed > precedence. Doing so would effectively do away with the concept of precedence > at all, since everything would have to

[swift-evolution] Allow a typealias to be named after the corresponding type

public struct BinarySearchTree { typealias Node = Node var root: Node? } private class Node { } This code currently doesn’t compile because the Node typealias circularly references itself. I’d like this syntax to just work, because this are the alternatives: - rename the

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

> On 15 Jun 2016, at 03:43, Jo Albright wrote: > > This is probably going to get lost in this massive chain. But I am going to > try to throw out a solution that I am not currently finding in this > conversation. > > There is a huge battle between removing and keeping keywords

[swift-evolution] Bitshift operators

While I was watching WWDC videos today, I noticed that there's a bit of annoying boilerplate in OptionSet specifications, and set out to get rid of it. Basically, what I'd like to do is this: extension OptionSet where RawValue: Integer { init(bit bits: RawValue...) {

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

I guess you don’t understand that a so called proposal should have enough details to explain the proposed behavior to someone who is not the author of the proposal. You’re offering is fine but a few unexplained lines of your gist wouldn’t make through a proposal review at all. I rather give a

Re: [swift-evolution] Arbitrary-sized integers

There is also a fairly robust implementation of arbitrary size integers here https://github.com/lorentey/BigInt/tree/master/Sources On Tue, Jun 14, 2016 at 10:02 PM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > 128-bit Ints have been discussed here a few weeks ago: >