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

[Brent Royal-Gordon via swift-evolution]

> 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. Typealiases should be just what it says in the name: aliases. It should 
not be possible to constrain a type with a typealias in a way you could not by 
substituting the same type name in directly.

In other words, I don't think this:

typealias ComparableArray = Array

Makes any more sense than this:

Array

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. The "proposed solution" examples are all quite sensible.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I haven't used any such languages enough to ever use an equivalent feature.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading.

-- 
Brent Royal-Gordon
Architechies

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

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

[Brent Royal-Gordon via swift-evolution]

> 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:
> 
> #mapsignature(socket(_:,_:,_:)->Int32)
> func socket(domain:SocketDomain, type:SocketType, protocol:SocketProtocol) -> 
> socket_t? {
>   let result = socket(domain.rawValue, type.rawValue, protocol.rawValue)
>   if result == -1 {
>   return nil
>   }
>   else{
>   return result
>   }
> }

What's wrong with just overloading it like this without hiding the original? 
That way you can start by directly porting (perhaps even mechanically 
converting) the code and later refine it to use the nicer Swift-style overload.

-- 
Brent Royal-Gordon
Architechies

___
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

[Sean Heber via swift-evolution]

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 meaning of 'public' and 'private' in programming languages 
> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and 
> Objective C; their 'public' is Swift's 'internal'. They have no equivalent to 
> Swift's 'public'. Swift has no equivalent to their 'private'.
> 
> Possibly my familiarity with other languages isn't broad enough, but this is 
> why I haven't understood the idea that Swift's use of 'private' is "right" or 
> "obvious". You learn Swift's meanings of these terms by coding in Swift, you 
> don't learn these meanings anywhere else first.
> 
> To use a hopefully recognised example: an American who wants 'chips' wants 
> what a Brit calls crisps; a Brit who wants chips wants what an American calls 
> french fries. Which meaning of 'chips' is more intuitive? Answer: the one you 
> grew up with.
> 
>> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> > all of these names (public, internal, private, local) have specific 
>> > meaning in the context of computer languages.
>> 
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's an 
>> access level. It usually has something to do with declaring variables inside 
>> a function.
>> 
>> For instance, Perl uses it to back up and restore a global variable. ML uses 
>> it to create a scope (roughly). Lua and Julia use it to declare lexical 
>> variables which are visible in enclosed scopes, which SE-0025's new access 
>> level is specifically *not* supposed to allow.
>> 
>> I don't know of any language where `local` is used as an access level. If 
>> you're aware of an analogous use in another language, I'd be interested to 
>> see it. But the examples I've found if anything *undermine* the suggestion 
>> that `local` would be a good keyword choice.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
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

[Ilya Belenkiy via swift-evolution]

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 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 not be changed. But since it can, we should definitely use
> it, and give it the meaning that most people expect.
>
>
> On Fri, Mar 25, 2016 at 7: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 maybe not even "local"), but they're
>> all adjectives (unlike "module" and "file"), and they're not awkward to
>> read or to use in conversation. But both the core team and the list
>> disagree, mainly because (a) it aligns 'private' more closely with other
>> languages, and (b) if you're not thinking about it, more restrictive is
>> better than less. (Both of which I agree are good ideas.)
>>
>> If we're not married to "private" being the most private access level, I
>> think there is a word that implies more privacy than "private": "secret".
>> Something that's private is often still shared with trusted people, but
>> something that's secret is very carefully protected indeed. "Three may keep
>> a secret, if two of them are dead."
>>
>> So then our four access levels would be:
>>
>> * public
>> * internal
>> * private
>> * secret
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
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

[Ilya Belenkiy via swift-evolution]

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 not
be changed. But since it can, we should definitely use it, and give it the
meaning that most people expect.

On Fri, Mar 25, 2016 at 7: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 maybe not even "local"), but they're
> all adjectives (unlike "module" and "file"), and they're not awkward to
> read or to use in conversation. But both the core team and the list
> disagree, mainly because (a) it aligns 'private' more closely with other
> languages, and (b) if you're not thinking about it, more restrictive is
> better than less. (Both of which I agree are good ideas.)
>
> If we're not married to "private" being the most private access level, I
> think there is a word that implies more privacy than "private": "secret".
> Something that's private is often still shared with trusted people, but
> something that's secret is very carefully protected indeed. "Three may keep
> a secret, if two of them are dead."
>
> So then our four access levels would be:
>
> * public
> * internal
> * private
> * secret
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
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

[Shawn Erickson via swift-evolution]

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 maybe not even "local"), but they're
> all adjectives (unlike "module" and "file"), and they're not awkward to
> read or to use in conversation. But both the core team and the list
> disagree, mainly because (a) it aligns 'private' more closely with other
> languages, and (b) if you're not thinking about it, more restrictive is
> better than less. (Both of which I agree are good ideas.)
>
> If we're not married to "private" being the most private access level, I
> think there is a word that implies more privacy than "private": "secret".
> Something that's private is often still shared with trusted people, but
> something that's secret is very carefully protected indeed. "Three may keep
> a secret, if two of them are dead."
>
> So then our four access levels would be:
>
> * public
> * internal
> * private
> * secret
>

I can support that and do like the word 'secret'. I am fine with keeping
'private' the same as it currently is even if it different from other
languages (since it already does).

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

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

[Brent Royal-Gordon via swift-evolution]

> 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 assignment like in `y = x`

I believe that, in this example, `y` is of type `Int?`, that is, a 
non-autounwrapped optional. An autounwrapped optional is only unwrapped if 
Swift cannot make the code type-check without unwrapping it.

-- 
Brent Royal-Gordon
Architechies

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

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

[Brent Royal-Gordon via swift-evolution]

> 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, 
but it's not particularly clear to me that you want 1 second to be a default 
stride. It's the default you would guess, but it's not actually a particularly 
useful default.

-- 
Brent Royal-Gordon
Architechies

___
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

[Brandon Knope via swift-evolution]

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 while coding: "wait what kind 
of private do I need?"

Brandon 

> On Mar 25, 2016, at 12:15 PM, 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 Royal-Gordon  
 wrote:
 
 I think it does. `module` could mean many things related to how Swift 
 creates and consumes modules. 
 `moduleprivate` combines something about access levels (public/private) 
 and scope (module), is easy to 
 Google, offers few "wrong" interpretations. By using a longer keyword, it 
 is less flexible in meaning and 
 more fixed in purpose.
