[swift-evolution] [Draft] Abolish IUO type

Hi, swift-evolution, Some colleagues and I have been working on a proposal to remove the ImplicitlyUnwrappedOptional type from Swift and replace it with an IUO decl attribute. Please have a look; I would

Re: [swift-evolution] Changing the curried static methods

> On Mar 14, 2016, at 1:09 PM, Joe Groff via swift-evolution > wrote: > > Note that there's a proposal open to flatten away the currying altogether: > > https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md > > I agree that it

Re: [swift-evolution] [Proposal] Add an API to Unmanaged to get the instance it holds "@guaranteed"

Updated proposal: use a method that accepts a closure to delineate the required guaranteed lifetime for which the assertion by the programmer holds. And, hopefully, no optimizer language speak. Add an API to Unmanaged to get the instance it holds @guaranteed Proposal: SE- Add an API to

Re: [swift-evolution] [META] Re: Mailman?

Le 15 mars 2016 à 12:52, Joe Groff via swift-evolution a écrit : > > I can't speak for the whole core team, but my preferences would be for > something that supports offline access well, like a mailing list, can sync > read and replied state across clients, like

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> On Mar 15, 2016, at 5:12 PM, Michel Fortin via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > Looks like a very good idea. Less wrapper code means less possibility of an > error, a less cluttered call stack when debugging, and faster

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

It's occurring to me, reading these recent posts, that we have two orthogonal systems of access levels. Swift's current access system is file based; a project file decides which files comprise a module, and the terms 'public', 'internal' and 'private' determine whether a property is accessible to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> What is your evaluation of the proposal? Looks like a very good idea. Less wrapper code means less possibility of an error, a less cluttered call stack when debugging, and faster compile times (because of less code). It looks like it'll work well for importing Apple headers. I'm a bit

Re: [swift-evolution] [META] Re: Mailman?

> On Mar 15, 2016, at 4:47 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Mar 15 2016, Joe Groff wrote: > >>> On Mar 15, 2016, at 3:27 AM, Adrian Kashivskyy >>> wrote: >>> >>> Joe, what are the

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

