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

One bonus it is a real word so autocorrect doesn’t fix it! I checked the dictionary and there are no negative or misleading meaning. It is a verb though, this is not being used as a verb in this case. http://www.dictionary.com/browse/interfile >

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

+1 -Thorsten > Am 30.03.2016 um 19:06 schrieb William Dillon via swift-evolution > : > > As long as you can still provide an overriding value to only one of the > defaulted parameters I probably wouldn't miss it. I would hate to have to > re-state the default

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

Good point! -Thorsten > Am 30.03.2016 um 23:40 schrieb Howard Lovatt via swift-evolution > : > > Implicit conversion complicates method overloading, e. g. if you have both > m(Int) and m(Double) which does m(0) call? Sure there are rules in other > languages that

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

+1 I am strictly against implicit conversions where data loss may happen. I am even against implicit conversions which are just expensive. With regards to the argument of counting on the developers intelligence I think that is a task for compilers just like type checking. -Thorsten > Am

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

Looks good to me. -Thorsten > Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution > : > >> On Mar 23, 2016, at 10:13 PM, Chris Lattner wrote: >> How about we continue this trend, and follow other existing Swift keywords >> that

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

On Mar 23, 2016, at 10:13 PM, Chris Lattner wrote: > How about we continue this trend, and follow other existing Swift keywords > that merge two lowercase words (associatedtype, typealias, etc), and use: > > public > moduleprivate > fileprivate >

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

One more possibility: public intermodule interfile private slightly longer but reads well. > On Mar 30, 2016, at 9:11 PM, Paul Ossenbruggen wrote: > > Ok speaking up, not a fan of fileprivate and moduleprivate because > > 1) very long > 2) doesn’t flow. > 3) not really

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

Ok speaking up, not a fan of fileprivate and moduleprivate because 1) very long 2) doesn’t flow. 3) not really private. I would be fine with filewide and modulewide and infile and inmodule with a slight preference for the infile and inmodule because it is shorter and conveys the same

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

> public > filewide > modulewide > private > > Don’t bother me because they seem to be part of the word. The way > “nationwide” does, they are made up words but intent is clear. I could live with filewide and modulewide instead of fileprivate and moduleprivate. I still prefer the latter

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

public filewide modulewide private Don’t bother me because they seem to be part of the word. The way “nationwide” does, they are made up words but intent is clear. OK violating my own statement of only having single words, but very short words. How about? public inmodule infile private I

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

> I personally like it because I consider the defaulted parameters to be “extra > add-ons” or the alternative to a “userInfo: [String: AnyObject]” pattern. > > I’d vote to leave things as-is unless it imposes a significant maintenance > cost on the compiler. Strong +1. Please leave it be, it's

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

> The problem with protected is that it provides virtually no protection at > all; you can trivially expose it in a derived class + > Extensions further dilute the enforceability of "protected", since anyone > would be able to use an extension to dump methods into a class's namespace > and

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

I'm missing those optional methods too, but protocol extensions sound like a better solution for this. (For those suggesting a separate protocol, consider UITableView. How many protocols would it take to model all the optional delegate methods as separate protocols? Certainly more than 10,

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