>>> 
>>> Sure, but is that worth 7 to 9 extra characters at every single use site 
>>> for something that's actually pretty common? Is it worth the muddled mess 
>>> of an all-lowercase keyword with no obvious break, or the 
>>> attention-grabbing of a capital letter or an underscore?
>>> 
>>> `module` and `file` are not going to be obscure corners of the language. 
>>> Most people will probably learn about them at the same time they learn 
>>> about `public` and `private`. 
>>> 
>>> (Actually, if `module` continues to be the default, you probably won't see 
>>> it *that* often. You *will* see `file`, but that's the one that can't be as 
>>> easily confused with a declaration.)
>>> 
>>> Obviousness for new users is great, but you can take it too far. We call 
>>> the type `Int32`, not 
>>> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and 
>>> if we did, it's not clear the longer name would really be more obvious, 
>>> because it would be such a pain to read.
>> 
>> 
>> `moduleprivate` is the default value. I doubt it will get  used much if at 
>> all. I don't think `fileprivate` will get used much either
>> but in such cases, I think those seven extra letters are essential and 
>> documenting.
>> 
>> The two remaining public and private access levels are simple and 
>> intuitively obvious.
> 
> I'm going to say that I remain unhappy with these new names. I don't believe 
> that these won't get used, and I don't want them to feel awkward, 
> discouraged, or penalized when they do. The standard library, for example, 
> has in its style guide that all access control should be explicit, which is a 
> reasonable style to enforce. I also have a small concern that they won't be 
> easy to talk about: "this method is private" "wait, file-private or 
> module-private?" "neither, just private-private".
> 
> I realize these are all vague concerns, and I don't have something more 
> concrete—or a better alternative. "modulescoped" and "filescoped" would be 
> very literally accurate but (a) would force people to learn what "scoped" 
> means unnecessarily, and (b) aren't less awkward.
> 
> I agree with the concerns that just saying "file var foo" makes it sound like 
> there's one copy of the variable shared in the entire file, even when applied 
> to an instance property. I think there's a lot of value is making the access 
> control terms adjectives.
> 
> 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 maybe not even "local"), but they're all 
> adjectives (unlike "module" and "file"), and they're not awkward to read or 
> to use in conversation. But both the core team and the list disagree, mainly 
> because (a) it aligns 'private' more closely with other languages, and (b) if 
> you're not thinking about it, more restrictive is better than less. (Both of 
> which I agree are good ideas.)
> 
> Jordan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 for a 
platform which does not have some way to represent an invalid pointer. However 
C does it, Swift can do the same thing.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] Request: Multiple Bool signatures

[Erica Sadun via swift-evolution]

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 can share signatures with me or just generally comment on how 
often this pattern shows up in your daily life. I am specifically looking for: 
use of two or more separate Boolean parameters passed as flags. 

I would also welcome examples of option sets that replaced Boolean flags with a 
note as to whether that option set type is used elsewhere in your app.

I am following up to an action item that Brent Royal-Gordon mentioned on-list a 
while back but I want real supporting motivating code evidence before I move 
forward with a draft proposal.

Feel free to email me off-list. Thank you,  -- Erica

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

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

[Dave via swift-evolution]

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 unless the code 
is marked @objc (and treating them as `T?` in code that isn’t)? The stated 
motivation is "This proposal seeks to limit the adoption of IUOs to places 
where they are actually required, and put the Swift language on the path to 
removing implicitly unwrapped optionals from the system entirely when other 
technologies render them unnecessary.”… If they’re only intended to be used 
with C/Obj-C code, seems like that’s something that’d be possible for the 
compiler to enforce.

Having typed this all out, I’m starting to suspect it might be more complicated 
than what we have now… Hmm… I’ll hit send anyway, in case I’m wrong.

- Dave Sweeris

> On Mar 25, 2016, at 3:10 PM, Joseph Lord via swift-evolution 
>  wrote:
> 
> 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:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md
>> 
> 
> As I don't use IUO optionals I'm really fairly neutral on the proposal. I 
> just wanted to mention with the powerful tools we have for dealing with 
> optionals (optional, chaining, nil-coalescing, map, flatmap, guard, and let - 
> thanks Chris and team) it really would be quite feasible to do away with IUOs 
> completely. I don't think the community is ready for that yet so I'm not 
> proposing that course of action at this time but such a proposal wouldn't get 
> a universally hostile response.
> 
> Even force unwrap is something that I only do test code since flatmap was 
> added to the Standard Library (I used to have my own implementation of 
> flatmap with a force unwrap after a filter which was the only production use 
> I've put force unwrap to).
> 
> Joseph
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Joseph Lord via swift-evolution]

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:


https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md



As I don't use IUO optionals I'm really fairly neutral on the proposal. 
I just wanted to mention with the powerful tools we have for dealing 
with optionals (optional, chaining, nil-coalescing, map, flatmap, guard, 
and let - thanks Chris and team) it really would be quite feasible to do 
away with IUOs completely. I don't think the community is ready for that 
yet so I'm not proposing that course of action at this time but such a 
proposal wouldn't get a universally hostile response.


Even force unwrap is something that I only do test code since flatmap 
was added to the Standard Library (I used to have my own implementation 
of flatmap with a force unwrap after a filter which was the only 
production use I've put force unwrap to).


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

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

[Joe Groff via swift-evolution]

> 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 possible type likely to be used - mutter, 
> mutter ;-)
> 
> Is it worth putting i a formal proposal for the extension of Any, or has that 
> already been done?


You could. For this particular use case, though, I think we really just want a 
more direct way of using *.Type values as types themselves.

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

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

