Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Brent Royal-Gordon via swift-evolution]

> On Apr 8, 2017, at 9:12 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> `\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then 
> compute the "keypath" of that, which doesn't make sense, whereas `(\Foo.bar)` 
> makes it clear that the keypath expression is being separated from whatever 
> might come after it.


Backing this up: It's also worth remembering that this syntax is an edge case. 
The vast majority of key paths will not be ambiguous in a way that requires 
parentheses. Even if you think \(Foo.bar) would look better than (\Foo.bar), 
you should keep in mind that most of the time, you'll only need \Foo.bar, and 
the parenthesized syntax should be a natural extension of that. 

-- 
Brent Royal-Gordon
Sent from my iPhone

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Tony Allevato via swift-evolution]

Agreed—I think the parentheses have to go on the outside for this to work.
In this sense, `\Person.mother.age` is an expression that returns a keypath
type, with the idea that the parser is greedy and tries to take as many
dotted names that follow. The parentheses halt that if needed, but the
backslash needs to be bound to the type name for the part inside the
parentheses to be interpreted as a keypath.

`\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then
compute the "keypath" of that, which doesn't make sense, whereas
`(\Foo.bar)` makes it clear that the keypath expression is being separated
from whatever might come after it.


On Sat, Apr 8, 2017 at 6:12 PM Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

At one point I was leaning towards a trailing backslash.  Now I prefer
parenthesis.

If parentheses are used should the escape character be outside the
parenthesis or inside?  For example:

let x = (\Person.mother.age).valueType
let y = (\Person.mother.age.valueType)

vs.

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)


It is a subtle difference.




On Apr 8, 2017, at 5:47 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:


On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution <
swift-evolution@swift.org> wrote:

I love the idea of a leading and trailing backslash. It makes it much
easier to read, and handles the "but what if I want to access a property of
a KeyPath?" case really well.

For example, these two are clearly distinct:

  let x = \Person.mother.age\.valueType

  let y = \Person.mother.age.valueType\

I'm not sure why an 'age' object would have a 'valueType' property, but
this variant makes it easy to handle. Even in cases where no disambiguation
is required, having the trailing backslash makes it much easier to read as
I'm scanning through code.

-BJ


I think I'd prefer brackets for that case; in your first example that reads
to me like an escape of the period character, rather than "this is the end
of the key path". Brackets would make this consistent with escaping within
strings, like so:

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)

Which makes sense to me if you consider the backslash in this case being an
escape from normal type/variable access. Put another way, normally when you
type Person. you're telling Swift "access this type and look for static
methods/properties etc.", whereas when you "escape" it you're telling Swift
to *not* to do that, resulting in a key-path instead.

Maybe it's a stretch, it that makes sense logically to me, plus I think the
use of brackets just looks cleaner than another backslash.
___
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] Pitch: Compound name `foo(:)` for nullary functions

[Xiaodi Wu via swift-evolution]

On Sat, Apr 8, 2017 at 7:15 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> There were some opinions on Slack that we should simply change `foo` so
> that it can *only* refer to the nullary version.
>
>
> I think this is the right solution. Eventually we want to get to the point
> where parameter labels are part of a compound name; at that point, it'd be
> natural for a zero-argument function to just have its name be the base name.
>

With the sigil, this seems like a half-way solution. If we are to remove
base name-only lookups, the zero-argument function can be unambiguously
spelled `\foo()` and we can leave `\foo` to refer only to variables named
"foo" without a compound name.


> That'd be a source-breaking change,
>
>
> We can always support looking up members by base name only as an
> unprincipled shorthand. (But to tell the truth, I'd prefer to just break
> them.)
>
> but I'm also not sure whether it's even solve the problem — is it true you
> might still have both a function and a variable named foo accessible in the
> same scope?
>
>
> The simple version is illegal:
>
> Welcome to Apple Swift version 3.1 (swiftlang-802.0.41 clang-802.0.36).
> Type :help for assistance.
>   1> struct X { var x: Int; func x() {} }
> error: repl.swift:1:29: error: invalid redeclaration of 'x()'
> struct X { var x: Int; func x() {} }
> ^
>
> repl.swift:1:16: note: 'x' previously declared here
> struct X { var x: Int; func x() {} }
>^
>

No, but this is legal:

```
struct S {
var foo: Int = 42
func foo(_ bar: Int = 42) {
print("Hello, world!")
}
}
```

I have a sneaking suspicion there actually *are* circumstances where it's
> possible—but I think there probably shouldn't be.
>

There are legitimate designs that might make use of this (see the `ulp`
example above); whether it's wise or not is a different matter.


> Of the main options discussed—`foo(_)` vs `foo(:)`—I think the underscore
> is more accurate. It does conflict with pattern matching syntax, but I
> don't think you can match a (0-ary) function value against anything anyway,
> so I don't think that matters in practice.
>
> --
> 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] [pitch] Adding in-place removeAll to the std lib

[Richard Wei via swift-evolution]

+1. We better make sure `equalTo:` is consistent with the label in the 
`Sequence.all` proposal.

-Richard

> On Apr 8, 2017, at 19:41, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> +1. Perfect. Let's not bikeshed this and get it done!
> 
> 
> Sorry, I'm going to have to insist on bikeshedding.
> 
> `equalTo:` is kind of ugly and has no precedent in the standard library. 
> Similar APIs seem to either leave the parameter unlabeled or use `of:` (as in 
> `index(of:)`). I think unlabeled is probably the right answer here.
> 
> The main shortcoming I can see is that if you see:
> 
>   array.removeAll(3)
> 
> You might think `3` is either an index or a count. But neither of those 
> actually make sense:
> 
> * It can't be an index because then `All` would have no meaning. There's only 
> ever one thing at a given index. Besides, indices are almost always marked 
> with `at:` or another parameter label.
> * It can't be a count because `All` is already a count. What could "remove 
> all 3" possibly mean if the array doesn't happen to have three elements?
> 
> And this is only a problem if the value happens to be an integer. If it's 
> anything else, the type makes clear that this can't possibly be an index or 
> count; it must be an element.
> 
> (But if you really do think this is insurmountable, `removeAll(of: 3)` *is* 
> impossible to misinterpret and fits in better than `removeAll(equalTo:)`.)
> 
> (P.S. The existing oddness of `removeFirst(_:)` compared to `removeFirst()` 
> and `removeAll()` is why I proposed last year that it be renamed to 
> `removePrefix(_:)`, which matches the count-taking `prefix(_:)` method.)
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

At one point I was leaning towards a trailing backslash.  Now I prefer 
parenthesis.

If parentheses are used should the escape character be outside the parenthesis 
or inside?  For example:

let x = (\Person.mother.age).valueType
let y = (\Person.mother.age.valueType)

vs.

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)


It is a subtle difference. 




> On Apr 8, 2017, at 5:47 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution 
>> > wrote:
>> 
>> I love the idea of a leading and trailing backslash. It makes it much easier 
>> to read, and handles the "but what if I want to access a property of a 
>> KeyPath?" case really well.
>> 
>> For example, these two are clearly distinct:
>> 
>>   let x = \Person.mother.age\.valueType
>> 
>>   let y = \Person.mother.age.valueType\
>> 
>> I'm not sure why an 'age' object would have a 'valueType' property, but this 
>> variant makes it easy to handle. Even in cases where no disambiguation is 
>> required, having the trailing backslash makes it much easier to read as I'm 
>> scanning through code.
>> 
>> -BJ
> 
> I think I'd prefer brackets for that case; in your first example that reads 
> to me like an escape of the period character, rather than "this is the end of 
> the key path". Brackets would make this consistent with escaping within 
> strings, like so:
> 
>   let x = \(Person.mother.age).valueType
>   let y = \(Person.mother.age.valueType)
> 
> Which makes sense to me if you consider the backslash in this case being an 
> escape from normal type/variable access. Put another way, normally when you 
> type Person. you're telling Swift "access this type and look for static 
> methods/properties etc.", whereas when you "escape" it you're telling Swift 
> to not to do that, resulting in a key-path instead.
> 
> Maybe it's a stretch, it that makes sense logically to me, plus I think the 
> use of brackets just looks cleaner than another backslash.
> ___
> 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] [pitch] Adding in-place removeAll to the std lib

[Brent Royal-Gordon via swift-evolution]

> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> +1. Perfect. Let's not bikeshed this and get it done!


Sorry, I'm going to have to insist on bikeshedding.

