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

First post to Swift evolution, please bear with me: the following is a bit wild, but something to think about for the future, maybe. Swift had three, and will now have four levels of scoping. In the future, might there be five? A scope that spans a limited set of modules, or a scope that only

[swift-evolution] Proposal to remove semicolons

A word of warning on this - I’ve just hit a case where an end of line semicolon is actually critical! If you’re debugging and need an early exit from a function, you add “return” somewhere in the middle of the code. But return can take an argument, so the compiler takes the argument from the

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

Very happy this is coming! I really like the details of this proposal as well. Just one thing - having the `VersionLocks` in `Packages/VersionLocks` seems like a bad idea to me. Couple of hurdles right away - for people who don't want to check in their dependencies, we can't just add `Packages`

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

Excellent point Brent. I was considering that this would have to be an exact match, I hadn't considered the need for an (x: Y) syntax. This probably should be considered in a future proposal though. The future proposal may make sense to be after existential types are explored, so that common

Re: [swift-evolution] [Draft] Abolish IUO type

> Let me play devil’s advocate: why not just get rid of implicit unwrapping > entirely? > > Apple’s Objective-C APIs have had plenty of time to be audited by now. Two reasons: 1. There are still a number of obscure Apple frameworks which have not been audited. 2. Not all imported code comes

Re: [swift-evolution] Potential Bug with Compiler in 2.1.1 and UnitTests

(bcc'ing swift-evolution, adding swift-users) This list is for language design discussion. If you have a bug, please file it at bugs.swift.org, or discuss it on swift-users. -Joe > On Mar 18, 2016, at 10:11 AM, James Campbell via swift-evolution > wrote: > > > I

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

> We decided to use a Swift-based format for the manifest because we believe it > gives developers the best experience for working with and describing their > project. The

Re: [swift-evolution] [proposal] Generic type aliases

> On Mar 16, 2016, at 5:02 PM, Chris Lattner wrote: > > On Mar 16, 2016, at 4:56 PM, Joe Groff > wrote: >>> We shouldn’t infer it the requirement. >>> >>> Rationale: I see this as analogous (in two ways) to why we don’t infer

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> On Mar 17, 2016, at 20:21 , Félix Cloutier wrote: > >> Fortunately, when a type has a single invalid value for which no operations >> are valid, Swift already has a solution: Optionals. > > To me, this makes it sound like dereferencing an unsafe pointer is unsafe > only

[swift-evolution] Potential Bug with Compiler in 2.1.1 and UnitTests

I have a class that specifies a initialiser taking any class that implements the protocol "ChatDatastore" I can use this fine in the functions for my test cases. However if I try to initialise it in a member either statically, lazily or even via a computed variable it shows an error stating

Re: [swift-evolution] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

> • What is your evaluation of the proposal? +1 > • Is the problem being addressed significant enough to warrant a change to > Swift? Yes, I’ve come across the issue a few times. > • Does this proposal fit well with the feel and direction of Swift? To me the solution seems a lot more

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

+1, this should be consistent. P.S. Finally somebody wrote an email using non-black Comic Sans.  Pozdrawiam – Regards, Adrian Kashivskyy > Wiadomość napisana przez Nicholas Maccharoli via swift-evolution > w dniu 17.03.2016, o godz. 09:27: > > ​As a follow-up to

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

Please… *please* let this lie. I understand that it will likely cause some specific cases to become more difficult but, on balance, it was a simplifying change. The syntax that we do have is clearer to those unfamiliar with programming idioms from other languages and people *are* familiar with

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> Le 16 mars 2016 à 15:36, Chris Lattner via swift-evolution > a écrit : > > Hello Swift community, > > The review of “Defaulting non-Void functions so they warn on unused results” > begins now and runs through March 21, 2016. The proposal is available here: > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> Perhaps we could add some kind of attribute to the type itself to allow for > selection between the two behaviours? imho that's a good direction — it's a pity that linking to other posts is so tedious ;-): I voted for something similar (change the setting for a whole module).

[swift-evolution] [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

Hello everybody. Please excuse this proposal’s poor formatting. I am very new to swift-evolution and don’t yet know how to do a formatted proposal. :) Proposal I am proposing to add an implement keyword to go with protocol method implementations like the override keyword. Motivation When

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

I agree with all of this; I don’t really know enough to comment on the specific implementation of a decimal type, but we definitely need something other than NSDecimal. I don’t know if it’s possible, but I think that tolerances should be able to take a percentage. For example, I could write

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

> Le 18 mars 2016 à 18:42, Rainer Brockerhoff via swift-evolution > a écrit : > > First draft towards a tentative pre-proposal: > https://gist.github.com/rbrockerhoff/6874a5698bb479886e83 > -- > > I propose, therefore, an internal data layout like this: > >

[swift-evolution] [proposal] Tail Call recursion attributes

Hello all, Introduction Tail call optimization can be a powerful tool when implementing certain types of algorithms. Unfortunately, Tail call optimization cannot be consistently used in Swift code. Developers cannot be sure that opportunities for this particular optimization to be applied are,

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

On 3/18/16 21:00, Dany St-Amant via swift-evolution wrote: > >> Le 18 mars 2016 à 18:42, Rainer Brockerhoff via swift-evolution >> a écrit : >> >> First draft towards a tentative pre-proposal: >> https://gist.github.com/rbrockerhoff/6874a5698bb479886e83 >> -- >>