[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.

Conceptually, whether a type can be advanced by some distance (guaranteed
by Strideable) is orthogonal to whether a type has an obviously correct
increment when calling next() on its iterator. Thus, although *strides*
with Strideable bounds should obviously conform to Collection, Ranges that
conform to Collection should be constrained to types which imply that the
Range represents a countable set (as the mathematicians say) of numbers.

This distinction may come in handy for implementing strides that don't
accumulate error. Striding through a Range that represents a countable set
of elements shouldn't accumulate error and we can use what we already
have--i.e. increment the current value every iteration without inspecting
the value of the starting bound. Striding through a Range that represents
an uncountable set of elements definitely requires reckoning from the
starting bound every iteration.
On Fri, Mar 25, 2016 at 11:25 AM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> 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 following addition to
> >>> the standard library?
> >
> >>>
> >>> ```
> >>> extension Range where Element: Strideable {
> >>> func by(step: Element.Stride) -> StrideTo {
> >>> return startIndex.stride(to: endIndex, by: step)
> >>> }
> >>> }
> >>>
> >>> /*
> >>> example of usage:
> >>>
> >>> for i in (1..<10).by(2) {
> >>> print(i)
> >>> }
> >>> */
> >>> ```
> >>
> >>
> >> My current thinking is that:
> >>
> >> * `for x in 0.0..<3.0 {}` should probably be an error, because 1.0 is
> >>   not the obviously-right stride to use for non-integral numbers.  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.
> >
> > Well, maybe I'm missing something, but `for x in 0.0..<3.0 { }`
> > doesn't work as it is, and it doesn't seem to have anything to do with
> > Strideable. Rather, HalfOpenInterval doesn't conform to
> > SequenceType.
>
> True, but the plan is that:
>
> * Interval is going away
> * Range will only require that its Bound be Comparable
> * Ranges with Strideable bounds will conform to Collection
>
> (see the swift-3-indexing-model branch on GitHub)
>
> > I agree that `for x in 0.0..<3.0 { }` should continue not working, but
> > maybe let's keep floating point types conforming to Strideable :)
>
> Those two things are not compatible with the plan we're going to
> propose, as described above.
>
> >>
> >> * `for x in (0.0..<20.0).striding(by: 1.3) {}` should work without
> >>   accumulating error
> >>
> >
> > +1.
> >
> >> * `for x in 0..<3 {}` should work (obviously; that's the status quo)
> >>
> >> * `for x in (0..<20).striding(by: 2)` should work
> >>
> >> I think this might also handle the concerns that
> >>
> https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
> >> was trying to address.
> >>
> >> If I thought extreme concision was important for this application, I'd
> be
> >> proposing something like
> >>
> >>   for x in 0.0..<20.0//1.3 {}
> >>
> >> but personally, I don't, which is why I propose `.striding(by: x)`
> >> rather than simply `.by(x)`, the latter being more open to
> >> misinterpretation.
> >
> > Yeah, `.striding(by: x)` is pretty good.
> >
> >>
> >> --
> >> Dave
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
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

[Michel Fortin via swift-evolution]

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 
file-private behavior of Swift 2's private. Mostly this happens when I have a 
pair of coupled classes that are meant to be used together and that need to 
access internal details of each other. Most declarations can be scope-private 
without problem, but it's not that uncommon for me to take advantage of 
file-private. 

There's another aspect that is bothering me about these long names. It seems 
that everyone agrees that writing internal is a rare thing. Still, if you look 
at generated headers in Xcode you'll see internal everywhere, like this:

internal class ItemDataModel {
internal var storage: ItemStorage { get set }
internal let fileType: String
required internal init(fileType: String, storage: ItemStorage = default)
}

Since internal is the default, it's quite common in generated headers. 
"moduleprivate" wouldn't be an improvement for legibility here. But perhaps no 
one but me looks at generated headers for my own project.

-- 
Michel Fortin
https://michelf.ca

___
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

[Kevin Lundberg via swift-evolution]

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 the front.

Kevin Lundberg
ke...@klundberg.com



> On Mar 25, 2016, at 1:11 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> 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 
>> uncommon — so I think it's time someone dissents:
>> That statement is at least subjective… right now, "file-private" is one of 
>> three access levels, and I wouldn't dare to say either is more or less 
>> important than the others.
>> 
>> I never encountered situations with the current model where I missed a new 
>> "private"-level, and maybe "private" will become fairly unusual for the code 
>> I'll be writing.
>> 
>> In my existing code, the new meaning of private wouldn't break much, but the 
>> current meaning doesn't hurt me, and there are cases where "file-private" is 
>> needed.
>> 
>> None the less, I don't care much about the "ugliness" of "fileprivate" — but 
>> not because I perceive it as unusual:
>> I just expect that code completion will do the typing for me, so maybe "f" 
>> will be all I have to write (half the characters of "pr" ;-)
> 
> I cannot come up with a single use-case in my code for fileprivate and would 
> love
> some real world examples where you'd want visibility in a single file but not 
> across
> an entire module.
> 
> The fileprivate behavior has been a bugaboo of mine for some time, 
> particularly in 
> playground use. 
> 
> As far as I'm concerned, the control I really want is public,  intra-modular, 
> private, and 
> private-even-to-extensions-and-subclasses. I assume the latter is a no-go.
> 
> -- E
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
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

[Ilya Belenkiy via swift-evolution]

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
before the review I always replied that unfortunately the right name is
already taken.

I can see that it could take a little adjustment for some people, but for
me, even now, when I write private in code, I always have to remind myself
that it doesn't mean what I think it means. I am sure that there are a lot
of people who feel the same way (especially the ones not on this mailing
list). For them, it would only resolve an ambiguity and not introduce a new
one.

On Fri, Mar 25, 2016 at 12:29 PM Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> 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.
>
> Jordan
>
>
> On Mar 25, 2016, at 9:27 , Ross O'Brien 
> wrote:
>
> 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 'file').
> It's easier to use in conversation ("these properties are private to the
> file").
> Disadvantage: it adds 'to', so the words are even longer (but no longer
> than the parenthesised form would've taken).
>
> 'privatetofile extension Foo : BarConvertible { }'
>
> On Fri, Mar 25, 2016 at 4:15 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution <
>> swift-evolution@swift.org> 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 modules.
>> `moduleprivate` combines something about access levels (public/private)
>> and scope (module), is easy to
>> Google, offers few "wrong" interpretations. By using a longer keyword, it
>> is less flexible in meaning and
>> more fixed in purpose.
>>
>>
>> Sure, but is that worth 7 to 9 extra characters at every single use site
>> for something that's actually pretty common? Is it worth the muddled mess
>> of an all-lowercase keyword with no obvious break, or the
>> attention-grabbing of a capital letter or an underscore?
>>
>> `module` and `file` are not going to be obscure corners of the language.
>> Most people will probably learn about them at the same time they learn
>> about `public` and `private`.
>>
>> (Actually, if `module` continues to be the default, you probably won't
>> see it *that* often. You *will* see `file`, but that's the one that can't
>> be as easily confused with a declaration.)
>>
>> Obviousness for new users is great, but you can take it too far. We call
>> the type `Int32`, not
>> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and
>> if we did, it's not clear the longer name would really be more obvious,
>> because it would be such a pain to read.
>>
>>
>>
>> `moduleprivate` is the default value. I doubt it will get  used much if
>> at all. I don't think `fileprivate` will get used much either
>> but in such cases, I think those seven extra letters are essential and
>> documenting.
>>
>> The two remaining public and private access levels are simple and
>> intuitively obvious.
>>
>>
>> I'm going to say that I remain unhappy with these new names. I don't
>> believe that these won't get used, and I don't want them to feel awkward,
>> discouraged, or penalized when they do. The standard library, for example,
>> has in its style guide that all access control should be explicit, which is
>> a reasonable style to enforce. I also have a small concern that they won't
>> be easy to talk about: "this method is private" "wait, file-private or
>> module-private?" "neither, just private-private".
>>
>> I realize these are all vague concerns, and I don't have something more
>> concrete—or a better alternative. "modulescoped" and "filescoped" would be
>> very literally accurate but (a) would force people to learn what "scoped"
>> means unnecessarily, and (b) aren't less awkward.
>>
>> I agree with the concerns that just saying "file var foo" makes it sound
>> like there's one copy of the variable shared in the entire file, even when
>> applied to an instance property. I think there's a lot of value is making
>> the access control terms adjectives.
>>
>> I honestly still think "public, internal, private, local" is a better
>> taxonomy.. It's true that "internal" and 

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

[David Owens II via swift-evolution]

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 case for me. 

Sent from my iPhone

> On Mar 25, 2016, at 10:11 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> 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 
>> uncommon — so I think it's time someone dissents:
>> That statement is at least subjective… right now, "file-private" is one of 
>> three access levels, and I wouldn't dare to say either is more or less 
>> important than the others.
>> 
>> I never encountered situations with the current model where I missed a new 
>> "private"-level, and maybe "private" will become fairly unusual for the code 
>> I'll be writing.
>> 
>> In my existing code, the new meaning of private wouldn't break much, but the 
>> current meaning doesn't hurt me, and there are cases where "file-private" is 
>> needed.
>> 
>> None the less, I don't care much about the "ugliness" of "fileprivate" — but 
>> not because I perceive it as unusual:
>> I just expect that code completion will do the typing for me, so maybe "f" 
>> will be all I have to write (half the characters of "pr" ;-)
> 
> I cannot come up with a single use-case in my code for fileprivate and would 
> love
> some real world examples where you'd want visibility in a single file but not 
> across
> an entire module.
> 
> The fileprivate behavior has been a bugaboo of mine for some time, 
> particularly in 
> playground use. 
> 
> As far as I'm concerned, the control I really want is public,  intra-modular, 
> private, and 
> private-even-to-extensions-and-subclasses. I assume the latter is a no-go.
> 
> -- E
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
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

[Erica Sadun via swift-evolution]

> 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 
> uncommon — so I think it's time someone dissents:
> That statement is at least subjective… right now, "file-private" is one of 
> three access levels, and I wouldn't dare to say either is more or less 
> important than the others.
> 
> I never encountered situations with the current model where I missed a new 
> "private"-level, and maybe "private" will become fairly unusual for the code 
> I'll be writing.
> 
> In my existing code, the new meaning of private wouldn't break much, but the 
> current meaning doesn't hurt me, and there are cases where "file-private" is 
> needed.
> 
> None the less, I don't care much about the "ugliness" of "fileprivate" — but 
> not because I perceive it as unusual:
> I just expect that code completion will do the typing for me, so maybe "f" 
> will be all I have to write (half the characters of "pr" ;-)

I cannot come up with a single use-case in my code for fileprivate and would 
love
some real world examples where you'd want visibility in a single file but not 
across
an entire module.

The fileprivate behavior has been a bugaboo of mine for some time, particularly 
in 
playground use. 

As far as I'm concerned, the control I really want is public,  intra-modular, 
private, and 
private-even-to-extensions-and-subclasses. I assume the latter is a no-go.

-- E




___
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

[Tino Heth via swift-evolution]

> 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 of 
three access levels, and I wouldn't dare to say either is more or less 
important than the others.

I never encountered situations with the current model where I missed a new 
"private"-level, and maybe "private" will become fairly unusual for the code 
I'll be writing.

In my existing code, the new meaning of private wouldn't break much, but the 
current meaning doesn't hurt me, and there are cases where "file-private" is 
needed.

None the less, I don't care much about the "ugliness" of "fileprivate" — but 
not because I perceive it as unusual:
I just expect that code completion will do the typing for me, so maybe "f" will 
be all I have to write (half the characters of "pr" ;-)

Tino
___
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

[Jordan Rose via swift-evolution]

> 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 'privatetodeclaration' to 
> 'privatetomodule' and 'privatetofile', which would solve that conversational 
> point: "These properties are private to the declaration".
> 
> Alternatively: 'fileaccessible', 'moduleaccessible', 'declarationaccessible'? 
> (Does that confuse code accessibility with such things as UIAccessibility?)

Just on this point, yes, we've been advised to avoid the word "accessibility" 
in the past. We're deliberately using "access control" and "access"; 
"accessible" is kind of on the line.

(We're not using "visible" because whether something is "visible" depends on 
the use site, whereas access level is a characteristic of the declaration only.)

Jordan

___
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

[Jordan Rose via swift-evolution]

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.

Jordan


> On Mar 25, 2016, at 9:27 , Ross O'Brien  wrote:
> 
> 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 'file'). It's easier to 
> use in conversation ("these properties are private to the file").
> Disadvantage: it adds 'to', so the words are even longer (but no longer than 
> the parenthesised form would've taken).
> 
> 'privatetofile extension Foo : BarConvertible { }'
> 
> On Fri, Mar 25, 2016 at 4:15 PM, 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 Royal-Gordon >> > wrote:
>>> 
 I think it does. `module` could mean many things related to how Swift 
 creates and consumes modules. 
 `moduleprivate` combines something about access levels (public/private) 
 and scope (module), is easy to 
 Google, offers few "wrong" interpretations. By using a longer keyword, it 
 is less flexible in meaning and 
 more fixed in purpose.
>>> 
>>> Sure, but is that worth 7 to 9 extra characters at every single use site 
>>> for something that's actually pretty common? Is it worth the muddled mess 
>>> of an all-lowercase keyword with no obvious break, or the 
>>> attention-grabbing of a capital letter or an underscore?
>>> 
>>> `module` and `file` are not going to be obscure corners of the language. 
>>> Most people will probably learn about them at the same time they learn 
>>> about `public` and `private`. 
>>> 
>>> (Actually, if `module` continues to be the default, you probably won't see 
>>> it *that* often. You *will* see `file`, but that's the one that can't be as 
>>> easily confused with a declaration.)
>>> 
>>> Obviousness for new users is great, but you can take it too far. We call 
>>> the type `Int32`, not 
>>> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and 
>>> if we did, it's not clear the longer name would really be more obvious, 
>>> because it would be such a pain to read.
>> 
>> 
>> `moduleprivate` is the default value. I doubt it will get  used much if at 
>> all. I don't think `fileprivate` will get used much either
>> but in such cases, I think those seven extra letters are essential and 
>> documenting.
>> 
>> The two remaining public and private access levels are simple and 
>> intuitively obvious.
> 
> I'm going to say that I remain unhappy with these new names. I don't believe 
> that these won't get used, and I don't want them to feel awkward, 
> discouraged, or penalized when they do. The standard library, for example, 
> has in its style guide that all access control should be explicit, which is a 
> reasonable style to enforce. I also have a small concern that they won't be 
> easy to talk about: "this method is private" "wait, file-private or 
> module-private?" "neither, just private-private".
> 
> I realize these are all vague concerns, and I don't have something more 
> concrete—or a better alternative. "modulescoped" and "filescoped" would be 
> very literally accurate but (a) would force people to learn what "scoped" 
> means unnecessarily, and (b) aren't less awkward.
> 
> I agree with the concerns that just saying "file var foo" makes it sound like 
> there's one copy of the variable shared in the entire file, even when applied 
> to an instance property. I think there's a lot of value is making the access 
> control terms adjectives.
> 
> 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 maybe not even "local"), but they're all 
> adjectives (unlike "module" and "file"), and they're not awkward to read or 
> to use in conversation. But both the core team and the list disagree, mainly 
> because (a) it aligns 'private' more closely with other languages, and (b) if 
> you're not thinking about it, more restrictive is better than less. (Both of 
> which I agree are good ideas.)
> 
> Jordan
> 
> ___
> 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