`equalTo:` is kind of ugly and has no precedent in the standard library. 
Similar APIs seem to either leave the parameter unlabeled or use `of:` (as in 
`index(of:)`). I think unlabeled is probably the right answer here.

The main shortcoming I can see is that if you see:

array.removeAll(3)

You might think `3` is either an index or a count. But neither of those 
actually make sense:

* It can't be an index because then `All` would have no meaning. There's only 
ever one thing at a given index. Besides, indices are almost always marked with 
`at:` or another parameter label.
* It can't be a count because `All` is already a count. What could "remove all 
3" possibly mean if the array doesn't happen to have three elements?

And this is only a problem if the value happens to be an integer. If it's 
anything else, the type makes clear that this can't possibly be an index or 
count; it must be an element.

(But if you really do think this is insurmountable, `removeAll(of: 3)` *is* 
impossible to misinterpret and fits in better than `removeAll(equalTo:)`.)

(P.S. The existing oddness of `removeFirst(_:)` compared to `removeFirst()` and 
`removeAll()` is why I proposed last year that it be renamed to 
`removePrefix(_:)`, which matches the count-taking `prefix(_:)` method.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Brent Royal-Gordon via swift-evolution]

> On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> There were some opinions on Slack that we should simply change `foo` so that 
> it can *only* refer to the nullary version.

I think this is the right solution. Eventually we want to get to the point 
where parameter labels are part of a compound name; at that point, it'd be 
natural for a zero-argument function to just have its name be the base name.

> That'd be a source-breaking change,

We can always support looking up members by base name only as an unprincipled 
shorthand. (But to tell the truth, I'd prefer to just break them.)

> but I'm also not sure whether it's even solve the problem — is it true you 
> might still have both a function and a variable named foo accessible in the 
> same scope?


The simple version is illegal:

Welcome to Apple Swift version 3.1 (swiftlang-802.0.41 clang-802.0.36). 
Type :help for assistance.
  1> struct X { var x: Int; func x() {} }
error: repl.swift:1:29: error: invalid redeclaration of 'x()'
struct X { var x: Int; func x() {} }
^

repl.swift:1:16: note: 'x' previously declared here
struct X { var x: Int; func x() {} }
   ^

I have a sneaking suspicion there actually *are* circumstances where it's 
possible—but I think there probably shouldn't be.

Of the main options discussed—`foo(_)` vs `foo(:)`—I think the underscore is 
more accurate. It does conflict with pattern matching syntax, but I don't think 
you can match a (0-ary) function value against anything anyway, so I don't 
think that matters in practice.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

[Brent Royal-Gordon via swift-evolution]

> On Apr 6, 2017, at 9:51 AM, Nate Cook  wrote:
> 
> Thanks for all your feedback, Brent! One note on this item in particular—if 
> you specify a default argument for a throws/rethrows closure, you have to use 
> "try" at the call site even if the default closure argument doesn't throw. 
> Modules currently don't promise that default closure arguments don't throw, 
> and a default argument could change from non-throwing to throwing in a later 
> version of a library.
> 
> There's a bug tracking the issue here: https://bugs.swift.org/browse/SR-2979 
> 

Ugh. If that's the case, I'd probably provide a merge-handler-argument-less 
version instead of using a default argument. But I would have the first 
argument of both be unlabeled.

Actually, if we're going to do that, maybe the non-merge-handling version 
should be failable. That's the one semantic a `resolveConflict` method can't 
provide, and of course trapping on error is still just one force-unwrap away if 
that's what you want.

So that would give us:

init?(_ keysAndValues: S)
where S.Iterator.Element == (key: Key, value: Value)

init(_ keysAndValues: S, correctingConflictsBy 
resolveConflict: (Value, Value) throws -> Value) rethrows
where S.Iterator.Element == (key: Key, value: Value)

I think that pretty much covers everything you could possibly want to do about 
a conflict.

(I'd do a similar thing to `merged`, and perhaps have `merge` return a Bool, if 
you don't give them `resolveConflict` functions.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Haravikk via swift-evolution]

> On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution 
>  wrote:
> 
> I love the idea of a leading and trailing backslash. It makes it much easier 
> to read, and handles the "but what if I want to access a property of a 
> KeyPath?" case really well.
> 
> For example, these two are clearly distinct:
> 
>   let x = \Person.mother.age\.valueType
> 
>   let y = \Person.mother.age.valueType\
> 
> I'm not sure why an 'age' object would have a 'valueType' property, but this 
> variant makes it easy to handle. Even in cases where no disambiguation is 
> required, having the trailing backslash makes it much easier to read as I'm 
> scanning through code.
> 
> -BJ

I think I'd prefer brackets for that case; in your first example that reads to 
me like an escape of the period character, rather than "this is the end of the 
key path". Brackets would make this consistent with escaping within strings, 
like so:

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)

Which makes sense to me if you consider the backslash in this case being an 
escape from normal type/variable access. Put another way, normally when you 
type Person. you're telling Swift "access this type and look for static 
methods/properties etc.", whereas when you "escape" it you're telling Swift to 
not to do that, resulting in a key-path instead.

Maybe it's a stretch, it that makes sense logically to me, plus I think the use 
of brackets just looks cleaner than another backslash.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Xiaodi Wu via swift-evolution]

Incidentally--and I suppose I will have to repeat myself somewhere else in
the likely case that this is not seen by the people who are designing this
feature--using the sigil syntax `\foo()` nicely solves the nullary function
problem, but we get another ambiguity with the introduction of key paths
and function references using the same syntax:

Currently, it is possible to have a member `var foo` and another `func
foo(bar:baz:)` in the same type. There is no real necessity to forbid that,
though I doubt it would break too many people's code. (I did, however, once
suggest naming `FloatingPoint.ulpOfOne` to simply `FloatingPoint.ulp`,
which would have taken advantage of this rule.)

In such a scenario, `\foo` becomes ambiguous. It would be sufficient to say
that in such scenarios `\foo` is always interpreted as referring to `var
foo`, while `\foo(bar:baz:)` becomes the only way of writing a reference to
the function.


On Thu, Apr 6, 2017 at 9:59 AM, Ricardo Parada  wrote:

> Agree.
>
>
> On Apr 6, 2017, at 8:02 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously
> distinguished from foo(), I think that would be the only logical result.
>
>
> On Thu, Apr 6, 2017 at 00:40 Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Now that escaping with \ has been proposed for KeyPaths, this makes me
>> wonder whether it would be appropriate to use "\foo()" rather than
>> "foo(_)"/"foo(:)" ?  It still feels a bit strange, as \foo() looks like
>> escaping the *result* of a call.
>>
>>
>> On Sat, Feb 25, 2017 at 1:43 PM, David Hart  wrote:
>>
>>
>> On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I don't have a *good* answer for this, but I'll vote *against* 'foo(:)'
>> because that's what a lot of people think the name of 'foo(_:)' should be.
>> I'd rather be able to offer fix-its for that even when you have both
>> 'foo()' and 'foo(_:)' defined. I'd rather go with 'foo(_)' despite the tiny
>> ambiguity in pattern contexts.
>>
>> (I'm personally in favor of killing unapplied function references
>> altogether in favor of closures, on the grounds that they are overly terse,
>> make type-checking more complicated, and often lead to retain cycles. Then
>> we'd only need this for #selector, and it's perfectly unambiguous to use
>> 'foo()' there. But I wasn't planning to fight that particular battle now,
>> and it is rather annoying to require the 'as' in the meantime.)
>>
>>
>> It is potentially going to be hard to fight that battle. I think a lot of
>> functional/Haskell people love them and would be sad to see them go away (I
>> plead guilty). But it isn’t a well known part of the language so I don’t
>> think the general community would miss it.
>>
>> Jordan
>>
>>
>> On Feb 21, 2017, at 23:05, Jacob Bandes-Storch 
>> wrote:
>>
>> Evolutioniers,
>>
>> *Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to
>> disambiguate references to functions. (You might've used it inside a
>> #selector expression.) But there's currently no compound name for a
>> function with no arguments.
>>
>> func foo() {}  // no compound syntax for this one :(
>> func foo(_ bar: Int) {}  // foo(_:)
>> func foo(bar: Int) {}  // foo(bar:)
>> func foo(bar: String, baz: Double) {}  // foo(bar:baz:)
>>
>> Given these four functions, only the first one has no compound name
>> syntax. And the simple reference "let myfn = foo" is ambiguous because
>> it could refer to any of the four. A workaround is to specify a contextual
>> type, e.g. "let myfn = foo as () -> Void".
>>
>> I filed SR-3550  for this a while
>> ago, and there was some discussion in JIRA about it. I'd like to continue
>> exploring solutions here and then write up a formal proposal.
>>
>> To kick off the discussion, *I'd like to propose foo(:) for nullary
>> functions.*
>>
>> Advantages:
>> - the colon marks a clear similarity to the foo(bar:) form when argument
>> labels are present.
>> - cutely parallels the empty dictionary literal, [:].
>>
>> Disadvantages:
>> - violates intuition about one-colon-per-argument.
>> - the parallel between #selector(foo(:)) and @selector(foo) is not quite
>> as obvious as between #selector(foo(_:)) and @selector(foo:).
>>
>>
>> For the sake of discussion, another option would be *foo(_)*. This was
>> my original choice, and I like that the number of colons matches the number
>> of parameters. However, it's a little less obvious as a function reference.
>> It would preclude _ from acting as an actual identifier, and might conflict
>> with pattern-matching syntax (although it appears functions can't be
>> compared with ~= anyway).
>>
>>
>> Looking forward to everyone's bikeshed color ideas,
>> Jacob
>>
>>
>> 

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[BJ Homer via swift-evolution]

I love the idea of a leading and trailing backslash. It makes it much easier to 
read, and handles the "but what if I want to access a property of a KeyPath?" 
case really well.

For example, these two are clearly distinct:

  let x = \Person.mother.age\.valueType

  let y = \Person.mother.age.valueType\

I'm not sure why an 'age' object would have a 'valueType' property, but this 
variant makes it easy to handle. Even in cases where no disambiguation is 
required, having the trailing backslash makes it much easier to read as I'm 
scanning through code.

-BJ

>>> On Apr 5, 2017, at 9:13 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada via swift-evolution 
>>>  wrote:
>>> 
>>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> It's worth noting that, if you write `\Person.name.valueType`, this syntax 
>>> is ambiguous—it could mean "make a key path for the `valueType` property on 
>>> `name` property of `Person`", or it could mean "make a key path for the 
>>> `name` property of `Person`, then access the key path's `valueType` 
>>> property". We can solve this by always interpreting it as the former and 
>>> requiring parentheses for the latter—that is, 
>>> `(\Person.name).valueType`—but I thought it was worth calling out 
>>> explicitly.
>> 
>> Good point. 
>> 
>>  I'm thinking about the hypothetical code examples from previous emails:
>> 
>> 
>>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> That's an interesting point. While `\` alone seems acceptable, I think it's 
> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
> Can we maybe consider instead:
> 
>   let firstFriendsNameKeyPath = \Person.friends[0].name\
> 
> It is also worth mentioning that, with the sigil, the `keyPath` label may not 
> be so necessary:
> 
>   print(luke[\.friends[0].name])
>   // or, if the suggestion above is accepted
>   print(luke[\.friends[0].name\])
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Brandon Knope via swift-evolution]

If a lot of people (core team included) agree that the current design is less 
than ideal...why lock in something so important that can never be changed going 
forward?

Why not get it right and force something source breaking that would improve the 
language for everyone going forward?

The language is still, after all, very young. 

I understand the problem it would cause but this isn't like breaking everyone's 
code 10 years later. It's still a fresh language

I'm probably missing some of the complexity and politics behind doing something 
like this, but it just seems like doing the right thing is more beneficial in 
the long run

Brandon 

> On Apr 8, 2017, at 12:34 AM, John McCall via swift-evolution 
>  wrote:
> 
> 
>>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>>>  wrote:
>>> 
>>> What is your evaluation of the proposal?
>> 
>> If this is the last option we have to change the status quo, any renaming is 
>> off the table, no further changes after Swift 4, and it's either this or 
>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>> will increase the convenience of access control for people like me who see 
>> types and their extensions as parts of the same entity, just spread visually 
>> across neighboring blocks. In almost any other language these two would 
>> indeed be one entity, since most languages don't have any way of dividing 
>> types into pieces this way.
>> 
>> However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>> back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.
> 
>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>> suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
> for some new generalization, e.g. if we added sub-file submodules and wanted 
> 'fileprivate' to allow access only within the submodule.  That is assuming a 
> lot about how a future submodule feature would work, and we aren't going to 
> design that feature specifically with a goal of replacing this keyword, and 
> frankly we don't know when we're going to take that on at all.  I would 
> caution people against assuming that 'fileprivate' will be renamed.
> 
>> 3) Postpone this until we add submodules, but with the assumption that it 
>> will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature — perhaps submodules — demands 
> that we define its interaction with 'private', the design of that interaction 
> will have to feel natural and consistent with the at-that-point extant design 
> of 'private'.  For example, it would not be acceptable if, say, adding a 
> submodule declaration to a file suddenly changed the interpretation of 
> 'private'.
> 
> An option (4) that you didn't list but which I should cover for completeness 
> would be to add new keywords in the future with new interpretations.  This is 
> something that the Core Team is willing to consider.  However, speaking just 
> for myself again, I find it unlikely that we would add new access control 
> features just to express increasingly-precise refinements; it would have to 
> be something that felt necessary because of some real inadequacy in the 
> existing access-control levels as applied to some other new feature (e.g. 
> submodules).
> 
> John.
> 
>> The thing I don't like about this proposal (or status quo) - apart from the 
>> fact that it will make people who like the current strict private unhappy - 
>> is that 'private' even right now means kind of two different things:
>> 
>> - for a property or a method defined in a class/struct, it means "available 
>> only inside this type"
>> - for a private global variable/constant/function, or a private type or 
>> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Fri, Apr 7, 2017 at 11:34 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > > What is your evaluation of the proposal?
> >
> > If this is the last option we have to change the status quo, any
> renaming is off the table, no further changes after Swift 4, and it's
> either this or being stuck with 'fileprivate' until the end of time, then
> +1 from me. It will increase the convenience of access control for people
> like me who see types and their extensions as parts of the same entity,
> just spread visually across neighboring blocks. In almost any other
> language these two would indeed be one entity, since most languages don't
> have any way of dividing types into pieces this way.
> >
> > However, IMHO any of these would be a better solution:
>
> I'd like to respond briefly to this to clarify the Core Team's decisions
> about what solutions are under consideration, both now and in the future.
> By doing this, I don't mean to pressure you towards any particular stance.
> The Core Team asked for this to be proposed because we wanted to know how
> the community felt about it; we are not specifically trying to get it
> approved, at least as a group.
>
> > 1) Rename 'private' to something else ('scoped'?) and rename
> 'fileprivate' back to 'private'
>
> The Core Team has rejected making such a major change in the
> interpretation of 'private'.  'private' will be tied to scopes, now and
> forever.  The only question is whether extensions of the same type within a
> file should be considered part of the same scope for the purposes of
> 'private'.  Swift 4 is the deadline for making that change; if it, too, is
> rejected, 'private' will be purely lexical forever.
>
> > 2) Rename 'fileprivate' to something more friendly (I liked the 'local'
> suggestion that Vladimir made today)
>
> The Core Team is willing to consider adding a new keyword to replace
> 'fileprivate', but not in Swift 4.
>
> Speaking just for myself, I don't think we'd accept such a change purely
> for aesthetics;


If I recall correctly, Chris in post-review discussions communicated that a
new keyword to replace `fileprivate` would be considered if `fileprivate`
turned out to be commonly used enough to be aesthetically problematic?

I bring this up because, in replying to BJ Homer, it occurs to me that
there is an interesting solution. If--as I understand--successive access
modifiers being supersets of preceding ones is a non-negotiable part of the
design, then type-based access modifiers cannot be accommodated in Swift
because of the existence of extensions. Ergo, the word "protected" cannot
ever be used to mean what it does in C++, etc. It is a perfectly nice word
that by its dictionary meaning is plausibly intermediate between "private"
and "internal," which we can repurpose to mean protected by the end of
file! By co-opting this word, it has the key virtue of definitively
demonstrating that Swift cannot and will not support access modifiers that
are tied to types.