> On Mar 15, 2016, at 5:01 PM, Brent Royal-Gordon > wrote: > > extension Foo { > static var readableProperties: [String: (inout Foo) -> inout > Any] = [ > "readWriteProperty": { $0.readWriteProperty }, >

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

>> As long as we're doing computation in getters, it will make sense for that >> computation to raise errors. I don't think we can get around the need for >> `get throws`. > > It's debatable whether this is a good use of property syntax. The standard > library doesn't even use property syntax

Re: [swift-evolution] [Pitch] Make the first parameter in a function declaration follow the same rules as the others

on Tue Mar 15 2016, Jordan Rose wrote: > Thank you! I realized one other potential flaw in the data-gathering: > your search for "func foo(_ bar" will match both Objective-C methods > and C functions. I'm not sure CF should really be contributing to the > scores.

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

I think in the referenced example the new private would mean “class and extensions”, with file being the new private, which I think is confusing. My preference would be: public module (currently internal) protected (class and extensions) private protected is widely used to mean this in other

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

On Tue, Mar 15, 2016 at 2:33 PM Erica Sadun https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote: > And again, moving the access control modification to the end just doesn't > look > right to me or seem to enhance readability. :( I like Shawn’s proposal better for cases where there

Re: [swift-evolution] [META] Re: Mailman?

on Tue Mar 15 2016, Joe Groff wrote: >> On Mar 15, 2016, at 3:27 AM, Adrian Kashivskyy >> wrote: >> >> Joe, what are the Core Team's requirements for a possible forum software to >> start a discussion? >> >> The issues you expressed may

Re: [swift-evolution] swift-evolution Digest, Vol 4, Issue 35

on Tue Mar 15 2016, Patrick Smith wrote: > What if private was just removed, and instead just has a literal description > of where the member is accessible from? > > public var something: Int > module var something: Int > file var something: Int > scope var

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

Just wondering, wouldn't private be enougth for a class level declaration ? Not sure why we need a file baed one. *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury

Re: [swift-evolution] [Proposal] Add an API to Unmanaged to get the instance it holds "@guaranteed"

on Mon Mar 14 2016, John McCall wrote: >> In this example this would be for the lifetime for the value in x which >> extends to the lifetime of y. > > What if I return it or assign it to non-local memory? > > I feel like you’re trying to define this by optimizer behavior. > That’s not a

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

Bikeshedding! I would suggest three things: Make the access modifies annotations, i.e. they are spelt with an @ and use lower-camel case (which I think was the result of a previous Swift Evolution proposal, otherwise what ever was agreed for annotations) Move them to the end of the declaration

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

> On Mar 15, 2016, at 3:09 PM, Shawn Erickson wrote: > > > > On Tue, Mar 15, 2016 at 2:05 PM Erica Sadun > wrote: > I see two results on the gmane search and neither one seems to match what > you're talking about: >

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

On Tue, Mar 15, 2016 at 2:05 PM Erica Sadun wrote: > I see two results on the gmane search and neither one seems to match what > you're talking about: > > http://search.gmane.org/?query=Scoped=Shawn=gmane.comp.lang.swift.evolution=relevance > > Do you have a direct link to

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

I see two results on the gmane search and neither one seems to match what you're talking about: http://search.gmane.org/?query=Scoped=Shawn=gmane.comp.lang.swift.evolution=relevance Do you have a direct

Re: [swift-evolution] [swift-evolution-announce] Review: Import Objective-C Constants as Swift Types

FWIW, https://github.com/apple/swift-evolution still does not seem to reflect that status? > On Mar 7, 2016, at 2:37 PM, John McCall wrote: > >> On Mar 7, 2016, at 10:12 AM, Jeff Kelley >

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

See my email earlier in this thread about how to potentially deal with this leveraging fairly normal syntax we already have to support in swift. On Tue, Mar 15, 2016 at 1:34 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > Oddball cases: > > Global visibility, private

Re: [swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions

Thanks! ...that muddies the water for me more. :) Who are the users of these platform conditionals? I would assume most likely folks that are interfacing swift code with C code? In side of the Swift "sandbox" you should be isolated otherwise, right? If that is the case then the width of various

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

Oddball cases: Global visibility, private settable public private(set) var foo: String Global visibility, module settable public private(module set) var foo: String Module visibility, file settableprivate(module, file

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

I like the idea of public and then varying degrees of private (with the default being the most private). Public values are published outside of the build target. However, I have a question how we would express the concept of mixed property access levels, for instance with a private (to the

Re: [swift-evolution] Making `.self` After `Type` Optional

> On Mar 15, 2016, at 1:54 AM, Charles Constant wrote: > > +1 for junking the .self requirement > > On Wed, Mar 9, 2016 at 11:14 PM, David Hart via swift-evolution > > wrote: > I strongly agree for the

Re: [swift-evolution] [META] Re: Mailman?

You speak and I hear custom Google Wave setup still... ;) http://incubator.apache.org/wave/ Sent from my iPhone > On 15 Mar 2016, at 16:52, Joe Groff via swift-evolution > wrote: > > >> On Mar 15, 2016, at 3:27 AM, Adrian Kashivskyy >>

Re: [swift-evolution] [Proposal] Add Binary Search functions to SequenceType

> On Mar 15, 2016, at 6:49 PM, Haravikk wrote: > >> On 15 Mar 2016, at 15:48, Lorenzo Racca > > wrote: >> >> I already knew the impossibility of applying such a predicate as “$0 == 3” >> and I actually

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

> On Mar 15, 2016, at 11:28 AM, Jordan Rose wrote: > > What is a "debug build"? Is it one where testing is enabled? Where the > optimization level is -Onone? (We've talked about having an -Odebug and/or > -Oplayground at some point. Are those "debug builds"?) Is it one

Re: [swift-evolution] [Discussion] Referencing the Objective-C selector of property getters and setters

Maybe it would be nice if we preferred getters instead? Since I (making a totally unfounded assumption) assume that would be used more. But either way, I just wanted to show a quick example of the problem, I'm personally less worried about the exact syntax. -- Keith Smiley On 03/15, David Hart

Re: [swift-evolution] [Proposal] Add Binary Search functions to SequenceType

> On 15 Mar 2016, at 15:48, Lorenzo Racca wrote: > > I already knew the impossibility of applying such a predicate as “$0 == 3” > and I actually couldn’t quite figure out a solution. I thought so, and I don’t think there is a way to do it, my point was really just that

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

> On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution > wrote: > > I, too, prefer it to be more like this: > > public // unchanged > module // currently internal > internal // currently private > private // new hotness I like these best out of what’s

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

What is a "debug build"? Is it one where testing is enabled? Where the optimization level is -Onone? (We've talked about having an -Odebug and/or -Oplayground at some point. Are those "debug builds"?) Is it one where asserts are not removed? (This can technically be controlled independently of

Re: [swift-evolution] Two-for-Tuesday: Resettable Properties

Indeed. I actually mention that in my proposal draft. The core problem that I believe should be addressed is the mechanism that the Swift importer applies to `null_resettable` Objective-C properties. Whether or not Swift should support the feature is separate, but related, which is why I drafted

Re: [swift-evolution] [Proposal] Add Binary Search functions to SequenceType

This is something I've been working on as well. The issue I've been stuck on is how we define the predicate and match the definitions of lower_bound and upper_bound from C++. It seems to me that the focus should be on these implementations, since once we have these a simple binary_search follows.

Re: [swift-evolution] [Pitch] Make the first parameter in a function declaration follow the same rules as the others

> On Mar 15, 2016, at 10:41 AM, Jordan Rose via swift-evolution > wrote: > > Thank you! I realized one other potential flaw in the data-gathering: your > search for "func foo(_ bar" will match both Objective-C methods and C > functions. I'm not sure CF should

Re: [swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions

On Tue, Mar 15, 2016 at 9:51 AM William Dillon wrote: > The vast majority of special cases I’ve seen and written are due to the > size of Int, not a pointer per se. To clear up the confusion, how about we > rename bitwidth to intwidth or intsize? > > - Will > > > On Mar

Re: [swift-evolution] throws as returning a Result

> On Mar 15, 2016, at 6:39 AM, Yuta Koshizawa wrote: > > 2016-03-15 2:23 GMT+09:00 Joe Groff : >> >> Yeah, we extensively discussed adding a Result type internally, but >> ultimately couldn't justify it. The only real use case we could see in the >> wild

Re: [swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions

Before going any further, is it possible to hop over to the [DRAFT] Introducing a Debug Build Configuration Test, and pick up where Joe Groff just left off? Looks like things may not be as clear and orthogonal as I initially thought and it would help (a lot) if the discussion was all in one

Re: [swift-evolution] [META] Re: Mailman?

> On Mar 15, 2016, at 3:27 AM, Adrian Kashivskyy > wrote: > > Joe, what are the Core Team's requirements for a possible forum software to > start a discussion? > > The issues you expressed may be solved by not giving moderation access to > community members on such

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

On Tue, Mar 15, 2016 at 9:31 AM, Erica Sadun wrote: > I would like to update my draft proposal to introduce a test for debug > configurations using a public function > rather than a build configuration test. > > * Would the stdlib team be open to that? No objections from

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

I am really not in favor of the parametrized access keywords. To me, private(module) and private(file) seem redundant. Module already implies it is restricted to the module, and file already implies it is restricted to the file so the private keyword just seems unnecessary in my opinion.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

First link does not work. > On 15 Mar 2016, at 17:31, Douglas Gregor wrote: > > Hello Swift community, > > The review of SE-0044 “Import as Member" begins now and runs through March > 22, 2016. The proposal is available here: > >

Re: [swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions

I guess the fuzziness in my mind is when considering LP64, LLP64, etc. I believe swift attempts to avoid that by defining either 32 bit or 64 bit model. If that is universally the case then I think bitwidth is fine. If not then pointerwidth may be more correct. Those bridging to C would have to

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

I would like to update my draft proposal to introduce a test for debug configurations using a public function rather than a build configuration test. * Would the stdlib team be open to that? * What would be an appropriate name? `debugConfiguration`? `debugBuild`? `isDebugBuild`?

[swift-evolution] [Review] SE-0044 Import as Member

Hello Swift community, The review of SE-0044 “Import as Member" begins now and runs through March 22, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md

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

> To summarize the place we’d like to end up: > > - “public” -> symbol visible outside the current module. > - “internal” -> symbol visible within the current module. > - unknown -> symbol visible within the current file. > - “private” -> symbol visible within the current declaration (class, >

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

True. I was thinking to much in the content of the stdlib only but with a builtin you can get things optimized away. On Tue, Mar 15, 2016 at 9:22 AM Dmitri Gribenko wrote: > A function can absolutely can do that, if it is implemented using a > builtin known to the

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

You would likely want to ensure debug related code could be optimized away / or not be included in release builds. I am not sure how a function would achieve that. On Tue, Mar 15, 2016 at 9:15 AM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > > On Mar 14, 2016, at 2:04

Re: [swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions

These are excellent. I wouldn’t have chosen anything differently. Thanks, Erica! > On Mar 15, 2016, at 9:10 AM, Erica Sadun via swift-evolution > wrote: > > https://gist.github.com/erica/5a344b12bd989f6395c2 > >

Re: [swift-evolution] [Proposal] Add Binary Search functions to SequenceType

I’m not sure the documentation matches the .lowerBound() and .upperBound() behaviours accurately enough; it suggests that a bound will be found for a predicate “match”, however if my predicate is { $0 == foo } then these won’t actually work at all unless I get lucky and the middle element is a

Re: [swift-evolution] [Revision] SE-0034 - Disambiguating Line Control Statements from Debugging Identifiers

> On Mar 15, 2016, at 2:29 AM, Ben Rimmington wrote: > > >> On 14 Mar 2016, at 22:30, Dave Abrahams via swift-evolution >> wrote: >> >> on Fri Mar 11 2016, Chris Lattner wrote: >> >>> This provides syntax that

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

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

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] [Proposal] Add Binary Search functions to SequenceType

Hi all, Using the library for an app with wide sorted arrays I’ve found out that Swift doesn’t (yet) have binary search functions. Standing on the fact that C++, Java and .NET all have Binary Search functions in their standard libs, and given the notorious difficulty to create the algorithm

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

What would be the meaning of: 1/ scoped public 2/ scoped internal ? O. On Tue, Mar 15, 2016 at 2:59 PM, James Froggatt via swift-evolution wrote: > I didn't get any responses to my previous email (sorry if I came across as > impatient), but I would like to reiterate

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

I didn't get any responses to my previous email (sorry if I came across as impatient), but I would like to reiterate my suggestion of a ‘scoped’ keyword, since it seems like it would solve many of the issues people have with other solutions: private var foo scoped private var foo internal var

Re: [swift-evolution] throws as returning a Result

2016-03-15 2:23 GMT+09:00 Joe Groff : > > Yeah, we extensively discussed adding a Result type internally, but > ultimately couldn't justify it. The only real use case we could see in the > wild was for threading errors through CPS-inversion-style abstractions like > async

[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

Re: [swift-evolution] Thank you, bye for now.

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

[swift-evolution] Thank you, bye for now.

Dear colleagues I’ve been on swift-evolution for a few weeks now and I hope you liked at least some of my contributions and ideas. I won’t be on swift-evolution for some time, because there are other things I must do, which have higher priority. However, what also influenced my decision was

[swift-evolution] Thank you, bye for now.

Dear colleagues I’ve been on swift-evolution for a few weeks now and I hope you liked at least some of my contributions and ideas. I won’t be on swift-evolution for some time, because there are other things I must do, which have higher priority. However, what also influenced my decision was

[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] [META] Re: Mailman?

Joe, what are the Core Team's requirements for a possible forum software to start a discussion? The issues you expressed may be solved by not giving moderation access to community members on such a forum, much like in Mailman. Pozdrawiam – Regards, Adrian Kashivskyy > Wiadomość napisana

Re: [swift-evolution] Simplifying Function Parameter List (when calling)

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

Re: [swift-evolution] Add an ifPresent function to Optional

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

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

I agree with you Tino that we should not stop here, but I would break it down in smaller proposals that had the biggest breakage in the language but still could all fit into Swift 3. It is one of the last chances of being allowed to break source and ABI compatibility and we ought to make it

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

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

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

I agree that the current "private" is useful, and would rather keep everything as-is than remove this scope. I'm neutral on adding a new access level, but don't like the "private(file)"-syntax: The issues with properties could be solved (my preference would be "private (set) var x: Int"), but

Re: [swift-evolution] [Revision] SE-0034 - Disambiguating Line Control Statements from Debugging Identifiers

> On 14 Mar 2016, at 22:30, Dave Abrahams via swift-evolution > wrote: > > on Fri Mar 11 2016, Chris Lattner wrote: > >> This provides syntax that looks like an imperative function call that >> affects the logical source location at that

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

Hi, i think the current idea of adding additional specifier is wrong answer to original question/problem. The original problem was how to ensure that particular type is the only one in a given file. (making private effectively scoped private for that type). Solution should be to mark the whole

Re: [swift-evolution] [Discussion] Referencing the Objective-C selector of property getters and setters

Wouldn't it be: #selector(getter: NSString.lowercaseString)) To allow us to disambiguate getters and setters? > On 15 Mar 2016, at 06:09, Keith Smiley wrote: > > Another reasonable use case for this is with `UILocalizedIndexedCollation`. > For example with Swift 2.1:

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

How about - “public” -> symbol visible outside the current module. - “package or module” -> symbol visible within the current module. - internal -> symbol visible within the current file. - “private” -> symbol visible within the current declaration (class, extension, etc). ? Sent from my

Re: [swift-evolution] Making `.self` After `Type` Optional

I personally don't mind the trailing `.self` but it does seem strange that you need that, or not, based on the number of parameters. I definitely think it would be nice to unify this one way or the other. Another interesting consideration I ran into just today is trying to use `self` as a

Re: [swift-evolution] Making `.self` After `Type` Optional

> On Mar 10, 2016, at 9:19 AM, Joe Groff via swift-evolution > wrote: > > For (A), we should look at the new places a generic type might appear in > expressions: > > - By itself: > > let x = Foo< T > > bar() // following statement > > let y = Foo< T, U > > bar()