[Ross O'Brien via swift-evolution]

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 'file').
It's easier to use in conversation ("these properties are private to the
file").
Disadvantage: it adds 'to', so the words are even longer (but no longer
than the parenthesised form would've taken).

'privatetofile extension Foo : BarConvertible { }'

On Fri, Mar 25, 2016 at 4:15 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution <
> swift-evolution@swift.org> 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 modules.
> `moduleprivate` combines something about access levels (public/private)
> and scope (module), is easy to
> Google, offers few "wrong" interpretations. By using a longer keyword, it
> is less flexible in meaning and
> more fixed in purpose.
>
>
> Sure, but is that worth 7 to 9 extra characters at every single use site
> for something that's actually pretty common? Is it worth the muddled mess
> of an all-lowercase keyword with no obvious break, or the
> attention-grabbing of a capital letter or an underscore?
>
> `module` and `file` are not going to be obscure corners of the language.
> Most people will probably learn about them at the same time they learn
> about `public` and `private`.
>
> (Actually, if `module` continues to be the default, you probably won't see
> it *that* often. You *will* see `file`, but that's the one that can't be as
> easily confused with a declaration.)
>
> Obviousness for new users is great, but you can take it too far. We call
> the type `Int32`, not
> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and
> if we did, it's not clear the longer name would really be more obvious,
> because it would be such a pain to read.
>
>
>
> `moduleprivate` is the default value. I doubt it will get  used much if at
> all. I don't think `fileprivate` will get used much either
> but in such cases, I think those seven extra letters are essential and
> documenting.
>
> The two remaining public and private access levels are simple and
> intuitively obvious.
>
>
> I'm going to say that I remain unhappy with these new names. I don't
> believe that these won't get used, and I don't want them to feel awkward,
> discouraged, or penalized when they do. The standard library, for example,
> has in its style guide that all access control should be explicit, which is
> a reasonable style to enforce. I also have a small concern that they won't
> be easy to talk about: "this method is private" "wait, file-private or
> module-private?" "neither, just private-private".
>
> I realize these are all vague concerns, and I don't have something more
> concrete—or a better alternative. "modulescoped" and "filescoped" would be
> very literally accurate but (a) would force people to learn what "scoped"
> means unnecessarily, and (b) aren't less awkward.
>
> I agree with the concerns that just saying "file var foo" makes it sound
> like there's one copy of the variable shared in the entire file, even when
> applied to an instance property. I think there's a lot of value is making
> the access control terms adjectives.
>
> 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 maybe not even "local"), but they're
> all adjectives (unlike "module" and "file"), and they're not awkward to
> read or to use in conversation. But both the core team and the list
> disagree, mainly because (a) it aligns 'private' more closely with other
> languages, and (b) if you're not thinking about it, more restrictive is
> better than less. (Both of which I agree are good ideas.)
>
> Jordan
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
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

