Re: [swift-evolution] final + lazy + fileprivate modifiers

I personally think that removing file private by itself does not solve the issue. We either put it all up for change (permissions levels and axis systems... including unsubclassable outside the module by default, warnings about overriding a default method only define in the protocol) and we

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > wrote: > > I was reading this nice listing of Swift keywords > (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh > >

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 14 Feb 2017, at 07:06, Chris Lattner via swift-evolution > wrote: > > >> On Feb 12, 2017, at 12:35 PM, Xiaodi Wu wrote: >> >> _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't >> actually meaningful. > > Yes,

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 10:14 PM, Xiaodi Wu via swift-evolution > wrote: > > FWIW, you're not the first to propose these names. `public(open)` was > suggested during the `open` debate and rejected in favor of `open`. > `private(file)` was suggested during the

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 12:35 PM, Xiaodi Wu wrote: > > _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't > actually meaningful. Yes, for sure. That was carefully worded :-) > Here's why: > > If I see `fileprivate` and can understand that to mean

Re: [swift-evolution] Simplifying Default Access Modifiers

-1. Aside from everyone being used to current behavior that I personally do find more logical since it prevents you from accidently exposing internal members via public API, the migrator won't have a choice but to slap "internal" everywhere during migration and like there are now projects full

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

I think the biggest problem we're going to face with this one is changes to Objective-C are out of scope for Swift Evolution. Apple tend to be the ones in control of the development of new Objective-C features and compatibility because they control the compiler. That said, as a request to

[swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

Hi all, I don’t have a formal proposal written up yet, but in my continued quest to make better-annotated Objective-C code, I had an idea for bridging nil with primitives. Since in Objective-C we often use constant values to represent invalid values or nil, the most obvious being NSNotFound,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 8:14 AM, Adrian Zubarev > wrote: > > Is that assumption correct? > > // Module A > public protocol SQLiteValue { > init(statement: SQLiteStatement, columnAt index: Int) throws > func bind(to statement: SQLiteStatement, at index:

Re: [swift-evolution] Simplifying Access Using 'Hidden'

I think you hit the nail on the head in that the main issue is that our access control is mixing together several concepts (file-based, type-based, module-based, “open”). I don’t think anyone is actually reading the proposal though. Hidden is file based (not type based). It provides the

Re: [swift-evolution] Simplifying Access Using 'Hidden'

A battle shout of "you will need language lawyers to decide all we are building to avoid protected" ;)? Sent from my iPhone > On 13 Feb 2017, at 23:38, Xiaodi Wu via swift-evolution > wrote: > > The beauty of Swift 2's access modifiers was that they were based

Re: [swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

> On Feb 13, 2017, at 1:42 PM, Charles Srstka via swift-evolution > wrote: > > The following comment accompanies the declaration of the SubSequence > associated type in the Collection protocol: > > /// A sequence that represents a contiguous subrange of the

Re: [swift-evolution] [Pitch] Int / Int returns Quotient-Remainder Tuple

> On Feb 13, 2017, at 4:03 PM, Dan Stenmark via swift-evolution > wrote: > > > let (quotient, remainder) = 17 / 5 > print( "Q:\(quotient) R:\(remainder)" )// Idiot-proof! This would seem pretty reasonable to me if instead of a tuple, it returned a Rational

Re: [swift-evolution] [Pitch] Int / Int returns Quotient-Remainder Tuple

FWIW the new integers proposal defines a quotientAndRemainder method for FixedWidthInteger protocol: https://github.com/apple/swift-evolution/pull/598/files#diff-6ef84b28f2eaeb383265ccbb60650022R785

[swift-evolution] [Pitch] Int / Int returns Quotient-Remainder Tuple

(I get the feeling the response to this pitch will be overwhelming negative, but *deep inhale* here I go!) A common mistake I see programmers make is dividing two integers and expecting a floating-point result. This mostly affect new programmers who haven't learned about ALUs yet, but I

Re: [swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

The lines just after the current declaration show the desired version, which is waiting on two generics features that are in the pipeline: // FIXME(ABI)#98 (Recursive Protocol Constraints): // FIXME(ABI)#99 (Associated Types with where clauses): // associatedtype SubSequence : Collection

Re: [swift-evolution] Simplifying Access Using 'Hidden'

The beauty of Swift 2's access modifiers was that they were based around files and modules, explicitly rejecting types and scopes as units for determining visibility. It seems at base there's a group of people who reject that decision altogether. Hence, new `private`, proposals around `protected`,

Re: [swift-evolution] Simplifying Access Using 'Hidden'

What still strikes me as odd is that we now seem to have a plethora of visibilities, some of which do not provide for a given context, some of which seem to be looking for a context to justify their existence. Whatever it is called, I find the idea of a file scope visibility somewhat bizarre

Re: [swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

Because it would be recursive. which is not supported, I believe. protocol Foo { associatedtype Bar : Foo } Playground execution failed: error: MyPlayground.playground:2:20: error: type may not reference itself as a requirement associatedtype Bar : Foo ^ > On Feb

[swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

The following comment accompanies the declaration of the SubSequence associated type in the Collection protocol: /// A sequence that represents a contiguous subrange of the collection's /// elements. /// /// This associated type appears as a requirement in the `Sequence` /// protocol, but it is

Re: [swift-evolution] Simplifying Default Access Modifiers

The purpose of an implicit internal, at least a big one, is for progressive disclosure. It allows learners to write useful types (and indeed entire apps) before they learn about access levels. Of the existing access levels only internal fits the bill. I do agree that for optimal style internal

Re: [swift-evolution] Simplifying Access Using 'Hidden'

Hasn't "hidden" already been discussed? I could swear that it was already pitched and feedback given. In any case there's an ongoing discussion in another thread about removing new private; it seems distinctly poor form to abandon that and propose doing the exact opposite (removing old private)

Re: [swift-evolution] Simplifying Default Access Modifiers

It bears mentioning that it does _not_ formally work this way with fileprivate or private types. The default access level for members is always internal. This was a deliberate change I suggested for SE-0025 and is new for Swift 3. It's just also the case that the rules were relaxed to allow you to

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 13, 2017, at 11:40 AM, Zach Waldowski via swift-evolution > wrote: > > I still haven't been convinced by this. What are these incredibly large files > that people are dealing with, and why should a crucial feature of the > language be built around

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 13, 2017, at 12:40 PM, Zach Waldowski via swift-evolution > wrote: > > I still haven't been convinced by this. What are these incredibly large files > that people are dealing with, and why should a crucial feature of the > language be built around

Re: [swift-evolution] final + lazy + fileprivate modifiers

I still haven't been convinced by this. What are these incredibly large files that people are dealing with, and why should a crucial feature of the language be built around servicing anti patterns? Zachary On Mon, Feb 13, 2017, at 01:26 PM, William Sumner via swift-evolution wrote: > >> On

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution > wrote: > > > Fileprivate > > I started the discussion early during the Swift 4 timeframe that I regret the > change in Swift 3 which introduced a scoped private keyword. For me, it's not > worth the

Re: [swift-evolution] Strings in Swift 4

> On Feb 10, 2017, at 12:38 PM, Hooman Mehr via swift-evolution > wrote: > > >> On Feb 9, 2017, at 6:50 PM, Shawn Erickson > > wrote: >> >> >> >> On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr >

Re: [swift-evolution] Strings in Swift 4

> On 11 Feb 2017, at 18:33, Dave Abrahams wrote: > > All of these examples should be efficiently and expressively handled by the > pattern matching API mentioned in the proposal. They definitely do not > require random access or integer indexing. > Hi Dave, then I am

Re: [swift-evolution] Simplifying Access Using 'Hidden'

The problem with fileprivate is this: a new keyword was introduced for the original definition of private and a new definition of private was introduced that does not carry its weight in the context of Swift. Because of these two actions, the original definition of private was elevated to a

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution > wrote: > > Having loosely followed this discussion, the way I'm thinking of ‘closed’ is > as a modifier which would let you switch over something from outside the > module in which it is declared.

Re: [swift-evolution] [Pitch] consistent public access modifiers

Having loosely followed this discussion, the way I'm thinking of ‘closed’ is as a modifier which would let you switch over something from outside the module in which it is declared. From outside the declaring module: • A closed enum's cases can be exhaustively switched. • A closed protocol's

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution > wrote: > > I was reading this nice listing of Swift keywords > (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh > >

Re: [swift-evolution] final + lazy + fileprivate modifiers

> Personally I’d prefer if we all together with the core team set down > (virtually ^^) and: > > Fully re-evaluated all the access modifier mess and sketched a new future > oriented model on how this should have been regardless it’s breaking change > or not. +1 imho the current situation is an

Re: [swift-evolution] Simplifying Access Using 'Hidden'

I’ve never said, I liked the keyword by its name, however I do like its behavior which opens up flexible ways of creating some code dependency across the file. What I really meant is, that I feel like some people talk about fileprivate behavior as if it was new, which it is not. I’m feeling

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

No, you’re totally right there. The mentioned class keyword is the protocol constraint-keyword such as protocol X : >> class << { … }. Instead we would like to generalize AnyObject --  Adrian Zubarev Sent with Airmail Am 13. Februar 2017 um 17:34:18, Alejandro Martinez via swift-evolution

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> On 13 Feb 2017, at 17:21, Adrian Zubarev via swift-evolution > wrote: > > People talk always like “I never liked fileprivate” and I feel like some of > you forgot that fileprivate is not new to Swift. It’s the repainted private > from days before Swift 3. I

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

On class vs. AnyObject, probablt a dumb question but maybe worth clarifying, we don't pretend to change it in a class declaration right? like AnyObject A { var } apart from that looking forward for this! On Sun, Feb 12, 2017 at 8:32 PM, David Hart via swift-evolution

Re: [swift-evolution] [Pitch] consistent public access modifiers

Okay thanks, that makes now sense to me. So even if we refine public protocols from module A with a custom protocol in module B, there is no way we can conform any other type from module B to it, but we could conform existing types of module A to our refined protocols. That’s fine by me,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 10:14 AM, Adrian Zubarev via swift-evolution > wrote: > > Is that assumption correct? > > // Module A > public protocol SQLiteValue { > init(statement: SQLiteStatement, columnAt index: Int) throws > func bind(to statement:

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 10:19 AM, Karl Wagner wrote: > >> >>> >>> As I mentioned earlier, I don't think `closed` is a good keyword standing >>> alone. And I also think that, given that we have `open`, `closed` also >>> won't pair well with `public`—they sound like antonyms

Re: [swift-evolution] Simplifying Access Using 'Hidden'

People talk always like “I never liked fileprivate” and I feel like some of you forgot that fileprivate is not new to Swift. It’s the repainted private from days before Swift 3. I cannot recall anyone complaining about it that much. There were some people that forced the addition of a stricter

Re: [swift-evolution] [Pitch] consistent public access modifiers

> >> >> As I mentioned earlier, I don't think `closed` is a good keyword standing >> alone. And I also think that, given that we have `open`, `closed` also won't >> pair well with `public`—they sound like antonyms when they aren’t. > > The semantics I am proposing do have an inverse

Re: [swift-evolution] [Pitch] consistent public access modifiers

Is that assumption correct? // Module A public protocol SQLiteValue { init(statement: SQLiteStatement, columnAt index: Int) throws func bind(to statement: SQLiteStatement, at index: Int) throws } // Module B protocol SQLiteLoggable : SQLiteValue { var logDescription: String { get } }

Re: [swift-evolution] Simplifying Access Using 'Hidden'

Le 13/02/2017 à 15:15, Adrian Zubarev via swift-evolution a écrit : > –1 > > I won’t even try to be constructive on this one. It simply makes me > tired of all this access modifier mess. |open|, |closed|, |public|, > |internal|, now |hidden|, |fileprivate|, |directoryprivate|, >

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 8:24 AM, Brent Royal-Gordon > wrote: > > Sorry, I meant to jump in a lot earlier than this, but lost track of this > thread on my mental to-do list. I've read most of the thread, but I really > can't keep all the replies in my head at once, so I

Re: [swift-evolution] final + lazy + fileprivate modifiers

Personally I’d prefer if we all together with the core team set down (virtually ^^) and: Fully re-evaluated all the access modifier mess and sketched a new future oriented model on how this should have been regardless it’s breaking change or not. Communicated the corrected model with the

Re: [swift-evolution] final + lazy + fileprivate modifiers

Imho the only good "excuse" for "new private" are playgrounds. They are often forgotten in discussions, but afaics, Swift aims to be a good language for teaching, so there is some impact on its design. Of course, this is only speculation on motivation, as I wasn't involved in the decision to

Re: [swift-evolution] Simplifying Default Access Modifiers

Sent from my iPad > On Feb 13, 2017, at 3:02 AM, Jonathan Hull via swift-evolution > wrote: > > I would like to propose a change to the default access modifier within an > enclosing scope. The default for top level definitions would stay internal, > but anything

Re: [swift-evolution] final + lazy + fileprivate modifiers

Very good graphic. But it reinforces my opinion that it's currently more messy/complicated than I should be. It looks like an over-designed or designed-by-comitee model. I understand that private is useful, but not useful enough to warrant the increased complexity. My 2 cents. > On 13 Feb

Re: [swift-evolution] final + lazy + fileprivate modifiers

I actually made a small visual of how open vs. public should work constantly on twitter: https://twitter.com/DevAndArtist/status/829688528216924160 --  Adrian Zubarev Sent with Airmail Am 13. Februar 2017 um 15:20:10, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sorry, I meant to jump in a lot earlier than this, but lost track of this thread on my mental to-do list. I've read most of the thread, but I really can't keep all the replies in my head at once, so I apologize if some of this is duplicative. I agree with Jordan Rose that "closed enums" and

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sent from my iPad > On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution > wrote: > > >> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution >> wrote: >> >> I think I we can live with the original three: public, internal, and

Re: [swift-evolution] Simplifying Access Using 'Hidden'

–1 I won’t even try to be constructive on this one. It simply makes me tired of all this access modifier mess. open, closed, public, internal, now hidden, fileprivate, directoryprivate, moduleprivate, private, I might even forget some of the proposed access modifiers. Instead of adding new

[swift-evolution] Simplifying Access Using 'Hidden'

I wanted to propose a second simplification to the access system which would have several benefits: • It would remove ‘fileprivate’ • It would allow extensions to be in their own files • It would serve the needs of ‘protected’ without the complications involved in that

Re: [swift-evolution] [swift-users] for in? optionalCollection {

> This would be more easily done than new syntax, surely. … and it wouldn't increase the size of the language, so in general, I prefer library-solutions. I'd expect some pushback against the conformance, but my personal opinion is that the difference between an empty collection and a missing

Re: [swift-evolution] Simplifying Default Access Modifiers

> On 13 Feb 2017, at 14:24, Adrian Zubarev via swift-evolution > wrote: > > –1 for me. > > IMO the current behavior reduces all that internal noise in large projects, > where the author only makes a small part of the API public. Furthermore this > will break the

Re: [swift-evolution] Simplifying Default Access Modifiers

I think having a different default access for nested-scope adds a significant amount of cognitive complexity for not much value. I understand that structs as nested types are often used to communicate values outside the score (internal even), so public will be required often in these cases.

Re: [swift-evolution] Simplifying Default Access Modifiers

–1 for me. IMO the current behavior reduces all that internal noise in large projects, where the author only makes a small part of the API public. Furthermore this will break the implicit initializer on structs and make it implicitly public. Leaving the initializer as internal while everything

Re: [swift-evolution] Simplifying Default Access Modifiers

+1 I think this is actually what most people would intuitively expect anyway. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 13 Feb 2017, at 10:02, Jonathan Hull via swift-evolution

[swift-evolution] Simplifying Default Access Modifiers

I would like to propose a change to the default access modifier within an enclosing scope. The default for top level definitions would stay internal, but anything within a scope would by default have the same visibility as it’s enclosing scope. The main reason for this is