Re: [swift-evolution] Attention Proposal Authors

To the best of my inspection, no changes from SE-0006 affect SE-0041 which recommends modifying protocol naming conventions for conversions or SE-0036 which provides for consistent leading dots across case member references. -- E > On Mar 18, 2016, at 11:17 AM, Dave Abrahams via

Re: [swift-evolution] [Draft] Expanding Build Configuration Tests for Simulator and Device targets

The reference for build configuration statements[1] has a list of platforms and operating systems. If that list is out of date, it's a documentation bug — so thanks for pointing that out! TSPL: Build configuration statements is missing Windows, FreeBSD, powerpc64, and powerpc64le If you

Re: [swift-evolution] Post-Evaluating proposal SE-0007 Remove C-style for-loops.

Hello Chris, Thank you, I know that and agree with you asking me to follow the usual path in Swift-evolution, of course. I am currently working on a proposal for a new for-loop variant: for v from v1 to v2 [by vstep] [tolerance vtol ] // in [] is optional here for numerical values.

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

Option 2i is the only one that neither discards nor makes up information, and it doesn't seem like 2i would impose a significant burden on users.​ ___ swift-evolution mailing list swift-evolution@swift.org

[swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

On Chris’s advice, I’ve spawned this into a new discussion topic, for which the base could be part of what I wrote in relation to SE-0007. Hello Patrick as I wrote: As a result of removing the classical for loop it is to be expected that lot of people might consider thinking twice about

Re: [swift-evolution] [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

I feel like this should be added to the "common proposal caveats", but please include a discussion of how this affects retroactive modeling (adding a protocol to a type you don't own that already has the appropriate members). Previous discussions about "implement" (usually "implements") usually

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

> On Mar 16, 2016, at 7:04 AM, Ross O'Brien via swift-evolution > wrote: > > A question about parsing: one of the perceived disadvantages to 'module' and > 'file' is how easily they might also be used as variable names. How easily > the parser can tell from

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> • What is your evaluation of the proposal? -1 This clearly makes me part of a small minority, but I doubt that the participants of this discussion are representative for all current and future users of Swift: Those who enjoy tinkering with the design of languages naturally strive for a

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

Le 15 mars 2016 à 9:49, Patterson, Jason via swift-evolution a écrit : > There were a few ideas here but I ultimately settled on a new `set?` > operator. The proposal then details the usage and ramifications of > such a change. For example, the getter would continue

Re: [swift-evolution] [Draft] Abolish IUO type

> On Mar 16, 2016, at 6:44 PM, Brent Royal-Gordon > wrote: > >> Let me play devil’s advocate: why not just get rid of implicit unwrapping >> entirely? >> >> Apple’s Objective-C APIs have had plenty of time to be audited by now. > > Two reasons: > > 1. There are still

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

*What is your evaluation of the proposal?* +1 *Is the problem being addressed significant enough to warrant a change to Swift?* Yes, the current annotation is present on most non-void functions, it adds a large number of lines to files that are properly annotated. *Does this proposal fit well

Re: [swift-evolution] [Draft] Abolish IUO type

On Mar 15, 2016, at 10:03 PM, Chris Willmore via swift-evolution wrote: > Hi, swift-evolution, > > Some colleagues and I have been working on a proposal > > to remove the

Re: [swift-evolution] [Draft] Abolish IUO type

One thing I've had bit me is the lack of some sort of confirmation, see this example. I have a objective-c method in a library like so: - (void)observe:(CallbackBlock)block; The CallbackBlock is a type def-ed block like so: typedef void (^CallbackBlock)(FDataSnapshot *snapshot); The parameter

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

> > > > >> We decided to use a Swift-based

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

> Very happy this is coming! I really like the details of this proposal as well. > > Just one thing - having the `VersionLocks` in `Packages/VersionLocks` seems > like a bad idea to me. Couple of hurdles right away > - for people who don't want to check in their dependencies, we can't just add

[swift-evolution] Pre-proposal: Safer Decimal Calculations

First draft towards a tentative pre-proposal: https://gist.github.com/rbrockerhoff/6874a5698bb479886e83 -- Pre-proposal: Safer Decimal Calculations Proposal: TBD Author(s): Rainer Brockerhoff Status: TBD Review manager: TBD Quoting the “The Swift Programming Language” book: “Swift adopts

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> On Mar 18, 2016, at 14:54, Russ Bishop wrote: > > >> On Mar 18, 2016, at 9:49 AM, Jordan Rose > > wrote: >> >> >>> On Mar 17, 2016, at 21:08 , Russ Bishop >> > wrote: >>>

Re: [swift-evolution] Fwd: [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

At the moment I'm considering Jordan's point: "(IIRC last time we got to "it's required if the member is in the same module, but allowed to be absent otherwise", which is fairly reasonable but probably still needs to be thought through.)" Taking my example: Int, Int16, Int32, Int64 etc. conform

Re: [swift-evolution] [Draft] Change IteratorType post-nil guarantee

> Current – post-nil unspecified > – Responsibility of the caller, needs to be aware of the API contract and > needs to track a bool and branch when relying on post-nil. > – Standard library currently has 3 occurrences of this being necessary. I got curious and decided to try to locate these. I

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

It looks like people finished the discussion for the best access level names. How should I update the proposal? On Mon, Mar 14, 2016 at 8:18 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Per Doug’s email, the core team agrees we should make a change here, but > would