[David Owens II via swift-evolution]

> 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 Royal-Gordon >> > wrote:
>>> 
 I think it does. `module` could mean many things related to how Swift 
 creates and consumes modules. 
 `moduleprivate` combines something about access levels (public/private) 
 and scope (module), is easy to 
 Google, offers few "wrong" interpretations. By using a longer keyword, it 
 is less flexible in meaning and 
 more fixed in purpose.
>>> 
>>> Sure, but is that worth 7 to 9 extra characters at every single use site 
>>> for something that's actually pretty common? Is it worth the muddled mess 
>>> of an all-lowercase keyword with no obvious break, or the 
>>> attention-grabbing of a capital letter or an underscore?
>>> 
>>> `module` and `file` are not going to be obscure corners of the language. 
>>> Most people will probably learn about them at the same time they learn 
>>> about `public` and `private`. 
>>> 
>>> (Actually, if `module` continues to be the default, you probably won't see 
>>> it *that* often. You *will* see `file`, but that's the one that can't be as 
>>> easily confused with a declaration.)
>>> 
>>> Obviousness for new users is great, but you can take it too far. We call 
>>> the type `Int32`, not 
>>> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and 
>>> if we did, it's not clear the longer name would really be more obvious, 
>>> because it would be such a pain to read.
>> 
>> 
>> `moduleprivate` is the default value. I doubt it will get  used much if at 
>> all. I don't think `fileprivate` will get used much either
>> but in such cases, I think those seven extra letters are essential and 
>> documenting.
>> 
>> The two remaining public and private access levels are simple and 
>> intuitively obvious.
> 
> I'm going to say that I remain unhappy with these new names. I don't believe 
> that these won't get used, and I don't want them to feel awkward, 
> discouraged, or penalized when they do. The standard library, for example, 
> has in its style guide that all access control should be explicit, which is a 
> reasonable style to enforce. I also have a small concern that they won't be 
> easy to talk about: "this method is private" "wait, file-private or 
> module-private?" "neither, just private-private".

I think this is a very important observation. Being able to talk about these 
levers is very important, especially in the context of teaching new people 
about the various levels of access control.

> I realize these are all vague concerns, and I don't have something more 
> concrete—or a better alternative. "modulescoped" and "filescoped" would be 
> very literally accurate but (a) would force people to learn what "scoped" 
> means unnecessarily, and (b) aren't less awkward.
> 
> I agree with the concerns that just saying "file var foo" makes it sound like 
> there's one copy of the variable shared in the entire file, even when applied 
> to an instance property. I think there's a lot of value is making the access 
> control terms adjectives.
> 
> 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 maybe not even "local"), but they're all 
> adjectives (unlike "module" and "file"), and they're not awkward to read or 
> to use in conversation. But both the core team and the list disagree, mainly 
> because (a) it aligns 'private' more closely with other languages, and (b) if 
> you're not thinking about it, more restrictive is better than less. (Both of 
> which I agree are good ideas.)

I agree 100% with this. 

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

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

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

[Dave Abrahams via swift-evolution]

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 following addition to
>>> the standard library?
>
>>>
>>> ```
>>> extension Range where Element: Strideable {
>>> func by(step: Element.Stride) -> StrideTo {
>>> return startIndex.stride(to: endIndex, by: step)
>>> }
>>> }
>>>
>>> /*
>>> example of usage:
>>>
>>> for i in (1..<10).by(2) {
>>> print(i)
>>> }
>>> */
>>> ```
>>
>>
>> My current thinking is that:
>>
>> * `for x in 0.0..<3.0 {}` should probably be an error, because 1.0 is
>>   not the obviously-right stride to use for non-integral numbers.  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.
>
> Well, maybe I'm missing something, but `for x in 0.0..<3.0 { }`
> doesn't work as it is, and it doesn't seem to have anything to do with
> Strideable. Rather, HalfOpenInterval doesn't conform to
> SequenceType. 

True, but the plan is that:

* Interval is going away
* Range will only require that its Bound be Comparable
* Ranges with Strideable bounds will conform to Collection

(see the swift-3-indexing-model branch on GitHub)

> I agree that `for x in 0.0..<3.0 { }` should continue not working, but
> maybe let's keep floating point types conforming to Strideable :)

Those two things are not compatible with the plan we're going to
propose, as described above.

>>
>> * `for x in (0.0..<20.0).striding(by: 1.3) {}` should work without
>>   accumulating error
>>
>
> +1.
>
>> * `for x in 0..<3 {}` should work (obviously; that's the status quo)
>>
>> * `for x in (0..<20).striding(by: 2)` should work
>>
>> I think this might also handle the concerns that
>> https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
>> was trying to address.
>>
>> If I thought extreme concision was important for this application, I'd be
>> proposing something like
>>
>>   for x in 0.0..<20.0//1.3 {}
>>
>> but personally, I don't, which is why I propose `.striding(by: x)`
>> rather than simply `.by(x)`, the latter being more open to
>> misinterpretation.
>
> Yeah, `.striding(by: x)` is pretty good.
>
>>
>> --
>> Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

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

[Dave Abrahams via swift-evolution]

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 of conforming NSDate to
> Strideable. 

I just recalled that Unsafe[Mutable]Pointers are also Strideable.  So
Strideable stays.

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.

> (Although obviously it ought to be using a float-friendly
> Strideable.)

-- 
Dave

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

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

[Joe Groff via swift-evolution]

> 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.
> 
> Excellent! I would also say that I have had a different error with…
> 
> private static func create() -> PropertyProtocol
> {
>   return Property() // without the explicit .init
>  ^ Non-associative operator is adjacent to operator of the 
> same precedence
>  ^ No'>' candidates produce the expected contextual result 
> type 'PropertyProtocol'
> }
> 
> So, it would seem that omitting the .init and using Self is interpreted 
> differently to using the .init and using Self. I'd hate you to solve one bug 
> just to find another for a very similar use case :-)
> 
>> Oops, my fault, this one is by design. Since we're calling through a dynamic 
>> type, our type system isn't able to express the result type 
>> `Property`, so we need to abstract it behind the PropertyProtocol.
> 
> Understood and somewhat expected. It's just that the error message is 
> somewhat distant from the error site and seemingly not connected.
> 
>>> Of course, after all this effort, I still have the problem of how to get 
>>> the Any.Type from the SubjectType property of a Mirror into a 
>>> PropertyType.Type.
>> 
>> That one's easy, at least—you can take `Any.Type` and use `as?` to cast it 
>> to `PropertyType.Type`.
> 
> You'd have thought so wouldn't you. But although this works fine…
> 
> let childMirror = Mirror(reflecting: child.value)
> 
> print(child.label, child.value, childMirror.subjectType)
> 
> let subjectType = childMirror.subjectType
> 
> print(subjectType)
> 
> if let propertyType = subjectType as? PropertyType.Type
> {
>   let property = PropertyFactory.createProperty(propertyType)
> 
>   print(property)
> }
> 
> … this doesn't…
> 
>   let intType: Any.Type = Int.self
> 
>   print(intType)
> 
>   if let propertyType = intType as? PropertyType.Type // this cast fails
>   {
> if var property = PropertyFactory.createProperty(propertyType) as? 
> Property
> {
>   property.value = 123
> 
>   print(property)
> }
>   }

You'd need to extend Int to conform to the protocol for the cast to succeed.

-Joe