it would have to be because 'fileprivate' seemed inappropriate for some new
> generalization, e.g. if we added sub-file submodules and wanted
> 'fileprivate' to allow access only within the submodule.  That is assuming
> a lot about how a future submodule feature would work, and we aren't going
> to design that feature specifically with a goal of replacing this keyword,
> and frankly we don't know when we're going to take that on at all.  I would
> caution people against assuming that 'fileprivate' will be renamed.
>
> > 3) Postpone this until we add submodules, but with the assumption that
> it will be possible to make some source-breaking changes at that point
>
> The Core Team is not willing to change the basic design of 'private' in
> future releases of Swift.  If some feature — perhaps submodules — demands
> that we define its interaction with 'private', the design of that
> interaction will have to feel natural and consistent with the at-that-point
> extant design of 'private'.  For example, it would not be acceptable if,
> say, adding a submodule declaration to a file suddenly changed the
> interpretation of 'private'.
>
> An option (4) that you didn't list but which I should cover for
> completeness would be to add new keywords in the future with new
> interpretations.  This is something that the Core Team is willing to
> consider.  However, speaking just for myself again, I find it unlikely that
> we would add new access control features just to express
> increasingly-precise refinements; it would have to be something that felt
> necessary because of some real inadequacy in the existing access-control
> levels as applied to some other new feature (e.g. submodules).
>
> John.
>
> > The thing I don't like about this proposal (or status quo) - apart from
> the fact that it will make people who like the current strict private
> unhappy - is 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Sat, Apr 8, 2017 at 12:01 AM, BJ Homer via swift-evolution <
swift-evolution@swift.org> wrote:

> If private is required to be tied to types forever and always, then yes,
> this proposal should be accepted.


Let's be clear: private is not and will never be tied to types. It is tied
to *scopes*. This proposal has received a lot of responses suggesting that
the proposed rules should be extended to allow extensions in the same
module to access private members, but that fundamentally misunderstands
access modifiers in Swift.

Two things here. First, Swift allows types to be extended after the fact:
outside the same declaration, outside the same file, even outside the same
module. Second, Swift has access modifiers where each level of access is a
superset of the previous. That is, if you change `private let a` to
`fileprivate let a`, there is no place where `a` becomes no longer
accessible; the same goes for each pair of access modifiers. These two
design decisions are, as far as I'm aware, "now and forever" aspects of
Swift.

Given that these two things are true, *no access modifier is or can be tied
to types*. This proposal is about extending the meaning of *scope* to
include same-file extensions. If you try to think of private as a
type-private modifier, you will invariably conclude that it is broken,
because you can't see private members in extensions outside the same scope.
You will also see the proposed private as broken, only less so, because you
can't see private members in extensions outside the same file. However,
unless I'm greatly mistaken, it is not the intention of this or any other
proposal to create an access level tied to types.

To do otherwise is to suggest that the use of "private" by beginners and
> the use of same-file extensions by beginners are incompatible. The former
> is silly; "private" is what beginners will naturally reach for. The latter
> is possible, but historically the use of same-file extensions has been
> quite idiomatic. So, I reluctantly agree we should accept this proposal.
>
> -BJ
>
> > On Apr 7, 2017, at 10:34 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> What is your evaluation of the proposal?
> >>
> >> If this is the last option we have to change the status quo, any
> renaming is off the table, no further changes after Swift 4, and it's
> either this or being stuck with 'fileprivate' until the end of time, then
> +1 from me. It will increase the convenience of access control for people
> like me who see types and their extensions as parts of the same entity,
> just spread visually across neighboring blocks. In almost any other
> language these two would indeed be one entity, since most languages don't
> have any way of dividing types into pieces this way.
> >>
> >> However, IMHO any of these would be a better solution:
> >
> > I'd like to respond briefly to this to clarify the Core Team's decisions
> about what solutions are under consideration, both now and in the future.
> By doing this, I don't mean to pressure you towards any particular stance.
> The Core Team asked for this to be proposed because we wanted to know how
> the community felt about it; we are not specifically trying to get it
> approved, at least as a group.
> >
> >> 1) Rename 'private' to something else ('scoped'?) and rename
> 'fileprivate' back to 'private'
> >
> > The Core Team has rejected making such a major change in the
> interpretation of 'private'.  'private' will be tied to scopes, now and
> forever.  The only question is whether extensions of the same type within a
> file should be considered part of the same scope for the purposes of
> 'private'.  Swift 4 is the deadline for making that change; if it, too, is
> rejected, 'private' will be purely lexical forever.
> >
> >> 2) Rename 'fileprivate' to something more friendly (I liked the 'local'
> suggestion that Vladimir made today)
> >
> > The Core Team is willing to consider adding a new keyword to replace
> 'fileprivate', but not in Swift 4.
> >
> > Speaking just for myself, I don't think we'd accept such a change purely
> for aesthetics; it would have to be because 'fileprivate' seemed
> inappropriate for some new generalization, e.g. if we added sub-file
> submodules and wanted 'fileprivate' to allow access only within the
> submodule.  That is assuming a lot about how a future submodule feature
> would work, and we aren't going to design that feature specifically with a
> goal of replacing this keyword, and frankly we don't know when we're going
> to take that on at all.  I would caution people against assuming that
> 'fileprivate' will be renamed.
> >
> >> 3) Postpone this until we add submodules, but with the assumption that
> it will be possible to make some source-breaking changes at that point
> >
> > The Core Team is not willing to change the basic design of 'private' in
> 

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

[Xiaodi Wu via swift-evolution]

