Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0048: Generic Type Aliases

> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md > • What is your evaluation of the proposal? I think it's a good idea that will make a lot of code clearer. I agree with the decision not to support additional constraints on the generic type.

Re: [swift-evolution] Rewrite imported C function signatures

> As you can observe, that old-style signature is highly error prone, does not > comply with swift guidelines, it is difficult to understand, etc. My opinion > is that there should be some syntax to rewrite the signature to avoid those > issues. For instance, a possible syntax could be: > >

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

I'll throw another suggestion into the ring: private (scoped access) public (file access) internal (module access) external (infinity and beyond) l8r Sean Sent from my iPad > On Mar 25, 2016, at 8:57 PM, Ross O'Brien via swift-evolution > wrote: > > The specific

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

I am sure that fileprivate is very useful. SE-0025 did not ask to remove it. On Fri, Mar 25, 2016 at 8:57 PM Ilya Belenkiy wrote: > all of these names (public, internal, private, local) have specific > meaning in the context of computer languages. I think that we should

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

all of these names (public, internal, private, local) have specific meaning in the context of computer languages. I think that we should use standard terms and give them the expected meaning. I did not do this originally with SE-0025 and suggested "scoped" because I thought that "private" could

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

On Fri, Mar 25, 2016 at 4:57 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > I honestly still think "public, internal, private, local" is a better > taxonomy.. It's true that "internal" and "private" aren't automatically > ordered relative to each other (and

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

> I do have a question. > > let x: Int! = 5 > let y = x > > let a = x ?? 1 // would this still work? > Or would it auto unwrapping always? meaning when .some `a = 5` or crash when > .none? > I am assuming that x is `Int?` that autounwraps. Just curious if autounwraps > only happen on

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

> Question: by what unit should > >for d in d0...d2 {} > > be iterating? Or should it be disallowed without a .striding(by: )? > > If the latter, NSDate might fall into the same bucket as floating types. Floating-point seconds (as NSTimeIntervals) are the natural Strideable.Stride,

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

You perfectly articulated what I've been trying to say and I agree 100% with your concerns. While we are in a minority, I think it's important to consider how the use of private in three keywords could become confusing to people learning the language and even just in a slight mental lapse

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

> 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 pointer just shuffle the problem around. Let me state it this way: You cannot write a fully-conforming C compiler

[swift-evolution] Request: Multiple Bool signatures

I am looking for examples of method/function signatures that use multiple Boolean flags, e.g. func generateContact(withAddress: Bool, withEmail: Bool, withPhone: Bool) -> Customer // not my code If you have app code or library code around that you can check, I would greatly appreciate if you

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

I’m pretty sure I only use them with `@IBOutlet` vars. One of the alternatives list is: • Remove IUOs completely. Untenable due to the prevalence of deferred initialization and unannotated Objective-C API in today's Swift ecosystem. What about leaving IUOs in the compiler, but disallowing them

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

On 25/03/2016 15:24, Chris Lattner via swift-evolution wrote: Hello Swift community, The review of "Abolish ImplicitlyUnwrappedOptional type" begins now and runs through March 30th. The proposal is available here:

Re: [swift-evolution] Binding generic types using a metatype parameter

> On Mar 25, 2016, at 12:39 PM, Joanna Carter > wrote: > > >> You'd need to extend Int to conform to the protocol for the cast to succeed. > > Ah, yes. And there lies the reason behind wanting to be able to extend Any - > avoiding having to extend every

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

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. Conceptually, whether a type can be advanced by some distance (guaranteed by Strideable) is orthogonal to whether a type has an obviously

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

Le 25 mars 2016 à 12:57, Tino Heth via swift-evolution a écrit : > > afaics this is the third time someone mentions that "file-private" is > uncommon — so I think it's time someone dissents: I'll do the same. There's many instances in my code where I rely on the

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

I use the file-private scope a fair amount for top-level constants that are intended to be used within the file, possibly across types. Doing things this way is more concise than embedding them as static members in the type itself since I don't need to qualify them with the name of the type at

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

This problem would be real only if this was new terminology in general (and even then, I'd say plain private means as private as it can be). But for most people for whom Swift is not the first programming language, it has a well defined meaning. This came up many times during discussions, and

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

I have types where I declare their members (some public, some private) and use extensions to provide the API implementations of protocols. These implementations use data that is not public to the type. A file-based access level is the only one that works for me. This is actually the common

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

> On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution > wrote: > > >> These are special cases — both file-private and module-private is something >> that is fairly unusual > > afaics this is the third time someone mentions that "file-private" is >

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

> These are special cases — both file-private and module-private is something > that is fairly unusual afaics this is the third time someone mentions that "file-private" is uncommon — so I think it's time someone dissents: That statement is at least subjective… right now, "file-private" is one

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

> On Mar 25, 2016, at 9:46, Ross O'Brien wrote: > > Well, several prominent voices seem to think that 'private' is "intuitively > obvious" when it refers to declaration-level scope, so I didn't argue that > point. I still happen to disagree; I would add

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

It doesn't solve the problem for me. "These properties are private." "To what?" "Just private" / "To the scope". They're also still awkward to read in code. I know we have lots of decl modifiers, but I've convinced myself we're not in Java's "public static void main" soup situation yet.

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

Well... how about we reverse the terms: call them 'privatetomodule' and 'privatetofile'. This is 'private(module)' and 'private(file)' but fitting the all lower-case style. It puts 'private' first (and when you use the keyword, 'private' is the bit you want to start with more than 'module' or

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

> On Mar 25, 2016, at 9:15 AM, Jordan Rose via swift-evolution > wrote: > > >> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution >> > wrote: >> >>> >>> On Mar 24, 2016, at 5:13 PM, Brent

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

on Thu Mar 24 2016, Xiaodi Wu wrote: > On Thu, Mar 24, 2016 at 4:18 PM, Dave Abrahams via swift-evolution > wrote: >> >> on Wed Mar 23 2016, Xiaodi Wu wrote: >> >>> So, in other words, you'd be satisfied with the

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

on Thu Mar 24 2016, Brent Royal-Gordon wrote: >> That >> would imply that floating types should not conform to Strideable, >> which raises the question of whether Strideable should be folded into >> the Integer protocol. > > Personally, I get a lot of mileage out

Re: [swift-evolution] Binding generic types using a metatype parameter

> On Mar 25, 2016, at 3:21 AM, Joanna Carter > wrote: > >>> extension PropertyType >>> { >>> private static func create() -> Property >>> { >>> typealias SelfType = Self >>> >>> return Property.init() >>> } >>> } >> >> Oops, that's definitely a bug. > >

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

> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution > wrote: > >> >> On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon >> wrote: >> >>> I think it does. `module` could mean many things related to how Swift >>> creates and consumes

Re: [swift-evolution] [Review] SE-0053 Remove explicit use of let from Function Parameters

* What is your evaluation of the proposal? +1. Since `let` is the default behaviour, and `var` usage has been deprecated, doesn’t make sense to have a keyword for this. * Is the problem being addressed significant enough to warrant a change to Swift? Yes. * Does this proposal fit well with the

[swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

Hello Swift community, The review of "Abolish ImplicitlyUnwrappedOptional type" begins now and runs through March 30th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md Reviews are an important part of the Swift

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

> On Mar 25, 2016, at 6:34 AM, John Siracusa via swift-evolution > wrote: > > Thanks for the explanation. I think this last part gets at the heart of my > question: Why isn't it important to highlight word boundaries in this case? > > On Fri, Mar 25, 2016 at 1:24

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

Huge +1 from me, but a character can't be valid for both function/variable names and operators because it'd break something in the compiler. Or at least I think that’s what I remember reading here. That doesn’t strictly rule out custom keywords, but those are probably part of the

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

I don’t think you'd even need a new operator. This works with Ints (haven’t tried anything else): extension Strideable { func stride(by by: Self.Stride) -> (last: Self, by: Self.Stride) { return (self, by) } } func ..< (first: T, rhs: (last: T, by: T.Stride)) -> StrideTo {

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

> Le 24 mars 2016 à 18:50, Brent Royal-Gordon via swift-evolution > a écrit : > >> Thirdly, as mentioned in the prior discussion it's certainly possible on >> some platforms to remap the memory page at address 0x0 and make it usable to >> userland code. Even if we

Re: [swift-evolution] Rewrite imported C function signatures

Well, it might be both an external annotation on C code and something specific within swift. The first is interesting when you have access to the C source code, but the later is good if you either don’t have access to the C source code, or the code (swift, objective-c, C, etc.) is autogenerated

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

Dave, I've been giving this approach a lot of thought (and have read everything I've been able to find that you've written on the matter several times) and am not convinced it will work. Implementing a lowerBound function is trivial with a unary operator. However, implementing an upperBound or

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

> Sure, but is that worth 7 to 9 extra characters at every single use site for > something that's actually pretty common? Yes. These are special cases — both file-private and module-private is something that is fairly unusual and should stick out a bit, so the length helps here. (Unless

Re: [swift-evolution] Rewrite imported C function signatures

Reposting my comment from that other thread: [...] it's more of an external annotation on C code, something that we don't currently support for user code. (My understanding is that they have it implemented for Apple frameworks.) Perhaps, with Swift 3 going Linux, with should expose the ability

Re: [swift-evolution] Promote "primitive" types to enums in extensions

> I think I may be similarly misunderstanding your proposal; your intention > then is to import the type as an enum with raw value (to facilitate the > conversion to/from the C code) but without exposing that raw value on the > Swift side? > > In that case I think I’m in favour. Me too. But

Re: [swift-evolution] Deprecating Trailing Closures

Agreed. Sent from my iPhone On Mar 25, 2016, at 07:44, Brent Royal-Gordon via swift-evolution wrote: >>>let foo = myArray >>>.filter { $0 & 1 == 1 } >>>.map { $0 + 1 } >>>.reduce(0) { $0 + $1 } >> >> This doesn’t really seem much neater

Re: [swift-evolution] Promote "primitive" types to enums in extensions

Yes, exactly, that’s a great summary of the proposal! > El 25 mar 2016, a las 12:25, Haravikk escribió: > > >> On 25 Mar 2016, at 09:56, Carlos Rodríguez Domínguez via swift-evolution >> wrote: >> >> The key of this proposal is that

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

I don't think that removing "switch(self)" would remove much boilerplate. I rather see the returns and cases as such. It is true your second approach is much more maintainable if you want to add or remove a case. However I think it suffers from readability and you cannot group related logic

Re: [swift-evolution] Binding generic types using a metatype parameter

>> extension PropertyType >> { >> private static func create() -> Property >> { >>typealias SelfType = Self >> >>return Property.init() >> } >> } > > Oops, that's definitely a bug. Excellent! I would also say that I have had a different error with… private static func create() ->

Re: [swift-evolution] Promote "primitive" types to enums in extensions

The key of this proposal is that the struct/class should come from outside any swift source code, that is, either imported by the compiler from C, or auto-generated from any external tool (i.e., a CoreData autogenerated class from a graphically specified data model). Of course, in well written

Re: [swift-evolution] Deprecating Trailing Closures

> On 25 Mar 2016, at 08:10, Haravikk via swift-evolution > wrote: > > >> On 24 Mar 2016, at 21:08, Howard Lovatt wrote: >> >> I use trailing closures all the time because I find the brackets too noisy, >> like ; at the end of a line is