>>> What would really make life easier here would be the ability to extend Any.
>>> 
>>> Any chance?
>> 
>> I think that'd be cool. Some people fear the power (and ensuing 
>> responsibility) that unleashes, though…
> 
> Of course there will always be abusers of power but, by not permitting it, 
> low level framework code becomes more difficult, onerous and obfuscated to 
> write. Framework writers have always had to bear far more responsibility - 
> think Cocoa ;-)
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 

___
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

[Jordan Rose via swift-evolution]

> 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 modules. 
>>> `moduleprivate` combines something about access levels (public/private) and 
>>> scope (module), is easy to 
>>> Google, offers few "wrong" interpretations. By using a longer keyword, it 
>>> is less flexible in meaning and 
>>> more fixed in purpose.
>> 
>> Sure, but is that worth 7 to 9 extra characters at every single use site for 
>> something that's actually pretty common? Is it worth the muddled mess of an 
>> all-lowercase keyword with no obvious break, or the attention-grabbing of a 
>> capital letter or an underscore?
>> 
>> `module` and `file` are not going to be obscure corners of the language. 
>> Most people will probably learn about them at the same time they learn about 
>> `public` and `private`. 
>> 
>> (Actually, if `module` continues to be the default, you probably won't see 
>> it *that* often. You *will* see `file`, but that's the one that can't be as 
>> easily confused with a declaration.)
>> 
>> Obviousness for new users is great, but you can take it too far. We call the 
>> type `Int32`, not 
>> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and if 
>> we did, it's not clear the longer name would really be more obvious, because 
>> it would be such a pain to read.
> 
> 
> `moduleprivate` is the default value. I doubt it will get  used much if at 
> all. I don't think `fileprivate` will get used much either
> but in such cases, I think those seven extra letters are essential and 
> documenting.
> 
> The two remaining public and private access levels are simple and intuitively 
> obvious.

I'm going to say that I remain unhappy with these new names. I don't believe 
that these won't get used, and I don't want them to feel awkward, discouraged, 
or penalized when they do. The standard library, for example, has in its style 
guide that all access control should be explicit, which is a reasonable style 
to enforce. I also have a small concern that they won't be easy to talk about: 
"this method is private" "wait, file-private or module-private?" "neither, just 
private-private".

I realize these are all vague concerns, and I don't have something more 
concrete—or a better alternative. "modulescoped" and "filescoped" would be very 
literally accurate but (a) would force people to learn what "scoped" means 
unnecessarily, and (b) aren't less awkward.

I agree with the concerns that just saying "file var foo" makes it sound like 
there's one copy of the variable shared in the entire file, even when applied 
to an instance property. I think there's a lot of value is making the access 
control terms adjectives.

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 maybe not even "local"), but they're all adjectives 
(unlike "module" and "file"), and they're not awkward to read or to use in 
conversation. But both the core team and the list disagree, mainly because (a) 
it aligns 'private' more closely with other languages, and (b) if you're not 
thinking about it, more restrictive is better than less. (Both of which I agree 
are good ideas.)

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

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

[Juan Ignacio Laube via swift-evolution]

* 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 feel and direction of Swift?
Yes.

* If you have you used other languages or libraries with a similar feature, how 
do you feel that this proposal compares to those?
N/A.

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
Quick reading of the proposal.


> On Mar 24, 2016, at 3:00 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "Remove explicit use of let from Function Parameters" begins 
> now and runs through March 27th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Chris Lattner via swift-evolution]

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 evolution process. All reviews 
should be sent to the swift-evolution mailing list at:
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager.


What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager



___
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

[Chris Lattner via swift-evolution]

> 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 AM, Chris Lattner  > wrote:
> Swift is an “opinionated” language and we find snake case to be ugly (YMMV of 
> course).
> 
> My attempt to summarize/rephrase the overall answer: "We used up all the 
> word-boundary-highlighting conventions that we don't find ugly on other parts 
> of the language, and we don't want to reuse any of them due to the potential 
> for conflict and confusion.”

I’m sorry for the confusion.  There are two issues: whether it is important to 
highlight word boundaries, and if so, what approach to use.  The first (and 
longer) part of the email was intended to justify why we don’t highlight word 
boundaries for keywords.  My overly snarky answer at the end was an attempt to 
answer why we don’t use snake case, but it wasn’t very effective :-)

Here is a different way to look at it: if we were going to highlight word 
boundaries, we would do it with camel case.  We use camel case in other places, 
and it has advantages over snake case (shorter identifiers), so we wouldn’t 
introduce a new way to do it.  

> As for snake case being ugly, my mileage does vary (obviously). Ithink 
> thereadability costofnot highlightingwordboundaries outweighsthe 
> aestheticconcerns. But them's the breaks when it comes to aesthetic issues, I 
> suppose. And in the grand scheme of things, at least the total number of 
> declaration modifiers should be small… :)

I understand the concern.  The short version of the argument is that multiword 
keywords and declmodifiers are rare , primitive, and used in idiomatic ways so 
the opportunity for confusion is low.

-Chris

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

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

[Dave via swift-evolution]

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 AFAIK-still-out-of-scope macro discussion.

- Dave Sweeris

> On Mar 24, 2016, at 9:24 AM, David Knothe via swift-evolution 
>  wrote:
> 
> Well I would love to be able to create and use my own keywords / alphanumeric 
> operators.
> Depending on the type of code you are writing, these may be more or less 
> helpful. The same is true for the 'step' keyword - maybe most people won't 
> ever use it - but I think there should certainly be a possiblity, be it a 
> concrete keyword built into the language or the possibility to create my own 
> ones.

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

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

[Dave via swift-evolution]

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 {
return first.stride(to: rhs.last, by: rhs.by)
}
func ...  (first: T, rhs: (last: T, by: T.Stride)) -> 
StrideThrough {
return first.stride(through: rhs.last, by: rhs.by)
}

Array(0..<10.stride(by: 2)) //[0, 2, 4, 6, 8]
Array(0...10.stride(by: 2)) //[0, 2, 4, 6, 8, 10]


> On Mar 24, 2016, at 3:40 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> If it's parentheses you want to avoid, you don't need a keyword to do that. 
> For example, I can make a stride operator `..+` in four lines like so:
> 
> ```
> infix operator ..+ { associativity left precedence 134 }
> func ..+ (left: Range, right: Element.Stride) 
> -> StrideTo {
> return left.startIndex.stride(to: left.endIndex, by: right)
> }
> 
> // example of usage:
> for i in 1..<10..+2 {
> print(i)
> }
> ```

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

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

[Dany St-Amant via swift-evolution]

> 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 don't currently support any such platforms, we 
>> shouldn't lock ourselves into a situation where we need to be able to do 
>> this.
> 
> I don't think this is mentioned in the proposal itself, but it came up in the 
> discussion.
> 
> The C standard requires that there be a "null" pointer address which can be 
> stored into any pointer but which can never actually be valid. It does *not* 
> require that the null pointer address be 0x0. Most platforms do use 0x0, and 
> clang doesn't support a non-0x0 null pointer, but this is not required by the 
> C standard.
> 
> I believe Swift should mimic this behavior. On platforms where 0x0 is a valid 
> address, Swift should not use 0x0 as the null pointer, but rather use some 
> other address which isn't valid (perhaps ~0x0). Pointer types should treat 
> this address as an unused value, which the enum machinery will then exploit 
> to represent Optional.none.

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.

Dany

> For now, this design should probably just be documented somewhere, perhaps in 
> a porting guide; actually implementing it is not really a priority.
> 
>> Finally, having nullable UnsafePointers currently is the only way from swift 
>> code to convert an UnsafePointer to an Int of its raw address, short of 
>> using another level of indirection:
>> 
>> let rawAddress: Int = UnsafePointer(nil).distanceTo(myPointer)
> 
> Given what I discussed about `nil` not necessarily being 0x0, this construct 
> is not necessarily valid anyway.
> 
> Besides, we *do* have a construct which converts between pointers and 
> integers without any semantic confusion about `nil`—and it even expresses 
> what it's doing more clearly than your `distanceTo` trick:
> 
>   unsafeBitCast(pointer, Int.self)
> 
>> I'm actually unsure of any other languages that have explicit nullability on 
>> a raw pointer type. (Maybe rust has it? I'm not very familiar with rust).
> 
> Apple variants of C, C++, and Objective-C now do. Actually, I believe they 
> had some nullability control even before the recent keywords through 
> __attribute__.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Carlos Rodríguez Domínguez via swift-evolution]

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 by an external 
tool (for instance, CoreData tools).

> El 25 mar 2016, a las 14:22, Andrey Tarantsov  escribió:
> 
> 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 to annotate external code to the users? And enum 
> importing could be a part of that.
> 
> A.
> 

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

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

[Jeff Hajewski via swift-evolution]

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
binarySearch function is, at least in my mind, a bit more difficult. The
reason is because with the unary predicate we only know if an element is
strictly less than the search value or greater than or equal to the search
value, whereas in the standard approach we can determine strictly greater
than as well as equivalence by swapping the inputs to the comp function.

For example, consider the set [2, 1, 5, 4]. If we want to search the set
using a unary predicate for 3, we would pass in the closure { $0 < 3  }. I
don't see how we can test for equivalence when all we know is "<" or ">=".
With the standard approach using a binary predicate of `{ $0 < $1 }` we can
use `{ $0 < 3 }` to get the lower bound and then `!{ 3 < $0 }` to get us to
equivalence (or in this case, to return `false`).

Of course, an easy solution around this is to change the definition of the
unary predicate to return a triple of values less/equal/greater. However,
this would either require an additional datatype to the library (which I
don't think is appropriate) OR require the user to increase the complexity
of their predicate function to return -1/0/1. I don't think either of these
are ideal or necessarily better than the standard approach of a value and a
binary predicate.

I really like the idea of the unary predicate approach, I just can't seem
to understand how it will work in practice. What am I missing here?
(hopefully not something completely obvious!)

Thanks!
Jeff

On Thu, Mar 24, 2016 at 4:52 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Tue Mar 15 2016, Nate Cook  wrote:
>
> >> On Mar 15, 2016, at 1:58 PM, Lorenzo Racca via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>> 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 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 your swift doc comments weren’t clear on that
> >>> point, then I went off at a bit of a tangent ;)
> >>>
> >> No problem! What I am trying to figure out here is how we should
> >> implement the lowerBound and upperBound functions. Should they
> >> exactly reflect their C++ counterparts?
> >> Anyway, it seems all of our implementations have the same problem,
> >> that they cannot be univocally called with any predicate whatsoever,
> >> (or at least it seemed to me during some tests with the
> >> implementations :) ), so I don’t really know how we should act. I am
> >> a little blocked.
> >> Does anyone have ideas on how that could work no matter what predicate
> is given? Especially, an upperBound() function, which is a little trickier.
> >
> > The key is to use a binary predicate (as used in sort and partition)
> > instead of a unary predicate. Then you can use the predicate as is for
> > lowerBound or with the arguments "reversed" for upperBound. The
> > methods would have a similar signature to indexOf—one that just takes
> > a value for comparable collections and one that takes a value and a
> > predicate.
>
> Having an overload that accepts a binary predicate is certainly a nice
> convenience, but the most general formulation takes a unary predicate
> that “partitions” the collection, i.e. returns false for the first N
> elements of the collection and returns true for the rest.
>
> IMO it's important to expose the unary predicate version.  Lots of
> times, the thing you want to compare against doesn't have the same type
> as the elements of the collection.  For example, you might have a
> collection of key-value pairs where you just want to compare against the
> keys, and you may not even be able to create an instance of the whole
> element.  For more on this, see
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1313.html
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
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

[Andrey Tarantsov via swift-evolution]

> 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 you're writing your entire app in module-private mode, in which case 
you won't use the modifier at all.)

I think Chris has explicitly stated that brevity for the sake of typing less is 
not a goal of Swift. There's software like Keyboard Maestro that I really 
recommend when typing code; just assign keyboard shortcuts (GW-BASIC-style) to 
the common keywords, and the length won't matter. 

> We call the type `Int32`, not 
> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`

Perhaps the new modifiers look worse to you than to me. "fileprivate var" reads 
just fine to my ears, exactly the right balance of length and brevity, and 
"file var" invokes wrong associations in my head, akin to being a static var, 
and generally feels way too short.

A.

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

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

[Andrey Tarantsov via swift-evolution]

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 to annotate external code to the users? And enum 
importing could be a part of that.

A.

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

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

[Andrey Tarantsov via swift-evolution]

> 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 perhaps not through the originally proposed syntax. I don't think this is 
an extension — 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 to annotate 
external code to the users? And enum importing could be a part of that.

A.


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

Re: [swift-evolution] Deprecating Trailing Closures

[David Sweeris via swift-evolution]

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 or more readable to me than:
>> 
>>let foo = myArray
>>.filter({ $0 & 1 == 1 })
>>.map({ $0 + 1 })
>>.reduce(0, { $0 + $1 })
> 
> I, on the other hand, cannot imagine how you would not see a difference 
> between the two. The paren-less form is *far* more readable to me; when you 
> put a parenthesis and a curly bracket next to each other, the curly bracket 
> disappears and I can no longer see that the expression is a closure.
> 
> Swift generally doesn't mandate any particular style. I think this is a good 
> time to continue that tradition.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Carlos Rodríguez Domínguez via swift-evolution]

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 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 
>> structures (as specified by Paul Ossenbruggen) we shouldn’t have any need 
>> for this proposal. However, many C structures make use of a raw type instead 
>> of an enum type, but specifying (through the associated documentation, not 
>> by any type enforcement) that only a set of enum values are allowed. 
>> Consequently, the resulting code making use of those structures becomes 
>> highly error prone, and, particularly in swift, very “old-style” code and 
>> difficult to understand for newcomers.
>> 
>> Again, I would like to highlight that my proposal intends to avoid as much 
>> as possible the use of enums’ raw values.
> 
> 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.

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

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

[Maximilian Hünenberger via swift-evolution]

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 inside computed properties. So the upcoming boilerplate is much 
bigger than the one you're about to remove.
In addition if you always use exhaustive switches the maintainability isn't 
that bad.

- Maximilian

Am 24.03.2016 um 02:22 schrieb Brent Royal-Gordon :

>> enum Suit: Int {
>>   case Hearts, Spades, Diamonds, Clubs
>> 
>>   static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
>> 
>>   var description: String {
>>   return match(self) {
>>   case .Hearts: "♥️"
>>   case .Spades: "♠️"
>>   case .Diamonds: "♦️"
>>   case .Clubs: "♣️"
>>   }
>>   }
>> 
>>   var isRed: Bool {
>>   return match(self) {
>>   case .Hearts, .Diamonds: true
>>   case .Spades, .Clubs: false
>>   }
>>   }
>>   }
> 
> This attacks the `return` boilerplate rather than the `switch` boilerplate. 
> That means that, while it helps in this case, it would not help with members 
> which have complicated logic or side effects. (And technically, the 
> boilerplate is still there—it's just a `match(self)` instead of a `switch 
> self`. I feel like they're orthogonal issues.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joanna Carter via swift-evolution]

>> 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() -> PropertyProtocol
  {
return Property() // without the explicit .init
   ^ Non-associative operator is adjacent to operator of the 
same precedence
   ^ No'>' candidates produce the expected contextual result 
type 'PropertyProtocol'
  }

So, it would seem that omitting the .init and using Self is interpreted 
differently to using the .init and using Self. I'd hate you to solve one bug 
just to find another for a very similar use case :-)

> Oops, my fault, this one is by design. Since we're calling through a dynamic 
> type, our type system isn't able to express the result type 
> `Property`, so we need to abstract it behind the PropertyProtocol.

Understood and somewhat expected. It's just that the error message is somewhat 
distant from the error site and seemingly not connected.

>> Of course, after all this effort, I still have the problem of how to get the 
>> Any.Type from the SubjectType property of a Mirror into a PropertyType.Type.
> 
> That one's easy, at least—you can take `Any.Type` and use `as?` to cast it to 
> `PropertyType.Type`.

You'd have thought so wouldn't you. But although this works fine…

  let childMirror = Mirror(reflecting: child.value)
  
  print(child.label, child.value, childMirror.subjectType)
  
  let subjectType = childMirror.subjectType
  
  print(subjectType)
  
  if let propertyType = subjectType as? PropertyType.Type
  {
let property = PropertyFactory.createProperty(propertyType)

print(property)
  }

… this doesn't…

let intType: Any.Type = Int.self

print(intType)

if let propertyType = intType as? PropertyType.Type // this cast fails
{
  if var property = PropertyFactory.createProperty(propertyType) as? 
Property
  {
property.value = 123

print(property)
  }
}

>> What would really make life easier here would be the ability to extend Any.
>> 
>> Any chance?
> 
> I think that'd be cool. Some people fear the power (and ensuing 
> responsibility) that unleashes, though…

Of course there will always be abusers of power but, by not permitting it, low 
level framework code becomes more difficult, onerous and obfuscated to write. 
Framework writers have always had to bear far more responsibility - think Cocoa 
;-)

Joanna

--
Joanna Carter
Carter Consulting

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

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

[Carlos Rodríguez Domínguez via swift-evolution]

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 structures 
(as specified by Paul Ossenbruggen) we shouldn’t have any need for this 
proposal. However, many C structures make use of a raw type instead of an enum 
type, but specifying (through the associated documentation, not by any type 
enforcement) that only a set of enum values are allowed. Consequently, the 
resulting code making use of those structures becomes highly error prone, and, 
particularly in swift, very “old-style” code and difficult to understand for 
newcomers.

Again, I would like to highlight that my proposal intends to avoid as much as 
possible the use of enums’ raw values.


> El 25 mar 2016, a las 6:42, Paul Ossenbruggen  escribió:
> 
> Why can’t you do this? No raw values required, except to initialize the enums.
> 
> struct Card {
> enum Suit : Int { case Hearts, Spades, Diamonds, Clubs }
> enum Rank : Int { case Ace, Two, Three, Four, Five, Six, Seven, Eight, 
> Nine, Jack, Queen, King }
> 
> let suit : Suit
> let rank : Rank
> 
> init?(suit: Int, rank: Int) {
> guard let suit = Suit(rawValue: suit),
>   let rank = Rank(rawValue: rank) else {
> return nil
> }
> self.suit = suit
> self.rank = rank
> }
> }
> 
> let firstCard = Card(suit: 0, rank: 3)
> let secondCard = Card(suit: 3, rank: 2)
> firstCard?.rank // returns Four
> secondCard?.suit // returns Clubs
> 
> 
> 
>> On Mar 24, 2016, at 11:18 AM, Carlos Rodríguez Domínguez via swift-evolution 
>> > wrote:
>> 
>> Well, I propose the “#” syntax to be consistent with other proposals that 
>> intend to provide compilation-related code. In this case, the proposal is 
>> just a way to provide an indication that a certain field within a struct or 
>> class should be enforced to be a value of a certain enum, not just a plain 
>> integer, by the compiler. Anyhow, I think many different sintaxis could be 
>> elaborated. For example, another possible syntax could imply reusing the 
>> typealias expression:
>> 
>> extension Card{
>>  typealias suit:CardSuit = suit:Int
>> }
>> 
>> However, I assume that using this syntax it should be possible to directly 
>> assign to the suit field both an integer or a CardSuit.
>>> b
> 
>>> On Thu, Mar 24, 2016 at 5:41 PM, Carlos Rodríguez Domínguez 
>>> > wrote:
>>> It is a common practice in C to assign to integer (int, int16, int64, etc.) 
>>> typed variables “constant" values declared in enums. In swift, it is in 
>>> fact possible to do that by using enums' “rawValue” property. When 
>>> importing structs from C into swift, we even get some fields declared with 
>>> an integer type, but expecting the assignment of a “constant” declared 
>>> inside an enum. Of course, this is error prone, it is “old-style” 
>>> programming and very confusing for newcomers. To solve this issue, my 
>>> proposal is to be able to create extensions that promote certain fields 
>>> within a class or struct to enums.
>>> 
>>> For instance, let’s take these sample C struct and enum:
>>> 
>>> struct Card {
>>> int suit;
>>> int rank;
>>> };
>>> 
>>> typedef enum {HEARTS, DIAMONDS, CLUBS, SPADES} CardSuit;
>>> 
>>> (Note: I understand that above code follows a bad programming practice, yet 
>>> it is widely common)
>>> 
>>> It should be imported into swift as follows:
>>> 
>>> struct Card {
>>> suit:Int
>>> value:Int
>>> }
>>> 
>>> enum CardSuit : Int {
>>> case Hearts, Diamonds, Clubs, Spades
>>> }
>>> 
>>> Now, I propose to be able to create an extension as follows:
>>> 
>>> extension Card {
>>> #enumvalue(suit:CardSuit)
>>> }
>>> 
>>> From this moment on, the suit field should only receive CardSuit values, 
>>> thus not requiring the use of raw values for assignments.
>>> 
>>> These extensions should also be of great interest for people using 
>>> CoreData, since it is not possible to declare enums in models. Therefore, 
>>> to declare enums, it is necessary to declare integer values, and then use 
>>> the “unsafe”, “unexpressive" approach explained before.
>>> 
>>> Note that the proposal intends to only support promotions from integer 
>>> values to enum values, but, for example, it could also be extended to 
>>> string values.
>>> 
>>> Finally, it could be appropriate to extend this proposal to redeclare 
>>> func’s signatures, in order to promote certain parameters to enum values.
>>> 
>>> Best,
>>> 
>>> Carlos.
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 

Re: [swift-evolution] Deprecating Trailing Closures

[Alex Blewitt via swift-evolution]

> 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 too noisy. The sort of code I use is:
>> 
>> let foo = myArray
>> .filter { $0 & 1 == 1 }
>> .map { $0 + 1 }
>> .reduce(0) { $0 + $1 } 
> 
> This doesn’t really seem much neater or more readable to me than:
> 
>   let foo = myArray
>   .filter({ $0 & 1 == 1 })
>   .map({ $0 + 1 })
>   .reduce(0, { $0 + $1 })
> 
> While they may add a small amount of noise, in the latter case the 
> parenthesis clarifies that each is a method, and what all of its arguments 
> are, and don’t use any custom syntax. Of course this assumes that .reduce() 
> would have an optional label on its closure argument.

On the other hand, I find the addition of the parenthesis makes it less 
readable than the one without. So please don't assume that what is equally 
readable for you applies to everyone else. 

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