+1. Perfect. Let's not bikeshed this and get it done!
On Sat, Apr 8, 2017 at 14:04 Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Hi swift-evolution,
>
> Another short proposal related to the Collection algorithms theme, this
> time for removing elements in-place from a collection.
>
> Online copy here:
> https://github.com/airspeedswift/swift-evolution/blob/1aac5593828941431d1805503865e7a2913d538b/proposals/-RemoveWhere.md
>
>
> Adding in-place removeAll to the Standard Library
>
>- Proposal: SE-
>- Authors: Ben Cohen 
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> Introduction
>
> It is common to want to remove all occurrences of a certain element from a
> collection. This proposal is to add two in-place remove algorithms to the
> standard library, which will remove all entries in a collection in-place
> matching either an Equatable value, or match that a certain criteria.
> Motivation
>
> Removing all elements matching some criteria is a very common operation.
> However, it can be tricky to implement correctly and efficiently.
>
> The easiest way to achieve this effect in Swift 3 is to use filter and
> assign back, negating the thing you want to remove (because filter takes
> a closure of items to “keep”):
>
> var nums = [1,2,3,4,5]// remove odd elements
> nums = nums.filter { !isOdd($0) }
>
> In addition to readability concerns, this has two performance problems:
> fresh memory allocation, and a copy of all the elements in full even if
> none need to be removed.
>
> The alternative is to open-code a for loop. The simplest performant
> solution is the “shuffle-down” approach. While not especially complex, it
> is certainly non-trivial:
>
> if var i = nums.index(where: isOdd) {
>   var j = i + 1
>   while j != nums.endIndex {
> let e = nums[j]
> if !isOdd(nums[j]) {
>   nums[i] = nums[j]
>   i += 1
> }
> j += 1
>   }
>   nums.removeSubrange(i.. }
>
> Possibilities for logic and performance errors abound. There are probably
> some in the above code.
>
> Additionally, this approach does not work for range-replaceable
> collections that are *not* mutable i.e. collections that can replace
> subranges, but can’t guarantee replacing a single element in constant time.
> String is the most important example of this, because its elements
> (graphemes) are variable width.
> Proposed solution
>
> Add the following methods to RangeReplaceableCollection:
>
> nums.removeAll(equalTo: 9)
> nums.removeAll(where: isOdd)
>
> The default implementation will use the protocol’s init() and append(_:) 
> operations
> to implement a copy-based version. Collections which also conform to
> MutableCollection will get the more efficient “shuffle-down”
> implementation, but still require RangeReplaceableCollection as well
> because of the need to trim at the end.
>
> Collections which are range replaceable but *not* mutable (like String)
> will be able to implement their own version which makes use of their
> internal layout. Collections like Array may also implement more efficient
> versions using memory copying operations.
>
> Since Dictionary and Set would benefit from this functionality as well,
> but are not range-replaceable, they should be given concrete
> implementations for consistency.
> Detailed design
>
> Add the following to RangeReplaceableCollection:
>
> protocol RangeReplaceableCollection {
>   /// Removes every element satisfying the given predicate from the 
> collection.
>   mutating func removeAll(where: (Iterator.Element) throws -> Bool) rethrows
> }
> extension RangeReplaceableCollection where Iterator.Element: Equatable {
>   /// Removes every element equal to the given element from the collection.
>   mutating func removeAll(equalTo element: Iterator.Element)
> }
>
> Source compatibility
>
> This change is purely additive so has no source compatibility consequences.
> Effect on ABI stability
>
> This change is purely additive so has no ABI stability consequences.
> Effect on API resilience
>
> This change is purely additive so has no API resilience consequences.
> Alternatives considered
>
> Regarding the name: remove instead of removeAll was considered. 
> removeAll(equalTo:
> 5) seems clearer when seen alongside similar methods removeFirst(5) and 
> remove(at:
> 5). In the case of remove(where:), the All in the basename is preserved
> for trailing closures.
> removeAll(where:) takes a closure with true for elements to remove. filter 
> takes
> a closure with elements to keep. In both cases, true is the “active”
> case, so likely to be what the user wants without having to apply a
> negation. The naming of filter is unfortunately ambiguous as to whether
> it’s a removing or keeping operation, but re-considering that is outside
> the scope of this proposal.
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

[swift-evolution] [pitch] Adding in-place removeAll to the std lib

[Ben Cohen via swift-evolution]

Hi swift-evolution,

Another short proposal related to the Collection algorithms theme, this time 
for removing elements in-place from a collection.

Online copy here: 
https://github.com/airspeedswift/swift-evolution/blob/1aac5593828941431d1805503865e7a2913d538b/proposals/-RemoveWhere.md


Adding in-place removeAll to the Standard Library

Proposal: SE- 

Authors: Ben Cohen 
Review Manager: TBD
Status: Awaiting review
Introduction

It is common to want to remove all occurrences of a certain element from a 
collection. This proposal is to add two in-place remove algorithms to the 
standard library, which will remove all entries in a collection in-place 
matching either an Equatable value, or match that a certain criteria.

Motivation

Removing all elements matching some criteria is a very common operation. 
However, it can be tricky to implement correctly and efficiently.

The easiest way to achieve this effect in Swift 3 is to use filter and assign 
back, negating the thing you want to remove (because filter takes a closure of 
items to “keep”):

var nums = [1,2,3,4,5]
// remove odd elements
nums = nums.filter { !isOdd($0) }
In addition to readability concerns, this has two performance problems: fresh 
memory allocation, and a copy of all the elements in full even if none need to 
be removed.

The alternative is to open-code a for loop. The simplest performant solution is 
the “shuffle-down” approach. While not especially complex, it is certainly 
non-trivial:

if var i = nums.index(where: isOdd) {
  var j = i + 1
  while j != nums.endIndex {
let e = nums[j]
if !isOdd(nums[j]) {
  nums[i] = nums[j]
  i += 1
}
j += 1
  }
  nums.removeSubrange(i.. Bool) rethrows
}

extension RangeReplaceableCollection where Iterator.Element: Equatable {
  /// Removes every element equal to the given element from the collection.
  mutating func removeAll(equalTo element: Iterator.Element)
}
Source compatibility

This change is purely additive so has no source compatibility consequences.

Effect on ABI stability

This change is purely additive so has no ABI stability consequences.

Effect on API resilience

This change is purely additive so has no API resilience consequences.

Alternatives considered

Regarding the name: remove instead of removeAll was considered. 
removeAll(equalTo: 5) seems clearer when seen alongside similar methods 
removeFirst(5) and remove(at: 5). In the case of remove(where:), the All in the 
basename is preserved for trailing closures.

removeAll(where:) takes a closure with true for elements to remove. filter 
takes a closure with elements to keep. In both cases, true is the “active” 
case, so likely to be what the user wants without having to apply a negation. 
The naming of filter is unfortunately ambiguous as to whether it’s a removing 
or keeping operation, but re-considering that is outside the scope of this 
proposal.



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

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

[Zach Waldowski via swift-evolution]

Responses inline.



Best,

  Zachary Waldowski

  z...@waldowski.me





On Wed, Apr 5, 2017, at 08:45 PM, Ben Cohen via swift-evolution wrote:

> • What is your evaluation of the proposal?



Overall, +1. Dictionary and in Set are in need of interaction
improvements. However, given the increased need for considering source
stability, I'm of the opinion adding new stuff to the stdlib should face
an appropriately high bar; so specific and nit-picky notes follow.


- The `init(_ keysAndValues: Sequence)` should be `init?(_:)`.

- The merging family does not feel completely in line with Swift
  naming. Considering other closure-taking methods in the stdlib, I
  feel like "by mergingValues" is a better fit, since "merg[ing]"
  already comes up in the signature, netting you `Dictionary(merging:
  listOfPairs, by: max)`.
- I'm not sure subscripts allow all this right now, but `default
  defaultValue` seems like an appropriate candidate for being
  `@autoclosure` and `throws`, and the subscript itself `rethrows`.
- I retract my concerns over the merging methods, but I still don't see
  the API benefit of `mapValues`. This doesn't seem like it pulls its
  weight besides an optimization. With SE-0154 and conditional
  conformances, I feel like the same optimization could be possible with
  `init(_ keysAndValues: Sequence)` and `lazy`. So -1 there.
- Source-breaking changes from `filter(_:)` overloads feel more
  problematic than described in the proposal. Both behaviors (returning
  Self and returning Array) are useful, and I don't want to lose easy
  calling of one. The desired behavior can also be accomplished using
  one of the initializers and `filter` or `lazy.filter`. -0.5 on that.
- As much as I want it personally, `grouped(by:)` feels like a weak
  specialization of `init(merging:mergingValues:)`. Now, of course, that
  would be better (for performance, readability, etc.) if `combine` were
  `inout`. This parallels nicely with the subscript-with-default being a
  mutating l-value. I don't remember how `reduce`-with-`inout` fell out
  back in January, but this feels like it's in similar territory. I just
  don't want to lock us into a collection of methods that are only
  slightly only different enough to be frustrating when using them.


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


For sure. Arrays and generalized collections are best-in-class; the
hashed collections are only slightly less so.


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



With some nits as noted above, yes.



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


I, for one, don't feel like Dictionary needs to shoot much past the
capabilities of NSMutableDictionary, but should definitely at least
match it; this proposal gets us pretty close.


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


Followed the proposal since inception. Uh, big user of dictionaries,
I suppose.


> 

> More information about the Swift evolution process is available at
> https://github.com/apple/swift-evolution/blob/master/process.md
> 

> Thank you,

> 

> Ben Cohen

> 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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Charles Srstka via swift-evolution]

I suggested that a while ago. Although I still think it’s the best solution (in 
addition to the benefits you mentioned, partials could also contain stored 
properties without making the behavior of extensions inconsistent), it didn’t 
seem to go over very well on the list, with people balking at the prospect of 
introducing another keyword.

Charles

> On Apr 8, 2017, at 7:19 AM, Neil via swift-evolution 
>  wrote:
> 
> I agreed with Charlie, but I think there’s another option. 
> 
> The access control problems that both SE-0159 and SE-0169 are attempting to 
> address can be resolved not by changing the definition of the existing access 
> modifiers, but refocussing the use of extensions. 
> 
> One such way would be to introduce a `partial` modifier. It would be similar 
> to C#’s partial modifier. The proposed partial modifier would be purely 
> additive and it would go a long way to mitigate the access control issues 
> inherent in extension-oriented design. 
> 
> The key characteristics of partial-oriented design would be:
> 
> - Partials would allow the splitting of implementations into multiple logical 
> units without the same-file restriction.
> - Partial definitions of a type are restricted to same module. If you wish to 
> add functionality to a type external to its defining module, use an 
> extension. 
> - Partials would provide greater clarity between additive extension and the 
> original implementation. 
> - Within a partial, private would be type-private. 
> - Within an extension, private would be scoped-private (the status quo). 
> 
> I do see that the last two points may introduce some friction. Particularly 
> because: 
> 
> - Within a partial, fileprivate would be more restrictive than private. 
> - Within an extension, fileprivate would be less restrictive than private 
> (the status quo). 
> 
> However, I don’t see these as too challenging for educators or developers as 
> they are differentiated by their top-level scope. 
> 
> 
> On 07/04/2017, 05:57, "Charlie Monroe via swift-evolution" 
>  
> wrote:
> 
>> Simply as long as it's file-based, it's not a solution, it's just another 
>> attempt to satisfy some part of the community. I'm not saying that the 
>> current access levels are perfect, but I still believe the way to go is to 
>> either use submodules, and/or introducing the concept of "protected" members.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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-0168: Multi-Line String Literals

[Karim Nassar via swift-evolution]

> On Apr 6, 2017, at 1:35 PM, Joe Groff via swift-evolution 
> > wrote:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>  
>   
> >
>   • What is your evaluation of the proposal?

-1 because I don’t think this proposal is fully baked. We definitely need this 
feature, but we need more discussion on the details.

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

Yes. There are many practical and pragmatic reasons to want to embed multi-line 
string literals in code, and most of these use-cases are hampered or made more 
significantly more fiddly with continuation characters or concatenation, for 
all the reasons already discussed.

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

This is where things break down. This proposal feels like we took Python’s 
approach and slapped it on Swift. There are more ways to do this than identical 
open-close delimiters with magic whitespace stripping. 

Non-exhasutive ideas for other options we should weigh (all spellings are 
straw-men):

1. Open/close delimiters: 
let msg = @“ // optionally: @4” to strip 4 chars leading whitespace
this is a
message
"@

2. A “Swifty” Heredoc compiler directive:
let msg = #stringUntil(END) // optionally: #stringUntil(END, stripLeading: 
4)
this is a
message
END

3. Other options as mentioned on this list

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

This is pretty much the Python approach with some additional vague 
whitespace-stripping rules. We need to think it through better and then 
re-introduce after proper discussion.

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

Read the proposal, followed the discussion.

> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
>  
>  >
> 
> Thank you,
> 
> -Joe
> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Charlie Monroe via swift-evolution]

This seems like a nice compromise, though it introduces a "horizontal" issue of 
indentation. Not a huge issue IMHO, though I think some people may see it as a 
downside.

For me, it's +1, though.

> On Apr 8, 2017, at 2:03 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> Imho there is a simple solution to reach the goals of SE-0169 without 
> breaking compatibility:
> Just allow extensions inside type declarations.
> 
> class MyVC: UIViewController {
> private let numberOfSections = 0
> 
> extension: UITableViewDataSource {
> // Skipping the class and assume we want to extend the surrounding 
> type
> func numberOfSections(in tableView: UITableView) -> Int {
> return numberOfSections
> }
> 
> func tableView(_ tableView: UITableView, numberOfRowsInSection 
> section: Int) -> Int {
> return 0
> }
> }
> 
> private extension {
> // this would contain everything that shoudn't be visible for other 
> extensios
> 
> var secret: Int = 0
> 
> public extension MyFriendClass {
> // oh, well, I make an exception here for a trustworthy type
> func checkSecret(of controller: MyVC) -> Bool {
> return controller.secret > 0
> }
> }
> 
> private extension {
> // this is so secret, I'm not even allowed to copy it
> }
> }
> 
> public func myMethod() {
> print("This is just a boring method")
> }
> }
> 
> It has the downside of shifting code to the right (you could as well leave 
> those extension-blocks unindented), but lots of advantages:
> - No change for private needed
> - It can be nested as much as you like to satisfy even the most absurd 
> desires of encapsulation
> - It reminds me on operator definitions inside type declarations 
> - No change for fileprivate needed (but actually, I think there is very 
> little need to keep fileprivate)
> 
> I wish this would only be a joke, but writing the example, I actually started 
> liking the concept (but I have a terrible headache right now which might 
> affect my mind) — so either this receives some feedback, or I might start 
> re-proposing this ;-)
> 
> - Tino
> ___
> 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-0169: Improve Interaction Between private Declarations and Extensions

[Neil via swift-evolution]

I agreed with Charlie, but I think there’s another option. 

The access control problems that both SE-0159 and SE-0169 are attempting to 
address can be resolved not by changing the definition of the existing access 
modifiers, but refocussing the use of extensions. 

One such way would be to introduce a `partial` modifier. It would be similar to 
C#’s partial modifier. The proposed partial modifier would be purely additive 
and it would go a long way to mitigate the access control issues inherent in 
extension-oriented design. 

The key characteristics of partial-oriented design would be:

- Partials would allow the splitting of implementations into multiple logical 
units without the same-file restriction.
- Partial definitions of a type are restricted to same module. If you wish to 
add functionality to a type external to its defining module, use an extension. 
- Partials would provide greater clarity between additive extension and the 
original implementation. 
- Within a partial, private would be type-private. 
- Within an extension, private would be scoped-private (the status quo). 

I do see that the last two points may introduce some friction. Particularly 
because: 

- Within a partial, fileprivate would be more restrictive than private. 
- Within an extension, fileprivate would be less restrictive than private (the 
status quo). 

However, I don’t see these as too challenging for educators or developers as 
they are differentiated by their top-level scope. 


On 07/04/2017, 05:57, "Charlie Monroe via swift-evolution" 
 
wrote:

> Simply as long as it's file-based, it's not a solution, it's just another 
attempt to satisfy some part of the community. I'm not saying that the current 
access levels are perfect, but I still believe the way to go is to either use 
submodules, and/or introducing the concept of "protected" members.










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

[swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

Imho there is a simple solution to reach the goals of SE-0169 without breaking 
compatibility:
Just allow extensions inside type declarations.

class MyVC: UIViewController {
private let numberOfSections = 0

extension: UITableViewDataSource {
// Skipping the class and assume we want to extend the surrounding type
func numberOfSections(in tableView: UITableView) -> Int {
return numberOfSections
}

func tableView(_ tableView: UITableView, numberOfRowsInSection section: 
Int) -> Int {
return 0
}
}

private extension {
// this would contain everything that shoudn't be visible for other 
extensios

var secret: Int = 0

public extension MyFriendClass {
// oh, well, I make an exception here for a trustworthy type
func checkSecret(of controller: MyVC) -> Bool {
return controller.secret > 0
}
}

private extension {
// this is so secret, I'm not even allowed to copy it
}
}

public func myMethod() {
print("This is just a boring method")
}
}

It has the downside of shifting code to the right (you could as well leave 
those extension-blocks unindented), but lots of advantages:
- No change for private needed
- It can be nested as much as you like to satisfy even the most absurd desires 
of encapsulation
- It reminds me on operator definitions inside type declarations 
- No change for fileprivate needed (but actually, I think there is very little 
need to keep fileprivate)

I wish this would only be a joke, but writing the example, I actually started 
liking the concept (but I have a terrible headache right now which might affect 
my mind) — so either this receives some feedback, or I might start re-proposing 
this ;-)

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Adrian Zubarev via swift-evolution]

What is your evaluation of the proposal?

–1 for the proposed solution, but in general I’d myself would want to see 
multi-line strings in Swift. The current proposal does not cover precision, 
which could also be desired by developers.

My _personal_ view on how I wish multi-line strings do behave is actually 
similar to the magical string concatenation which is an optimization during 
compile time (not included in Xcode 8.3). Many people disagree with this point 
of view in favor of implicit new lines and non escaped " character, which is 
fine by me only if we can extend the standard string literal to support 
multilines too. Such extension will be stricter and have special precision 
rules.

// Simplicity which supports indent but at a cost of no
// leading or trailing space characters
let string1 = "my
multiline
string"

print(string1) // prints "mymultilinestring"

let string2 = "my \
multiline \
string"
   
// Trailing precision
print(string2) // prints "my multiline string"

let string3 = "my
" multiline
" string"
   
// Leading precision
print(string3) // prints "my multiline string"

let string4 = "my \
" multiline \
" string"
   
// Leading and trailing precision
print(string4) // prints "my  multiline  string" (Note: 2x two whitespaces)

let string5 = "my\
"multiline\
"string"
   
// Leading and trailing precision
// Provide a fix-it to remove some `\` and `"` characters
// because it equals `string1`
print(string5) // prints "mymultilinestring"

let string6 = "my \
"multiline \
"string"
   
// Leading and trailing precision
// Provide a fix-it to remove some `"` characters
// because it equals `string2`
print(string6) // prints "my multiline string"

let string7 = "my\
" multiline\
" string"
   
// Leading and trailing precision
// Provide a fix-it to remove some `\` characters
// because it equals `string3`
print(string7) // prints "my multiline string"
Additionally you can support a similar version of multilines strings with """ 
notation for those of use who are lazy to type \n and \" and want implicit new 
lines. However this raises the question, if the addition of """ is warrant it’s 
existence only for laziness and copy pasting?

The above example should also support string interpolation.

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

Not enough from my point of view.

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

The addition of multi-lined strings does fit, however I don’t think the 
proposed solution satisfies everyone. Personally I’d probably never use a 
multi-lined string as proposed, just because it adds implicit new lines to my 
very long string, which I maybe only want to break up into a few lines for 
better readability without the boilerplate of the not so obvious optimization 
magic provided by the complier though the concatenation operator +.

I think the correct name is *multi line string literal*, which is different 
from _multi line string_. The former should not have any implicit behavior 
except if there are two different versions like "__" and """___""".

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

Javascript has this nice ability to break up strings into multilines with 
trailing precision, which I used in the example above.

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

Read the whole proposal and took part in latest discussion thread.



-- 
Adrian Zubarev
Sent with Airmail

Am 6. April 2017 um 21:35:50, Joe Groff via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hello Swift community,

The review of SE-0168 "Multi-Line String Literals" begins now and runs through 
April 12, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.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. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md

Reply text
Other replies

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 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jean-Daniel via swift-evolution]

So, +1 for me too. 

I’m part of the people who didn’t want SE-0025 in the first place, and don’t 
like any workaround we try to implement to mitigate it, but taking the Core 
Team decision in account, I feel this is the right thing to do now.

If strong scoped variables are needed, it will always be possible to 
reintroduce them using a new keyword (I will personally be against such 
proposal, but it is a possibility).


> Le 8 avr. 2017 à 06:34, John McCall via swift-evolution 
>  a écrit :
> 
>> 
>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> 
>> If this is the last option we have to change the status quo, any renaming is 
>> off the table, no further changes after Swift 4, and it's either this or 
>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>> will increase the convenience of access control for people like me who see 
>> types and their extensions as parts of the same entity, just spread visually 
>> across neighboring blocks. In almost any other language these two would 
>> indeed be one entity, since most languages don't have any way of dividing 
>> types into pieces this way.
>> 
>> However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>> back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.
> 
>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>> suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
> for some new generalization, e.g. if we added sub-file submodules and wanted 
> 'fileprivate' to allow access only within the submodule.  That is assuming a 
> lot about how a future submodule feature would work, and we aren't going to 
> design that feature specifically with a goal of replacing this keyword, and 
> frankly we don't know when we're going to take that on at all.  I would 
> caution people against assuming that 'fileprivate' will be renamed.
> 
>> 3) Postpone this until we add submodules, but with the assumption that it 
>> will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature — perhaps submodules — demands 
> that we define its interaction with 'private', the design of that interaction 
> will have to feel natural and consistent with the at-that-point extant design 
> of 'private'.  For example, it would not be acceptable if, say, adding a 
> submodule declaration to a file suddenly changed the interpretation of 
> 'private'.
> 
> An option (4) that you didn't list but which I should cover for completeness 
> would be to add new keywords in the future with new interpretations.  This is 
> something that the Core Team is willing to consider.  However, speaking just 
> for myself again, I find it unlikely that we would add new access control 
> features just to express increasingly-precise refinements; it would have to 
> be something that felt necessary because of some real inadequacy in the 
> existing access-control levels as applied to some other new feature (e.g. 
> submodules).
> 
> John.
> 
>> The thing I don't like about this proposal (or status quo) - apart from the 
>> fact that it will make people who like the current strict private unhappy - 
>> is that 'private' even right now means kind of two different things:
>> 
>> - for a property or a method defined in a class/struct, it means "available 
>> only inside this type"
>> - for a private global variable/constant/function, or a private type or 
>> extension, it means "available in this file" i.e. the same as 'fileprivate'
>> 
>> So if we're worried that this proposal makes the meaning of 'private' 
>> unclear - it already is unclear. 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jakub Suder via swift-evolution]

Fair enough - in this case, definitely +1 on the current proposal.

Kuba

On 8 April 2017 at 06:34, John McCall  wrote:

>
> > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > > What is your evaluation of the proposal?
> >
> > If this is the last option we have to change the status quo, any
> renaming is off the table, no further changes after Swift 4, and it's
> either this or being stuck with 'fileprivate' until the end of time, then
> +1 from me. It will increase the convenience of access control for people
> like me who see types and their extensions as parts of the same entity,
> just spread visually across neighboring blocks. In almost any other
> language these two would indeed be one entity, since most languages don't
> have any way of dividing types into pieces this way.
> >
> > However, IMHO any of these would be a better solution:
>
> I'd like to respond briefly to this to clarify the Core Team's decisions
> about what solutions are under consideration, both now and in the future.
> By doing this, I don't mean to pressure you towards any particular stance.
> The Core Team asked for this to be proposed because we wanted to know how
> the community felt about it; we are not specifically trying to get it
> approved, at least as a group.
>
> > 1) Rename 'private' to something else ('scoped'?) and rename
> 'fileprivate' back to 'private'
>
> The Core Team has rejected making such a major change in the
> interpretation of 'private'.  'private' will be tied to scopes, now and
> forever.  The only question is whether extensions of the same type within a
> file should be considered part of the same scope for the purposes of
> 'private'.  Swift 4 is the deadline for making that change; if it, too, is
> rejected, 'private' will be purely lexical forever.
>
> > 2) Rename 'fileprivate' to something more friendly (I liked the 'local'
> suggestion that Vladimir made today)
>
> The Core Team is willing to consider adding a new keyword to replace
> 'fileprivate', but not in Swift 4.
>
> Speaking just for myself, I don't think we'd accept such a change purely
> for aesthetics; it would have to be because 'fileprivate' seemed
> inappropriate for some new generalization, e.g. if we added sub-file
> submodules and wanted 'fileprivate' to allow access only within the
> submodule.  That is assuming a lot about how a future submodule feature
> would work, and we aren't going to design that feature specifically with a
> goal of replacing this keyword, and frankly we don't know when we're going
> to take that on at all.  I would caution people against assuming that
> 'fileprivate' will be renamed.
>
> > 3) Postpone this until we add submodules, but with the assumption that
> it will be possible to make some source-breaking changes at that point
>
> The Core Team is not willing to change the basic design of 'private' in
> future releases of Swift.  If some feature — perhaps submodules — demands
> that we define its interaction with 'private', the design of that
> interaction will have to feel natural and consistent with the at-that-point
> extant design of 'private'.  For example, it would not be acceptable if,
> say, adding a submodule declaration to a file suddenly changed the
> interpretation of 'private'.
>
> An option (4) that you didn't list but which I should cover for
> completeness would be to add new keywords in the future with new
> interpretations.  This is something that the Core Team is willing to
> consider.  However, speaking just for myself again, I find it unlikely that
> we would add new access control features just to express
> increasingly-precise refinements; it would have to be something that felt
> necessary because of some real inadequacy in the existing access-control
> levels as applied to some other new feature (e.g. submodules).
>
> John.
>
> > The thing I don't like about this proposal (or status quo) - apart from
> the fact that it will make people who like the current strict private
> unhappy - is that 'private' even right now means kind of two different
> things:
> >
> > - for a property or a method defined in a class/struct, it means
> "available only inside this type"
> > - for a private global variable/constant/function, or a private type or
> extension, it means "available in this file" i.e. the same as 'fileprivate'
> >
> > So if we're worried that this proposal makes the meaning of 'private'
> unclear - it already is unclear. Wouldn't it be much more clear if private
> global variables, functions and classes were required to use the access
> level that means "available in this file", since that's how they actually
> work? (as long as this level is not named 'fileprivate' :)
> >
> > And the other access level, the "available only inside this type"
> (private / scoped), could only be used for things that are actually
> contained inside a type, and wouldn't have two different meanings depending
> on whether 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Rod Brown via swift-evolution]

> On 8 Apr 2017, at 2:34 pm, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> 
>> If this is the last option we have to change the status quo, any renaming is 
>> off the table, no further changes after Swift 4, and it's either this or 
>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>> will increase the convenience of access control for people like me who see 
>> types and their extensions as parts of the same entity, just spread visually 
>> across neighboring blocks. In almost any other language these two would 
>> indeed be one entity, since most languages don't have any way of dividing 
>> types into pieces this way.
>> 
>> However, IMHO any of these would be a better solution:
> 
> I'd like to respond briefly to this to clarify the Core Team's decisions 
> about what solutions are under consideration, both now and in the future.  By 
> doing this, I don't mean to pressure you towards any particular stance.  The 
> Core Team asked for this to be proposed because we wanted to know how the 
> community felt about it; we are not specifically trying to get it approved, 
> at least as a group.
> 
>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>> back to 'private'
> 
> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.

With this being the case, I want to revise my response to +1. It allows the 
flexibility required for the extension-rich architecture Swift open adopts with 
protocol conformance and I think that’s a good thing, personally.

> 
>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>> suggestion that Vladimir made today)
> 
> The Core Team is willing to consider adding a new keyword to replace 
> 'fileprivate', but not in Swift 4.
> 
> Speaking just for myself, I don't think we'd accept such a change purely for 
> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
> for some new generalization, e.g. if we added sub-file submodules and wanted 
> 'fileprivate' to allow access only within the submodule.  That is assuming a 
> lot about how a future submodule feature would work, and we aren't going to 
> design that feature specifically with a goal of replacing this keyword, and 
> frankly we don't know when we're going to take that on at all.  I would 
> caution people against assuming that 'fileprivate' will be renamed.
> 
>> 3) Postpone this until we add submodules, but with the assumption that it 
>> will be possible to make some source-breaking changes at that point
> 
> The Core Team is not willing to change the basic design of 'private' in 
> future releases of Swift.  If some feature — perhaps submodules — demands 
> that we define its interaction with 'private', the design of that interaction 
> will have to feel natural and consistent with the at-that-point extant design 
> of 'private'.  For example, it would not be acceptable if, say, adding a 
> submodule declaration to a file suddenly changed the interpretation of 
> 'private'.
> 
> An option (4) that you didn't list but which I should cover for completeness 
> would be to add new keywords in the future with new interpretations.  This is 
> something that the Core Team is willing to consider.  However, speaking just 
> for myself again, I find it unlikely that we would add new access control 
> features just to express increasingly-precise refinements; it would have to 
> be something that felt necessary because of some real inadequacy in the 
> existing access-control levels as applied to some other new feature (e.g. 
> submodules).
> 
> John.
> 
>> The thing I don't like about this proposal (or status quo) - apart from the 
>> fact that it will make people who like the current strict private unhappy - 
>> is that 'private' even right now means kind of two different things:
>> 
>> - for a property or a method defined in a class/struct, it means "available 
>> only inside this type"
>> - for a private global variable/constant/function, or a private type or 
>> extension, it means "available in this file" i.e. the same as 'fileprivate'
>> 
>> So if we're worried that this proposal makes the meaning of 'private' 
>> unclear - it already is unclear. Wouldn't it be much more clear if private 
>> global variables, functions and classes were required to use the access 
>> level that means "available in this file", since that's how they actually 
>> work? 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

Type inference sounds nice initially then you face the costs in compilation 
time and reduced ability to debug and reason about the code months after the 
fact... and you start to rethink things (not every programmer keeps 
maintainability over pretty smart haiku code).

Sent from my iPhone

> On 8 Apr 2017, at 07:35, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Apr 7, 2017, at 22:40, Pranshu Goyal via swift-evolution 
>>  wrote:
>> 
>> I agree with the sentiment of the proposal, it does add value to overall 
>> efficiency of swift and make things simpler for the swift team, but as 
>> Matthew said a blanket ban will add noise to the code. Also this particular 
>> feature is one of those niceties about swift which makes it very welcoming 
>> to new adopters.
>> 
>> If some middle ground can be proposed to this problem then I think we will 
>> be making a lot of people happy.
> 
> I don't think I'd mind a flag that disables type inference for properties or 
> something. Really, though, this seems like a linter's job to me.
> 
> Maybe the Swift manual should have a chapter about the trade-offs between 
> code that's quick to write, quick to run, and quick to compile?
> 
> - Dave Sweeris
> ___
> 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] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.

If private really is tied to scopes now and forever, I certainly have no doubt 
these change should be accepted to alleviate the biggest annoyance with it.

Should this be accepted, to me, using "fileprivate" serves as a flag that 
another type has privileged access to another type's private members. 
Unfortunately, because fileprivate is needed for extensions of the same type, 
then the keyword loses this meaning. If I choose to use extensions to define a 
type (as was a practice greatly encouraged in Swift 1/2), fileprivate serves no 
self-documentation role beyond "private".

Additionally, I truly believe this proposal would align the access control with 
what newcomers to the language are already familiar with. When they adopt the 
Swift practice of multiple extensions, they'll be confused why they have to 
change private to fileprivate, and may instead just decide to stick it all in 
one definition. Anecdotally, that's certainly what I expected when Swift 3 was 
released, and I've now stopped using extensions for types as much simply 
because of fileprivate.

> On Apr 7, 2017, at 10:01 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> If private is required to be tied to types forever and always, then yes, this 
> proposal should be accepted. To do otherwise is to suggest that the use of 
> "private" by beginners and the use of same-file extensions by beginners are 
> incompatible. The former is silly; "private" is what beginners will naturally 
> reach for. The latter is possible, but historically the use of same-file 
> extensions has been quite idiomatic. So, I reluctantly agree we should accept 
> this proposal.
> 
> -BJ
> 
>> On Apr 7, 2017, at 10:34 PM, John McCall via swift-evolution 
>>  wrote:
>> 
>> 
 On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
  wrote:
 
 What is your evaluation of the proposal?
>>> 
>>> If this is the last option we have to change the status quo, any renaming 
>>> is off the table, no further changes after Swift 4, and it's either this or 
>>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>>> will increase the convenience of access control for people like me who see 
>>> types and their extensions as parts of the same entity, just spread 
>>> visually across neighboring blocks. In almost any other language these two 
>>> would indeed be one entity, since most languages don't have any way of 
>>> dividing types into pieces this way.
>>> 
>>> However, IMHO any of these would be a better solution:
>> 
>> I'd like to respond briefly to this to clarify the Core Team's decisions 
>> about what solutions are under consideration, both now and in the future.  
>> By doing this, I don't mean to pressure you towards any particular stance.  
>> The Core Team asked for this to be proposed because we wanted to know how 
>> the community felt about it; we are not specifically trying to get it 
>> approved, at least as a group.
>> 
>>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>>> back to 'private'
>> 
>> The Core Team has rejected making such a major change in the interpretation 
>> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
>> question is whether extensions of the same type within a file should be 
>> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
>> the deadline for making that change; if it, too, is rejected, 'private' will 
>> be purely lexical forever.
>> 
>>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>>> suggestion that Vladimir made today)
>> 
>> The Core Team is willing to consider adding a new keyword to replace 
>> 'fileprivate', but not in Swift 4.
>> 
>> Speaking just for myself, I don't think we'd accept such a change purely for 
>> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
>> for some new generalization, e.g. if we added sub-file submodules and wanted 
>> 'fileprivate' to allow access only within the submodule.  That is assuming a 
>> lot about how a future submodule feature would work, and we aren't going to 
>> design that feature specifically with a goal of replacing this keyword, and 
>> frankly we don't know when we're going to take that on at all.  I would 
>> caution people against assuming that 'fileprivate' will be renamed.
>> 
>>> 3) Postpone this until we add submodules, but with the assumption that it 
>>> will be possible to make some 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[David Sweeris via swift-evolution]

> On Apr 7, 2017, at 22:40, Pranshu Goyal via swift-evolution 
>  wrote:
> 
> I agree with the sentiment of the proposal, it does add value to overall 
> efficiency of swift and make things simpler for the swift team, but as 
> Matthew said a blanket ban will add noise to the code. Also this particular 
> feature is one of those niceties about swift which makes it very welcoming to 
> new adopters.
> 
> If some middle ground can be proposed to this problem then I think we will be 
> making a lot of people happy.

I don't think I'd mind a flag that disables type inference for properties or 
something. Really, though, this seems like a linter's job to me.

Maybe the Swift manual should have a chapter about the trade-offs between code 
that's quick to write, quick to run, and quick to compile?

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Brent Royal-Gordon via swift-evolution]

> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.


Beyond just being more friendly, I think it could be considered a teaching 
issue. A great way to introduce beginners to custom types would be something 
like:

struct Point {
var x = 0.0
var y = 0.0
}

Or:

struct Person {
var name = ""
var age = 18
}

If you have to explicitly specify types for the properties, that's another 
thing you need to introduce to people before you can do this.

On the other hand, a very limited form of inference might be fine here. Imagine 
if we did a sort of limited, single-pass, top-down inference which only 
understood a few things (literals, tuple syntax, initializer calls), stopped 
once it had seen enough to infer a complete type, and rejected an expression if 
it encountered something it didn't understand before finishing. That would 
probably cover most simple cases, and it would probably only allow expressions 
whose types were obvious enough that we could use it for arguments, too. (But 
of course it would mean more code in the compiler, so it might not be worth it.)

-- 
Brent Royal-Gordon
Architechies

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