I wonder if perhaps it would be clearer if public was used for indicating something was published, even if it is published to a restricted set: public(#all)- expose outside the framework, shortened to public public(#module) - exposed module-wide, default if omitted public(#file)

Re: [swift-evolution] Still Missing: Fixed Decimal Numerical Type.

+CC Steve > On Mar 30, 2016, at 6:09 AM, Ted F.A. van Gaalen via swift-evolution > wrote: > > There is still no fixed decimal numerical type available in Swift! > > It should be implemented *as soon as possible* > because the fixed decimal type is really needed >

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

I know that it’s been suggested a while back, but what is/was the reasoning for rejecting: public module (same as internal in Swift 2.2) file (same as private in Swift 2.2) private It seems pretty simple, clear, and understandable. It doesn’t make itself very useful as search terms (module or

Re: [swift-evolution] Still Missing: Fixed Decimal Numerical Type.

> var depositPromille: Decimal(10,3) = -1234.56 > typealias Money = Decimal(20,2) There is no mechanism to parameterize types like this. (Specifically, you can only parameterize a generic type with types, not integers or other values.) That makes this a fairly large effort—certainly not

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

> On Mar 30, 2016, at 16:30, Brent Royal-Gordon wrote: > > While working that out, I also came up with a new suggestion for keywording > if we keep just these four levels and don't generalize `fileprivate` into an > "internal, with limitations" mechanism: > > * public

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

Is it reasonable to think that the hypothetical type promotion system that Chris Lattner was alluding to *might* result in function signatures that are subtly different than what you’re proposing? If so, I’d be very hesitant to introduce them into the standard library. Perhaps there could be a

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

> This is covered under the guise of being able to define a subtype > relationship between structs, which is something that I and many other people > would love to have, but it is outside the scope of Swift 3. Should this be on the "Commonly Proposed" list or in the "Out of Scope" list in the

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

> On Mar 30, 2016, at 15:20, Brent Royal-Gordon wrote: > >> Now, it is a very useful feature! Apple, of course, does this all the time >> with its "SPI". But I think the right form of the feature is to be able to >> tag a bunch of public declarations as "SPI" or

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

> Now, it is a very useful feature! Apple, of course, does this all the time > with its "SPI". But I think the right form of the feature is to be able to > tag a bunch of public declarations as "SPI" or "limited" or "limited to group > 'X'" or possibly even "limited to module 'X'", and then

[swift-evolution] [Draft] Adding a Build Configuration Import Test

The way I would like to see this spelled is: weak import UIKit //Only imports UIKit if it has been (non-weakly) imported elsewhere in the project #if imported(UIKit) // Do UIKit specific stuff here #endif As a framework author, this allows me to provide implementations for different

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

How about public, private, private(#file), and private(#module)? At a later date, if needed, private(S1, S3, ...) could be added. This would be a minimal change and not stop an extension in the future if requested. On Thursday, 31 March 2016, James Campbell via swift-evolution <

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

Ok, Dave, Developer, Steven, Howard Very interesting, thank you for the in depth responses! I see the points, I am still learning everyday. I drop my case, as they say. Kind Regards. TedvG > On 30.03.2016, at 23:38, Developer wrote: > > > > >> On Mar 30, 2016, at

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

> On Mar 30, 2016, at 12:57 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Thank you, Robert & Haravikk > Please allow me to respond in-line hereunder, thanks. > Ted. >> On 30.03.2016, at 16:15, Haravikk >

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

On Mar 30, 2016, at 1:35 PM, Ted F.A. van Gaalen via swift-evolution wrote: >> As long as data loss is an "unintended" effect of a certain class of >> coercions, I don't believe it deserves to be implicit. If you "know what >> you're doing", the preference so far

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

Implicit conversion complicates method overloading, e. g. if you have both m(Int) and m(Double) which does m(0) call? Sure there are rules in other languages that deal with this but they are complicated. So my call is that it is not worth the trouble. On Thursday, 31 March 2016, Ted F.A. van

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

> On Mar 30, 2016, at 4:35 PM, Ted F.A. van Gaalen > wrote: > > >> On 30.03.2016, at 20:29, Developer > > wrote: >> >> I believe section 6.3 of the ISO/C99 specification describes its integer >> promotion

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On Mar 30, 2016, at 3:11 AM, Jeremy Pereira via swift-evolution > wrote: >> On 25 Mar 2016, at 23:00, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> In the low level world, there is no such thing as an invalid address; both >>>

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

> On 30.03.2016, at 20:29, Developer wrote: > > I believe section 6.3 of the ISO/C99 specification describes its integer > promotion rules and Appendix J describes undefined behavior as a consequence > of integer and floating point coercion. I refer to these when I

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

I still would like to see this new for-loop statement be implemented in the next Swift version Examples: for v from 0.5 to 30.0 by 0.3// floating point types for v from 0 to 100 by 5 // Integer for v from 12.0 to -10.0 by -2 // Floating points backward the “by …”

[swift-evolution] Thoughts regarding readable INTENT of Loop keywords

Swift Control Flow using Loops One of Swifts strengths is clear, readable INTENT, conveyed by the languages Keyword tokens. For anyone new to programming, clear, readable intent, goes a long way in helping them master the language, by helping reduce logical/semantic errors caused by a

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

What about local for a file only or scope definition ?  Sent from Supmenow.com On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution" wrote: Ah, sorry! Those are all clear to me; it's the possibility of writing some other module name

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

Ah, sorry! Those are all clear to me; it's the possibility of writing some other module name there that would have the wrong implications. Jordan > On Mar 30, 2016, at 12:38 , Ross O'Brien wrote: > > Damn, and I thought it was clear all this time that

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

Damn, and I thought it was clear all this time that 'private(module)', or 'private(#module)', or 'moduleprivate', meant that the symbol is visible only inside the module. It's always been a suggested replacement specifier for 'internal'. On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via

Re: [swift-evolution] Feature proposal: Range operator with step

> On Mar 30, 2016, at 11:42 AM, Dave Abrahams wrote: > > > on Wed Mar 30 2016, Joe Groff wrote: > >>> On Mar 30, 2016, at 8:50 AM, Dave Abrahams wrote: >>> >>> >>> on Tue Mar 29 2016, Joe Groff wrote: >>> >> > On Mar 28, 2016, at 5:33 PM,

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Mar 30 2016, Joe Groff wrote: >> On Mar 30, 2016, at 8:50 AM, Dave Abrahams wrote: >> >> >> on Tue Mar 29 2016, Joe Groff wrote: >> > On Mar 28, 2016, at 5:33 PM, Brent Royal-Gordon wrote: >> Floating-point seconds

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Mar 29 2016, Xiaodi Wu wrote: > On Tue, Mar 29, 2016 at 7:48 PM, Dave Abrahams wrote: >> >> on Tue Mar 29 2016, Xiaodi Wu wrote: >> >>> Relatedly, while you're tackling this big revision: >>> > >>> I've tried to play around with what it would take to write a

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

> On Mar 30, 2016, at 9:59 AM, Joe Groff via swift-evolution > wrote: > > Many people are surprised when they find out defaulted parameters can be > reordered, unlike required arguments. This special case adds complexity to > the language, and runs against our

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

I believe section 6.3 of the ISO/C99 specification describes its integer promotion rules and Appendix J describes undefined behavior as a consequence of integer and floating point coercion. I refer to these when I speak of "rules". As long as data loss is an "unintended" effect of a certain

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

I think Matthew and Erica bring up good points here. When considering this change, it's worthwhile considering the effect it would have on the package manager (among the other cases that they may use privately). Currently, the package.swift's centerpiece is the initialization of the Package

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

One place where I believe argument re-ordering is useful is with memberwise arguments when you are initializing an instance. Order usually plays no significant role with these arguments which are in some sense similar to assignment statements (which are inherently re-orderable). In fact, I

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On Mar 30, 2016, at 3:11 , Jeremy Pereira via swift-evolution > wrote: > > >> On 25 Mar 2016, at 23:00, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> In the low level world, there is no such thing as an invalid address; both

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

Thank you, Robert & Haravikk Please allow me to respond in-line hereunder, thanks. Ted. > On 30.03.2016, at 16:15, Haravikk wrote: > > I’m in favour of implicit conversion for integers where no data can be lost > (UInt32 to Int64, Int32 to Int64 etc.), in fact I

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

> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon wrote: > >> If Scala style access modifiers were adopted for Swift then a private(file) >> modifier would also be necessary to give the current private functionality. > > I could imagine having these options: > >

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

> On Mar 29, 2016, at 18:28, Joe Groff wrote: > > >> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution >> wrote: >> >>> >>> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution >>> wrote: >>>

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

> On Mar 29, 2016, at 18:18, Joe Groff wrote: > > >> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution >> wrote: >> >> Well that would be true if we assume that protected would work that way. >> Considering that this: >> >>

[swift-evolution] Question about heterogeneous collections

Hi folks, I have an issue with using a heterogeneous array of objects conforming to a protocol - I want to write an extension on Array (or CollectionType) that applies only when Element : MyProtocol, but I can’t call methods in that extension from an instance of [MyProtocol] because "Using

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

Yes, absolutely this - I'd likely be fine with the order of them being strict, but being able to omit ones that I want to be defaulted is a must. l8r Sean Sent from my iPhone > On Mar 30, 2016, at 12:06 PM, William Dillon via swift-evolution > wrote: > > As long

Re: [swift-evolution] Feature proposal: Range operator with step

Sure, I could give it a shot this weekend. On Wed, Mar 30, 2016 at 12:03 PM Erica Sadun wrote: > > On Mar 29, 2016, at 11:26 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Tue, Mar 29, 2016 at 7:48 PM, Dave Abrahams >

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

I use this feature from time to time, but not usually intentionally. I appreciate that it doesn't force me to rearrange a bunch of parameters at call sites just because I happen to change the order of them in the function declaration, though. l8r Sean Sent from my iPhone > On Mar 30, 2016,

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

As long as you can still provide an overriding value to only one of the defaulted parameters I probably wouldn't miss it. I would hate to have to re-state the default value of all the parameters up to the one I want to change, though. - Will > On Mar 30, 2016, at 9:59 AM, Joe Groff via

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

> On Mar 30, 2016, at 10:59 AM, Joe Groff via swift-evolution > wrote: > > Many people are surprised when they find out defaulted parameters can be > reordered, unlike required arguments. This special case adds complexity to > the language, and runs against our

Re: [swift-evolution] Feature proposal: Range operator with step

> On Mar 29, 2016, at 11:26 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Mar 29, 2016 at 7:48 PM, Dave Abrahams > wrote: >> >> on Tue Mar 29 2016, Xiaodi Wu wrote: >> >>> Relatedly, while you're

[swift-evolution] [Pitch] Enforce argument order for defaulted parameters

Many people are surprised when they find out defaulted parameters can be reordered, unlike required arguments. This special case adds complexity to the language, and runs against our general trend of treating argument labels as a significant part of an API's name, and preferring a single way of

[swift-evolution] [Draft] Expand Document Markup for Mutating/Non-Mutating Cross References

Bringing this over to its own thread. Swift patterns encourage both functional and procedural implementations for many methods. This proposal makes it easier to connect those implementations through Swift doc markup. Thank you in advance for criticism, suggestions, and feedback. -- E Expand

Re: [swift-evolution] Feature proposal: Range operator with step

> On Mar 30, 2016, at 8:50 AM, Dave Abrahams wrote: > > > on Tue Mar 29 2016, Joe Groff wrote: > >>> On Mar 28, 2016, at 5:33 PM, Brent Royal-Gordon >>> wrote: >>> > Floating-point seconds (as NSTimeIntervals) are the natural

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

Associatedtype won’t be used nearly as often as these operators, I support the rational there but not in this case as it will be seen far more often. - Paul > On Mar 30, 2016, at 8:28 AM, Ilya Belenkiy wrote: > > I understand. The same is true about associatedtype. My

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Mar 29 2016, Joe Groff wrote: >> On Mar 28, 2016, at 5:33 PM, Brent Royal-Gordon >> wrote: >> Floating-point seconds (as NSTimeIntervals) are the natural >>> Strideable.Stride, but it's not particularly clear to me that you >>> want 1 second to be a

Re: [swift-evolution] Feature proposal: Range operator with step

> Am 30.03.2016 um 05:58 schrieb Xiaodi Wu via swift-evolution > : > > On Tue, Mar 29, 2016 at 9:57 PM, Joe Groff via swift-evolution > wrote: >> >>> On Mar 28, 2016, at 5:33 PM, Brent Royal-Gordon >>> wrote: >>>

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

I understand. The same is true about associatedtype. My iPhone just suggested it as a one word completion! I think the same will happen with these names. Chris Lattner already described the rationale in this thread, so I won't repeat it. I also originally wanted short names, but I think that we

Re: [swift-evolution] IUO type, treat nil as normal error, not fatal error

I think it would be an interesting to have an optional type that has throwing semantics on errors (I wonder if the behaviors proposal would allow something like that), but IMHO this should be something else than IUO. IUO is great for when you’re pretty darn sure a thing will never actually be

Re: [swift-evolution] Feature proposal: Range operator with step

Good points! -Thorsten > Am 25.03.2016 um 19:29 schrieb Xiaodi Wu via swift-evolution > : > > Ah, I think the conceptual muddle arises in the plan then. Specifically, I'd > argue that not all Ranges with Strideable bounds should conform to Collection. > >

Re: [swift-evolution] SetAlgebra naming update

> Am 30.03.2016 um 16:49 schrieb Dave Abrahams : > >> on Wed Mar 30 2016, Thorsten Seitz wrote: >> >> That's certainly an improvement, but why "formIntersection" instead of >> "intersect" (in analogy to "subtract")? > > 1. Consistency with union, which is more closely

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

The scala idea is interesting, has anyone used it extensively to understand how well it works in practice? Is it too fiddly? Do you spend too much time thinking about access levels. > On Mar 29, 2016, at 5:47 PM, Brent Royal-Gordon via swift-evolution > wrote: >

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Another alternative is to add a protocol extension with blank/harmless/default methods for things that are optional and always call 'em. On Wed, Mar 30, 2016 at 7:18 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > I’m not sure, why not just define an additional protocol

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

I understand the desire to wrap this up as it has gone on for a long time. I just don’t like the length and readability of the moduleprivate and fileprivate names (and how auto correct is always “fixing” it for me when I try to write about it). As I mentioned these will likely be used very

Re: [swift-evolution] SetAlgebra naming update

on Wed Mar 30 2016, Thorsten Seitz wrote: > That's certainly an improvement, but why "formIntersection" instead of > "intersect" (in analogy to "subtract")? 1. Consistency with union, which is more closely related than subtract. 2. "Intersect" actually has the wrong meaning as an imperative.

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

So, just so I'm understanding correctly what the new system would be (taking into account Chris Lattner's comments). A symbol specified as 'public' is visible outside the module. A symbol with no specifier, or specified as 'moduleprivate', is visible only within the module, but anywhere within

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

I’m in favour of implicit conversion for integers where no data can be lost (UInt32 to Int64, Int32 to Int64 etc.), in fact I posted a similar thread a little while ago but can’t find it; there’s something being done with numbers so this may be partly in the works. I definitely think that

[swift-evolution] [Proposal] Make optional protocol methods first class citizens

Hi, I find that optional protocol methods to be very useful. However, there is a caveat -- it needs to be mapped to @objc. This puts a set of limitations, such as: structures cannot be used as parameters as it does not map to objective-c. What do you think about removing the requirement of using

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

Hi Tino > On 30.03.2016, at 15:07, Tino Heth <2...@gmx.de> wrote: > > Sometimes, it's definitely desirable to have implicit conversion… but > sometimes, it's not, so I think the current behavior is good. > I guess most of us have a zero tolerance policy for warnings, so those would > be

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

I believe we will need another non-type access level if frameworks are ever divided into submodules. -DW > On Mar 30, 2016, at 7:13 AM, Ilya Belenkiy via swift-evolution > wrote: > > I am not sure if we will ever get another access level. If we do, great, but >

[swift-evolution] Missing initializers from/to FloatingPointType

While FloatingPointType can be initialized from various Int type variants, it seems to be missing an initializer from Double/Float. Similarly, there are no initializers from FloatingPointType to Double/Float. Is this intentional? I've tried implementing the following: //

[swift-evolution] Still Missing: Fixed Decimal Numerical Type.

There is still no fixed decimal numerical type available in Swift! It should be implemented *as soon as possible* because the fixed decimal type is really needed for applications working with financial and statistical data! E.g. var depositPromille: Decimal(10,3) = -1234.56 typealias Money

[swift-evolution] Implicit Type Conversion For Numerics Where Possible.

Currently, one has to deal with explicit conversion between numerical types, which in many cases is unnecessary and costing time to code for things that are quite obvious, and cluttering the source, making it less readable. Especially dealing all the time with often unavoidable intermixing of

[swift-evolution] IUO type, treat nil as normal error, not fatal error

Hi all, I want to discuss the Implicitly Unwrapped Optional Type. In Swift 1 and Swift2, when a variable declared as IUO type, its value should be non-nil. If its value is nil, it will crash the program when read the value. I believe it is better to let developer catch this event, treat it

Re: [swift-evolution] [Proposal] Factory Initializers

Yeah. I was thinking we would want to mirror the convenience initializer syntax, but I am completely ok with this as well. Honestly this is the syntax I first tried to use in convenience inits while learning swift, and I would love to see that migrate to something like this. My only worry

Re: [swift-evolution] [Proposal] Factory Initializers

If we are to enforce a different type signature for factory initializers vs required/convenience initializers (which would greatly simplify this issue), if I’m understanding correctly, there shouldn’t be a need to be able to “return” self.init(), right? Because you could do this instead:

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On 25 Mar 2016, at 23:00, Brent Royal-Gordon via swift-evolution > wrote: > >> In the low level world, there is no such thing as an invalid address; both >> 0x0 and ~0x0 are perfectly valid byte pointers. So using something else than >> 0x0 for Swift invalid

Re: [swift-evolution] [Proposal] Factory Initializers

Ah, good catch. Would that be confusing as to whether self.init() would lead to an infinite loop, or call the required initializer? Unlike convenience initializers, factory initializers might have the same signature as the required ones. > On Mar 30, 2016, at 2:52 AM, Jonathan Hull

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

That's the key point. "Protected" would increase the expressivity of the language by declaring intent and exposing cleaner public APIs. I don't think this idea should be dropped just because conscious hacks/decisions can workaround it, so big +1 for it. 2016-03-30 5:51 GMT+01:00 Thorsten Seitz

Re: [swift-evolution] [Proposal] Factory Initializers

Agreed. I would like to see what I was referring to as “stage 1” in this proposal, and we can (hopefully) add on a full solution over time. (I just wanted to make sure we considered those cases so we didn’t block future improvements) Looking at the proposal, my only contention would be that

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

On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution wrote: >> If Scala style access modifiers were adopted for Swift then a private(file) >> modifier would also be necessary to give the current private functionality. > > I could imagine having these

Re: [swift-evolution] [Proposal] Factory Initializers

Ultimately, while these are good points, I feel the full mechanism for class clusters belong in a separate proposal. The focus for this one I believe should be the underlying mechanism of factory initializers; should that be approved, then we can focus on adding additional features on top of

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

>> On Mar 29, 2016, at 13:54, Chris Lattner via swift-evolution >> wrote: >> >> On Mar 25, 2016, at 10:37 AM, Kevin Lundberg via swift-evolution >> wrote: >> I use the file-private scope a fair amount for top-level constants that are >>

Re: [swift-evolution] [Draft] SwiftPM: Adding development package as a dependency

On Wed, Mar 30, 2016 at 6:05 AM, James Richard wrote: > It's be nice to include a bit about how these interact with generated > Xcodeproj files. In Cocoapods those end up in a separate grouping, which I > find to be beneficial. > It should do the same as it does for other

Re: [swift-evolution] Feature proposal: Range operator with step

> We don't make String a sequence for similar reasons (though perhaps, by > analogy to String, there could be > `seconds`/`days`/`solarMonths`/`lunarMonths`/etc. views that are Strideable). Well, you managed to nerd snipe me pretty hard with this suggestion. First design: