date:20170407

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

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

2017-04-07 Thread Brent Royal-Gordon via swift-evolution

> 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. 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 it's at 
> the root of the file or nested inside something else.
> 
> I really believe that even though this is kind of painful for everyone, it's 
> worth spending time to figure out a solution that satisfies most

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

> On Apr 6, 2017, at 11:01 AM, Brad Hilton via swift-evolution 
>  wrote:
> 
> How about Person.name.get / Person.name.set for getter/setter references.

We don't really want getter/setter references; we want one instance which 
represents the whole property and (if writable) can be used to modify it 
in-place if it's a value type.

-- 
Brent Royal-Gordon
Architechies

___
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

2017-04-07 Thread Brent Royal-Gordon via swift-evolution

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md

First of all, to be clear: although my name is on this proposal, it's there
because I worked on it last year when we were exploring other approaches. I
haven't worked on this version of the proposal and wasn't aware that it was up
for review until the announcement went out. So the below is just my opinion; it
does not represent the opinion of the other authors, and I haven't even talked
to them about it. So don't take this as "even the authors aren't totally happy
with this proposal". :^)

> On Apr 6, 2017, at 12:35 PM, Joe Groff via swift-evolution
> wrote:
>
> • What is your evaluation of the proposal?

I think that, if we want to do something in the style of Python's multiline
string literals, this proposal specifies a good design for them. It addresses
one of the main problems with them in Python—the fact that they typically have
to be flush against the left margin—and, although we might want to tighten the
description of the de-indenting algorithm, I think its proposal in this area is
basically the right thing to do. Others have argued that we should use a
#keyword or special syntax for this, but I don't think that's the right move;
we should always have de-indenting on, because you usually want it, and when
you don't, you can easily "turn it off" by positioning the delimiter so it
infers zero indentation.

Specifically, here are the rules I would specify for indentation:

— If the leading delimiter is at the end of its line, *and* the characters
between the trailing delimiter and the newline before it consist entirely of
zero or more horizontal whitespace characters, the literal uses de-indenting.
—If one of these conditions is true but not the other, we may want to
emit a warning.

— If a literal uses de-indenting:
1. The one newline after the leading delimiter is removed.
2. The whitespace on the last line is removed.
3. Each line is compared to the whitespace removed from the last line.
The largest common prefix of characters that are exact matches for the
whitespace removed from the last line are removed.
— If we only matched a prefix of the last line's whitespace,
but not all of it, we should emit a warning—*especially* if the non-matching
character was a whitespace character, but not the one we expected.

So, for instance, this code (⎵ = space, ⇥ = tab, ↵ = newline):

"""↵
Foo↵
⎵⎵⇥Bar↵
"""

Creates a literal with these contents (and probably a warning on the "Bar"
line):

Foo↵
⇥Bar↵

However, this code (with non-whitespace before the trailing `"""`):

"""↵
Foo↵
⎵⎵⇥Bar"""

Would be:

↵
Foo↵
⎵⎵⇥Bar

And this code (with no newline after the leading `"""`) :

"""Foo↵
⎵⎵⇥Bar↵
"""

Would be:

Foo↵
⎵⎵⇥Bar↵

Finally, if you escape a newline, the newline should not be included in the
string, but de-indenting should still happen. So this string:

"""↵
Foo\↵
⎵⎵⇥Bar\↵
"""

Becomes this (plus a warning for the mismatched indentation):

Foo↦Bar

* * *

However, I'm not sure Python-style quoting is our best alternative. But that's
very much a matter of opinion, because there's no knockout winner in this area.

Basically, every multiline string literal design I'm aware of has at least two
of these three weaknesses:

1. It doesn't help you with strings which themselves contain quote
marks (and, thus, you have to backslash them).

2. There's little redundancy in the syntax, which makes parsing
difficult, particularly when code is incomplete or out of context. Basically,
at any point in the code, you might be in a multiline string literal or you
might be in actual code, and the only way to know which is to look at the
entire file before that point. And that assumes the code is well-formed. If
someone forgets—or hasn't yet typed—a closing `"""`, you can tell that one of
the multiline strings in the file is unclosed, but it's not clear which one.
You end up applying a heuristic: It's *probably* the one before where you start
getting syntax errors from the "code" you're parsing. But that heuristic can be
wrong, particularly if you have Swift code that's generating Swift code.

3. Conventional string literal syntax has you place the full content of
the string in the place where it will go in the expression. That's fine for
short strings, but when you start looking at long multiline strings, all that
extra content makes the expression difficult to read. It's like having a
hundred-word parenthetical in the middle of a sentence: By the time it's
finished,

[swift-evolution] [Review] SE-0166: Swift Archival & Serialization

2017-04-07 Thread Robert Bennett via swift-evolution

Review of SE-0166 "Swift Archival & Serialization: 
"https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
 


This is an amazing proposal. I have one question about the CodingKey protocol, 
though. It feels strange to provide two ways to access keys, String for 
convenience/clarity and Int for performance, and to have those both floating 
around when only at most one will be used by an Encoder. It's very likely I'm 
missing something here (certainly I haven't thought about this as much as the 
authors of the proposal) but would it make more sense to write CodingKey like 
this?

public protocol CodingKey {
associatedtype Key

var value: Key { get }

init?(value: Key)
}

For any enum conforming to CodingKey, the compiler can still generate the 
implementations of those methods using String as Key, although I don't see why 
it would when using Int is more performant. It might also be necessary to have 
a protocol CodingKeyKeyProtocol (yech) to constrain the Key type — 
associatedtype Key: CodingKeyKeyProtocol — to something that can be used as an 
Encoder/Decoder key. It's possible that Hashable is already sufficient for this 
protocol. This would allow more flexible custom types conforming to CodingKey, 
although I'm not sure if that flexibility is needed. I'm also not sure anything 
aside from Int is needed, in which case the associatedtype could be removed and 
Key replaced with Int.



What is your evaluation of the proposal?
+1000

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

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

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

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
Read the whole proposal, did my best to understand it but it's a lot to digest.

___
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

2017-04-07 Thread Jakub Suder via swift-evolution

> 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:

1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate'
back to 'private'

2) Rename 'fileprivate' to something more friendly (I liked the 'local'
suggestion that Vladimir made today)

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 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 it's
at the root of the file or nested inside something else.

I really believe that even though this is kind of painful for everyone,
it's worth spending time to figure out a solution that satisfies most of us
and makes the language clearer and friendlier in the long term, even if it
means breaking compatibility again. Do we want to be stuck with an
imperfect solution 10 years from now, because we didn't want to do this
last breaking change now?


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

I think almost everyone here agrees it is significant.


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

This is a difficult question. IMHO it would definitely fit much better with
the direction of Swift if we bit the bullet and did whatever we agree will
make the language simpler and better long term, regardless how many changed
lines in git this will cause when Swift 4 is released.


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

I've used many languages, but I think in none of them it was a common thing
(or even a possibility) to split types into several blocks like we do in
Swift with extensions, so the main issue we're talking about didn't exist
there. In Ruby you can kind of do the same thing with modules - if you have
a private method in a module, you can access it from methods in the main
type, even if they're defined in a different file. (But Ruby isn't very
strict about access control in general, e.g. it allows you to call private
methods on any object via #send).


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

I've read or skimmed through most of the messages in the recent threads
about this and the last proposal.

Disclaimer: I have very little experience with Swift 3 (but plenty with
Swift 2.x).

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

2017-04-07 Thread Jordan Rose via swift-evolution


> On Apr 7, 2017, at 04:18, Gwendal Roué via swift-evolution 
>  wrote:
> 
> - the private/fileprivate qualifier used not to be a intrinsic property of an 
> object (because one had to move from private to fileprivate as soon as an 
> extension was added). Now private/fileprivate can be made meaningful, and 
> above all *stable*. A scenario where private is turned into a fileprivate now 
> involves something called "friendship" in C++: fileprivate now reflects 
> *actual design intent*, not "shut up this stupid compiler".

I, uh, wish to object to your implication that C++ 'friend' reflects actual 
design intent in most cases. :-)

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

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

2017-04-07 Thread Ricardo Parada via swift-evolution

Thanks Shawn. 

I understand that part. I asked mostly because Nate mentioned that we cannot 
have a default closure because it would force the use of try even when the 
default closure does not throw. I do t know if that is a current bug or feature 
to allow changing the default in the future to a closure that throws:

>>> https://bugs.swift.org/browse/SR-2979

Thanks. 

> On Apr 6, 2017, at 10:12 PM, Shawn Erickson  wrote:
> 
> They rethrow which is IMHO perfect for this. If the closure throws then the 
> outer functions throws (e.g. requires try). This allows folks that have a 
> need to throw if they want without forcing it on everyone.
> 
>> On Thu, Apr 6, 2017 at 6:53 PM Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>> How important is it that the closure be allowed to throw when resolving 
>> collisions?  In my use cases merging dictionaries he resolving of the 
>> collisions is always relatively simple.  Shouldn’t they be as below maybe?
>> 
>> /// Creates a new dictionary using the key/value pairs in the given 
>> sequence,
>> /// using a combining closure to determine the value for any duplicate 
>> keys.
>> init(
>> merging keysAndValues: S,
>> resolvingCollisionsWith combine: (Value, Value) -> Value
>> ) where S.Iterator.Element == Element
>> 
>> /// Merges the key/value pairs in the given sequence into the dictionary,
>> /// using a combining closure to determine the value for any duplicate 
>> keys.
>> mutating func merge(
>> _ other: S,
>> resolvingCollisionsWith combine: (Value, Value) -> Value
>> ) where S.Iterator.Element == Element
>> /// Returns a new dictionary created by merging the key/value pairs in 
>> the
>> /// given sequence into the dictionary, using a combining closure to 
>> determine
>> /// the value for any duplicate keys.
>> func merged(
>> with other: S,
>> resolvingCollisionsWith combine: (Value, Value) -> Value
>> ) -> [Key: Value] where S.Iterator.Element == Element
>> 
>> 
>> 
 On Apr 6, 2017, at 12:51 PM, Nate Cook via swift-evolution 
  wrote:
 
> On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
>   • What is your evaluation of the proposal?
 
 (As a meta issue, I'm not sure I like the grab-bag review style; I'm 
 finding this proposal a little bit difficult to navigate.)
 
 Sequence-based initializer and merging initializer
 
 Good idea, but I think these two are redundant with each other, and I 
 don't think "merging" is an accurate way to describe what the second one 
 does. (`merging` would suggest to me that it was combining several 
 dictionaries or lists, not combining conflicting elements.) I'd suggest a 
 single initializer along the lines of:
 
init(_ keysAndValues: S, correctingConflictsBy 
 resolveConflict: (Value, Value) throws -> Value = { fatalError("Duplicate 
 values \($0) and \($1)") }) rethrows
where S.Iterator.Element == (key: Key, value: Value)
>>> 
>>> 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
>>> 
 Merging methods
 
 Good idea, but I'm not a fan of the `mergingValues:` label. I would 
 suggest the same `correctingConflictsBy resolveConflict:` label I 
 suggested for the previous method—possibly including the default value. I 
 also think `merge(_:correctingConflictsBy:)`'s first parameter should be 
 labeled `with`, just as the `merged` variant is.
 
 I wonder if we might also want a method that copies the Dictionary, but 
 with a single key added/removed/changed:
 
func withValue(_ value: Value?, forKey key: Key) -> [Key: Value]
 
 Key-based subscript with default value
 
 I like the functionality, but not way this proposal does it. I don't like 
 having the default value be a labeled parameter to the subscript, because 
 it isn't used to locate the value. However, I can't come up with a better 
 syntax without adding language features. What I'd like to do is make it 
 possible to assign through `??`:
 
frequencies[c] ?? 0 += 1
 
 But that would require either that we support `inout` functions, or that 
 `??` become magic

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

2017-04-07 Thread Brent Royal-Gordon via swift-evolution

> On Apr 7, 2017, at 2:15 PM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> I don't necessarily think that the concept is a bad idea, but I think that 
> the interaction of Swift features facilitates poor coding decisions. For 
> example, the proposal interpolates an `author` variable straight into an XML 
> document, and suggests doing the same to JSON strings. To me, this shows that 
> an important use case of the feature is to format payloads in a way that is 
> known to cause vulnerabilities.

I don't know if it will be reviewed for Swift 4, let alone be accepted, but I 
have a proposal in for a revised string interpolation protocol. One of the 
major use cases I considered was types which provided safe interpolation for 
things like markup languages and JSON. So, for instance, if you wrote this:

let xml: XMLString = """

\(author)
XML Developer's Guide
Computer
44.95
2000-10-01
An in-depth look at creating applications with 
XML.

"""

XMLString could escape `author` by default, unless it were itself an 
`XMLString` or you wrote the interpolation as `\(raw: author)`. And of course, 
this being Swift, `XMLString` would not necessarily have to be stated 
explicitly; it could come from being concatenated to an `XMLString`, passed in 
an `XMLString` parameter, or assigned to an `XMLString` property.

So I think this particular concern is orthogonal to the question of supporting 
multiline strings. Escaping safety is possible—it's just a separate feature.

-- 
Brent Royal-Gordon
Architechies

___
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

2017-04-07 Thread Félix Cloutier via swift-evolution

> What is your evaluation of the proposal?

-1, approximately.

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

I don't necessarily think that the concept is a bad idea, but I think that the 
interaction of Swift features facilitates poor coding decisions. For example, 
the proposal interpolates an `author` variable straight into an XML document, 
and suggests doing the same to JSON strings. To me, this shows that an 
important use case of the feature is to format payloads in a way that is known 
to cause vulnerabilities.

Of course, you can already shoot yourself in the foot that way with short 
strings, but at least, it looks ugly. Come up with a solution that looks better 
and people will stop using the ugly one. The long string version looks good 
despite being dangerous, and I think that it would compete with safe efforts.

You can also say that it's the developer's responsibility to make sure that you 
don't misuse it. I disagree. I think that SQL injections and the like have 
caused enough damage that it's time to change attitudes.

To be clear, I wouldn't be opposed to large strings that can't interpolate (but 
I don't think that they would be extremely useful).

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

I think that it's a secondary concern. There are better, type-safe, and not 
much more cumbersome ways to create XML and JSON documents that don't open 
careless developers to injection vulnerabilities, which are much more 
Swift-like ways to solve that problem. I would rather have the community work 
on that kind of solution than to make strings look like the right tool.

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


If you remove interpolation support from long strings, they aren't particularly 
compelling anymore. I use long strings in Python for documentation and not much 
else; but Swift uses comments for documentation. There are just not that many 
places where you need long strings outside of quick-and-dirty payload 
formatting, and printing your --help message (assuming that the community 
doesn't come up with a great option parsing library, if that doesn't already 
exist).

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

I've done enough reading to know that my opinion is unpopular. :)

> Le 6 avr. 2017 à 12:35, Joe Groff via swift-evolution 
>  a écrit :
> 
> 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 well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -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] [Review] SE-0168: Multi-Line String Literals

2017-04-07 Thread David Waite 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. I don’t feel this properly solves all the issues of multiline strings. 
Indeed, I think the baked-in whitespace-stripping would complicate or preclude 
its usage in some scenarios.

Languages with multi-line string primitives typically have to bake in multiple 
approaches and/or behavioral modifiers to meet all the use cases. This appears 
to aim for a very particular behaviors with regards to formatting and 
whitespace, without proposing ways to support other behaviors. As the 
motivation section did not attempt to summarize the expressed desired 
behaviors, the swift-evolution threads are the best place to go to determine 
the conflicting sets of desired behaviors.

Likewise, it feels underspecified. For example, the specification does not 
detail what the behavior is of

let a = """foobar"""  // legal? equivalent of "foobar"? Would you get a warning?
let b = "" // legal? equivalent of "" ? Would you get a warning?
let c = """multi-line strings are escaped using the """ (triple-quote) 
characters""" // legal? does the triple quote need to be escaped?

I feel that some of the alternate approaches were discarded for rather 
arbitrary reasons as well(regex-based syntax formatter issues?), and suspect 
this approach was chosen for its ease of copy/pasting in text. However, I 
understand the desire to have just a single proposed approach - I just don't 
feel thats realistic for the wide variety of requirements expressed in 
discussions.

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

Absolutely. I feel however that discussions have not resulted in a single 
approach being deemed more appropriate than others.

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

I don't think so as specified - it simply does not cover enough of the given 
desired functionality.

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

This seems closest to how multi-line strings work in python (which some refer 
to as its heredoc support). However, python multi-line strings both are simpler 
by default and have more optional complexity:

- Multi-line strings in python by default include the initial newline and all 
indentation. There is a syntax """\ for indicating that the newline following 
the starting quotes 
- As a more general pattern, each line of a multi-line string ending in a 
backslash squelches the newline character
- Python does not (from my memory) have any way to eliminate indentation. The 
expectation is that the embedded text starts at column 0.

Python includes other methods to do strings across multiple lines, such as:
- ("foo"  "bar") # results in "foobar", the strict concatenation of 
the two strings
- "foo\bar"  # also results in foobar, as the newline is squelched by 
the backslash before the newline.

I'm personally most familiar with the support in Ruby, which has an even more 
comprehensive set of options and controls - single and double quotes as well as 
custom quoting, controls over expression and escape interpretation, as well as 
inline HEREDOCs defined with optional leading whitespace elimination and END 
DATA blocks.

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

In-depth study.

> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -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] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

2017-04-07 Thread Rod Brown via swift-evolution


> On 7 Apr 2017, at 9:10 am, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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?
It pains me to say this: -1. I think this is a bandaid solution.

Swift had a simple module based access control. Was it the right one? 
Debatable. But at least the story was consistent and it worked. Then Scoped 
access came along rather than trying to really flesh out the problem of access 
control, and for some stupid reason, we chose to make private scoped and 
introduce a terrible access modifier for what was "private" before.

We don't have submodules yet. When they come, we need to flesh this stuff out, 
and deal with concepts like "protected" ect rather than ignoring them like we 
seem to be doing.

I think reverting the behaviour (in the previous proposal) was right short 
term, but not long term, and created unnecessary churn. But the fight for Swift 
source stability needs to take a back seat to getting this right in the Swift 5 
timeline and we need to accept that some level of pain will come because we 
need to rework this stuff to get it right for the future.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. We need to sort out access control. The current solution seems ill 
equipped for the future.

> Does this proposal fit well with the feel and direction of Swift?
No. It is a bandaid solution which confuses the point of 'private'. Is it 
scoped, or a weird mid-way between a scoped and fileprivate?

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Some with access control, and our system seems broken.

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

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift


> On Apr 7, 2017, at 12:01 PM, John McCall  wrote:
> 
>> On Apr 7, 2017, at 2:50 PM, Joe Groff  wrote:
>>> On Apr 7, 2017, at 11:48 AM, John McCall  wrote:
>>> 
 On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
>> 
>> 
>>> On Apr 6, 2017, at 9:46 PM, John McCall  wrote:
>>> 
 On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
> On Apr 6, 2017, at 20:37 , John McCall  wrote:
> 
>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>>  wrote:
>> I tend to dislike the backslash as well, but can't suggest a good 
>> alternative.
>> 
>> Does any of this allow for operations within the key path? e.g. 
>> Department.employees.@sum.salary?
> 
> You can express things like this in the feature as proposed using 
> subscripts:
> 
> extension Collection {
> subscript(summing path: KeyPath) -> T {
> var sum: T = 0
> for let elt in self {
> sum += elt[keyPath: path]
> }
> return sum
> }
> }
 
 I'm just remembering how AppKit/Cocoa lets you do things like this in 
 a very expressive way. Your proposal seems a bit cumbersome. Maybe 
 when we have custom annotations, they can be extended to use within 
 key paths.
>>> 
>>> I'm not seriously endorsing this exact spelling.  It would be much 
>>> better to be able to write something like:
>>> \Department.employees.sum(of: \.salary)
>>> However, since "sum" would presumably be a method on Collection, I 
>>> think this would have to be a future extension to the proposal, and the 
>>> overall thing might have to be a function rather than a key path 
>>> because it would no longer have identity.
>> 
>> Also, less clever but potentially easier to reason about:
>> 
>>  extension Array where Element == Employee {
>>var sumOfSalary: Double {
>>  return // ...
>>}
>>  }
>> 
>> If you can express it in a computed property, you can refer to it via a 
>> key path:
>> 
>>  \Department.employees.sumOfSalary
> 
> Yeah, you can, but that's definitely an expressivity hit.
 
 True, but there are some benefits to requiring a subscript/property rather 
 than an arbitrary closure, particularly that it gives the operation a 
 stable identity and structure so the key path can still be equated/hashed 
 and (eventually) iterated through.
>>> 
>>> Right, I think if you add a method to the chain, the result definitely has 
>>> to be a function rather than a key path.  The idea is that you basically 
>>> decompose:
>>> 
>>> \Base.A.B.C
>>> 
>>> into
>>> ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
>>> result(C)
>>> 
>>> except that if all of the components A, B, and C are just properties or 
>>> applied subscripts you can make it a KeyPath instead, which can 
>>> then contextually devolve into a function.
>> 
>> It seems to me that method references (non-mutating ones, at least) could 
>> still be treated as read-only key path components. There's not much more 
>> than syntax as a difference between a nonmutating method and get-only 
>> property or subscript. The method decl is still something we can ascribe 
>> identity to.
> 
> That's true.  My concern with ascribing identity to methods is that we have a 
> number of features around methods — overloading, default arguments, various 
> kinds of polymorphism — that make the exact choice of declaration somewhat 
> imprecise.  Should it be a different key path if we pick a protocol 
> requirement vs. a concrete method that satisfies it?  I suppose we have that 
> specific problem with properties and subscripts as well, though.

Yeah, the restrictions on overloading properties are effectively superficial, 
since protocol extensions and library evolution still give you means to end up 
with an overloaded property name. Subscripts are already arbitrarily 
overloadable.

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

> On Apr 7, 2017, at 2:50 PM, Joe Groff  wrote:
>> On Apr 7, 2017, at 11:48 AM, John McCall  wrote:
>> 
>>> On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
 On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
  wrote:
 
> 
> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
> 
> 
>> On Apr 6, 2017, at 9:46 PM, John McCall  wrote:
>> 
>>> On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
 On Apr 6, 2017, at 20:37 , John McCall  wrote:
 
> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>  wrote:
> I tend to dislike the backslash as well, but can't suggest a good 
> alternative.
> 
> Does any of this allow for operations within the key path? e.g. 
> Department.employees.@sum.salary?
 
 You can express things like this in the feature as proposed using 
 subscripts:
 
 extension Collection {
 subscript(summing path: KeyPath) -> T {
 var sum: T = 0
 for let elt in self {
 sum += elt[keyPath: path]
 }
 return sum
 }
 }
>>> 
>>> I'm just remembering how AppKit/Cocoa lets you do things like this in a 
>>> very expressive way. Your proposal seems a bit cumbersome. Maybe when 
>>> we have custom annotations, they can be extended to use within key 
>>> paths.
>> 
>> I'm not seriously endorsing this exact spelling.  It would be much 
>> better to be able to write something like:
>> \Department.employees.sum(of: \.salary)
>> However, since "sum" would presumably be a method on Collection, I think 
>> this would have to be a future extension to the proposal, and the 
>> overall thing might have to be a function rather than a key path because 
>> it would no longer have identity.
> 
> Also, less clever but potentially easier to reason about:
> 
>   extension Array where Element == Employee {
> var sumOfSalary: Double {
>   return // ...
> }
>   }
> 
> If you can express it in a computed property, you can refer to it via a 
> key path:
> 
>   \Department.employees.sumOfSalary
 
 Yeah, you can, but that's definitely an expressivity hit.
>>> 
>>> True, but there are some benefits to requiring a subscript/property rather 
>>> than an arbitrary closure, particularly that it gives the operation a 
>>> stable identity and structure so the key path can still be equated/hashed 
>>> and (eventually) iterated through.
>> 
>> Right, I think if you add a method to the chain, the result definitely has 
>> to be a function rather than a key path.  The idea is that you basically 
>> decompose:
>> 
>> \Base.A.B.C
>> 
>> into
>> ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
>> result(C)
>> 
>> except that if all of the components A, B, and C are just properties or 
>> applied subscripts you can make it a KeyPath instead, which can then 
>> contextually devolve into a function.
> 
> It seems to me that method references (non-mutating ones, at least) could 
> still be treated as read-only key path components. There's not much more than 
> syntax as a difference between a nonmutating method and get-only property or 
> subscript. The method decl is still something we can ascribe identity to.

That's true.  My concern with ascribing identity to methods is that we have a 
number of features around methods — overloading, default arguments, various 
kinds of polymorphism — that make the exact choice of declaration somewhat 
imprecise.  Should it be a different key path if we pick a protocol requirement 
vs. a concrete method that satisfies it?  I suppose we have that specific 
problem with properties and subscripts as well, though.

John.
___
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

2017-04-07 Thread Matthew Johnson via swift-evolution


> On Apr 7, 2017, at 1:50 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Apr 7, 2017, at 11:48 AM, John McCall  wrote:
>> 
>>> On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
 On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
  wrote:
 
> 
> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
> 
> 
>> On Apr 6, 2017, at 9:46 PM, John McCall  wrote:
>> 
>>> On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
 On Apr 6, 2017, at 20:37 , John McCall  wrote:
 
> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>  wrote:
> I tend to dislike the backslash as well, but can't suggest a good 
> alternative.
> 
> Does any of this allow for operations within the key path? e.g. 
> Department.employees.@sum.salary?
 
 You can express things like this in the feature as proposed using 
 subscripts:
 
 extension Collection {
 subscript(summing path: KeyPath) -> T {
 var sum: T = 0
 for let elt in self {
 sum += elt[keyPath: path]
 }
 return sum
 }
 }
>>> 
>>> I'm just remembering how AppKit/Cocoa lets you do things like this in a 
>>> very expressive way. Your proposal seems a bit cumbersome. Maybe when 
>>> we have custom annotations, they can be extended to use within key 
>>> paths.
>> 
>> I'm not seriously endorsing this exact spelling.  It would be much 
>> better to be able to write something like:
>> \Department.employees.sum(of: \.salary)
>> However, since "sum" would presumably be a method on Collection, I think 
>> this would have to be a future extension to the proposal, and the 
>> overall thing might have to be a function rather than a key path because 
>> it would no longer have identity.
> 
> Also, less clever but potentially easier to reason about:
> 
>   extension Array where Element == Employee {
> var sumOfSalary: Double {
>   return // ...
> }
>   }
> 
> If you can express it in a computed property, you can refer to it via a 
> key path:
> 
>   \Department.employees.sumOfSalary
 
 Yeah, you can, but that's definitely an expressivity hit.
>>> 
>>> True, but there are some benefits to requiring a subscript/property rather 
>>> than an arbitrary closure, particularly that it gives the operation a 
>>> stable identity and structure so the key path can still be equated/hashed 
>>> and (eventually) iterated through.
>> 
>> Right, I think if you add a method to the chain, the result definitely has 
>> to be a function rather than a key path.  The idea is that you basically 
>> decompose:
>> 
>> \Base.A.B.C
>> 
>> into
>> ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
>> result(C)
>> 
>> except that if all of the components A, B, and C are just properties or 
>> applied subscripts you can make it a KeyPath instead, which can then 
>> contextually devolve into a function.
> 
> It seems to me that method references (non-mutating ones, at least) could 
> still be treated as read-only key path components. There's not much more than 
> syntax as a difference between a nonmutating method and get-only property or 
> subscript. The method decl is still something we can ascribe identity to.

I like where you guys are going with this!

> 
> -Joe
> ___
> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift


> On Apr 7, 2017, at 11:48 AM, John McCall  wrote:
> 
>> On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
>>> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
>>>  wrote:
>>> 
 
 On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
 
 
> On Apr 6, 2017, at 9:46 PM, John McCall  wrote:
> 
>> On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
>>> On Apr 6, 2017, at 20:37 , John McCall  wrote:
>>> 
 On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
  wrote:
 I tend to dislike the backslash as well, but can't suggest a good 
 alternative.
 
 Does any of this allow for operations within the key path? e.g. 
 Department.employees.@sum.salary?
>>> 
>>> You can express things like this in the feature as proposed using 
>>> subscripts:
>>> 
>>> extension Collection {
>>> subscript(summing path: KeyPath) -> T {
>>> var sum: T = 0
>>> for let elt in self {
>>> sum += elt[keyPath: path]
>>> }
>>> return sum
>>> }
>>> }
>> 
>> I'm just remembering how AppKit/Cocoa lets you do things like this in a 
>> very expressive way. Your proposal seems a bit cumbersome. Maybe when we 
>> have custom annotations, they can be extended to use within key paths.
> 
> I'm not seriously endorsing this exact spelling.  It would be much better 
> to be able to write something like:
> \Department.employees.sum(of: \.salary)
> However, since "sum" would presumably be a method on Collection, I think 
> this would have to be a future extension to the proposal, and the overall 
> thing might have to be a function rather than a key path because it would 
> no longer have identity.
 
 Also, less clever but potentially easier to reason about:
 
extension Array where Element == Employee {
  var sumOfSalary: Double {
return // ...
  }
}
 
 If you can express it in a computed property, you can refer to it via a 
 key path:
 
\Department.employees.sumOfSalary
>>> 
>>> Yeah, you can, but that's definitely an expressivity hit.
>> 
>> True, but there are some benefits to requiring a subscript/property rather 
>> than an arbitrary closure, particularly that it gives the operation a stable 
>> identity and structure so the key path can still be equated/hashed and 
>> (eventually) iterated through.
> 
> Right, I think if you add a method to the chain, the result definitely has to 
> be a function rather than a key path.  The idea is that you basically 
> decompose:
> 
>  \Base.A.B.C
> 
> into
>  ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
> result(C)
> 
> except that if all of the components A, B, and C are just properties or 
> applied subscripts you can make it a KeyPath instead, which can then 
> contextually devolve into a function.

It seems to me that method references (non-mutating ones, at least) could still 
be treated as read-only key path components. There's not much more than syntax 
as a difference between a nonmutating method and get-only property or 
subscript. The method decl is still something we can ascribe identity to.

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

> On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
>> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
>>> 
>>> 
 On Apr 6, 2017, at 9:46 PM, John McCall  wrote:
 
> On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
>> On Apr 6, 2017, at 20:37 , John McCall  wrote:
>> 
>>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>>>  wrote:
>>> I tend to dislike the backslash as well, but can't suggest a good 
>>> alternative.
>>> 
>>> Does any of this allow for operations within the key path? e.g. 
>>> Department.employees.@sum.salary?
>> 
>> You can express things like this in the feature as proposed using 
>> subscripts:
>> 
>> extension Collection {
>> subscript(summing path: KeyPath) -> T {
>> var sum: T = 0
>> for let elt in self {
>> sum += elt[keyPath: path]
>> }
>> return sum
>> }
>> }
> 
> I'm just remembering how AppKit/Cocoa lets you do things like this in a 
> very expressive way. Your proposal seems a bit cumbersome. Maybe when we 
> have custom annotations, they can be extended to use within key paths.
 
 I'm not seriously endorsing this exact spelling.  It would be much better 
 to be able to write something like:
 \Department.employees.sum(of: \.salary)
 However, since "sum" would presumably be a method on Collection, I think 
 this would have to be a future extension to the proposal, and the overall 
 thing might have to be a function rather than a key path because it would 
 no longer have identity.
>>> 
>>> Also, less clever but potentially easier to reason about:
>>> 
>>> extension Array where Element == Employee {
>>>   var sumOfSalary: Double {
>>> return // ...
>>>   }
>>> }
>>> 
>>> If you can express it in a computed property, you can refer to it via a key 
>>> path:
>>> 
>>> \Department.employees.sumOfSalary
>> 
>> Yeah, you can, but that's definitely an expressivity hit.
> 
> True, but there are some benefits to requiring a subscript/property rather 
> than an arbitrary closure, particularly that it gives the operation a stable 
> identity and structure so the key path can still be equated/hashed and 
> (eventually) iterated through.

Right, I think if you add a method to the chain, the result definitely has to 
be a function rather than a key path.  The idea is that you basically decompose:

  \Base.A.B.C

into
  ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
result(C)

except that if all of the components A, B, and C are just properties or applied 
subscripts you can make it a KeyPath instead, which can then 
contextually devolve into a function.

John.
___
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

2017-04-07 Thread Peter Dillinger via swift-evolution

• What is your evaluation of the proposal?



-1, for two reasons:



(from 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034897.html
 and follow-up)

First, having the same beginning and ending delimiter, with no continuation 
character, makes it very easy for a syntax highlighter or tokenizer to get 
"inverted" in what it believes is string content and what it believes is code.  
I have seen this happen due to a subtle bug in a Python syntax highlighter, and 
it's incredibly frustrating that a single misinterpretation can "invert" the 
highlighting of the rest of the file.  It's also possible that future syntactic 
enhancements to Swift could lead to inversion in a correct highlighter for an 
older version of Swift reading a newer Swift file.



When working with an online tokenizer / highlighter while editing your code, 
the proposed design maximizes what needs to get re-parsed as """ are added and 
removed.  Sure, automatic insertion of close-""" helps, but not fully.



Under this proposal, you might say, "you can assume it's code again if the 
indentation decreases too much."  There are two problems with that.  First, the 
required indentation is determined by the line with the close """, so there's 
no way to detect a violation until you get there.  Second, the user might have 
intended that as part of the quoted text but messed up the formatting.  In that 
case, if you assume resumption of code, the actual close """ will be 
interpreted as an open """ and you have inversion anyway.  So it's not clear 
that you've decreased the likelihood of inversion.





Second, as others have pointed out, the proposal is quite lacking in specifics. 
 For example, it's not clear if characters are allowed on the same line after 
an open """.  If not allowed, a syntax highlighter could heuristically 
distinguish open and close """ based on non-whitespace on the same line (just 
not the case of """ on a line with only whitespace - perhaps that should be 
disallowed).  This could be helpful for recovery in tokenization/highlighting, 
but this proposal is unclear.





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



Yes.  Especially since unused string expressions are not a compilation error, 
using + to construct long strings spanning multiple lines is hazardous.

(See 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034472.html
 )





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



I'm not satisfied this proposal has sufficiently addressed issues in the 
language feature being mostly inherited here.





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



I have experience with some tools supporting Python and we had issues with 
syntax highlighting ending up "inverted" because """ strings have the same 
beginning and ending delimiter.





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



A quick read, and participation in the discussion.  I don't see any evidence 
the proposal took into account recent discussion:



https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034856.html


--
Peter Dillinger, Ph.D.
Software Engineering Manager, Coverity Analysis, Software Integrity Group | 
Synopsys
www.synopsys.com/software



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

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


> On Apr 6, 2017, at 8:59 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Apr 5, 2017, at 7:56 PM, Douglas Gregor  wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
>> Swift" begins now and runs through April 9, 2017. The revised proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> 
> Something came to mind that I wanted to record, even though it's not directly 
> addressed by this proposal.
> 
> I know that one future direction here is that key paths ought to be 
> equatable, serializable, etc.  Serialization in particular is something that 
> we're going to have to think about very carefully.
> 
> In general, it's really bad for deserialization to be able to call arbitrary 
> code in the program.  There is a well-known security hole in various 
> reflective deserialization libraries where they will happily call arbitrary 
> functions or constructors if they're named in the serialized data.  (Often, 
> there's some way to limit this, but you have to know to use it — so it's 
> merely the default that isn't secure, but that's no defense.)  A Swift 
> serialization library would hopefully be designed around a protocol that 
> provided a (throwing) deserializing initializer, so that (1) types have to 
> opt in to supporting deserialization and (2) deserialization doesn't call 
> completely arbitrary code.  But it's still a potential security hole if 
> deserialization can construct a key path that, when accessed, will execute 
> arbitrary code in the process.
> 
> There are other concerns as well.  It's a code-size and performance problem 
> if we have to treat every property and subscript in the program as 
> potentially used, and emit key-path metadata for them, just in case they 
> might be used by a deserialized key path.  And, of course, it potentially 
> becomes a binary compatibility problem to remove a property or subscript, 
> even a private one, if that was ever used in a key path that was serialized.  
> But the biggest concern is security.
> 
> Anyway, just a thought that shouldn't be allowed to derail this proposal.

When we design serialization behavior for key paths, I think it'd be reasonable 
to require opt-in decoration on the particular storage declarations that need 
to be encodable.

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


> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
>> 
>> 
>>> On Apr 6, 2017, at 9:46 PM, John McCall  wrote:
>>> 
 On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
> On Apr 6, 2017, at 20:37 , John McCall  wrote:
> 
>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>>  wrote:
>> I tend to dislike the backslash as well, but can't suggest a good 
>> alternative.
>> 
>> Does any of this allow for operations within the key path? e.g. 
>> Department.employees.@sum.salary?
> 
> You can express things like this in the feature as proposed using 
> subscripts:
> 
> extension Collection {
> subscript(summing path: KeyPath) -> T {
> var sum: T = 0
> for let elt in self {
>  sum += elt[keyPath: path]
> }
> return sum
> }
> }
 
 I'm just remembering how AppKit/Cocoa lets you do things like this in a 
 very expressive way. Your proposal seems a bit cumbersome. Maybe when we 
 have custom annotations, they can be extended to use within key paths.
>>> 
>>> I'm not seriously endorsing this exact spelling.  It would be much better 
>>> to be able to write something like:
>>> \Department.employees.sum(of: \.salary)
>>> However, since "sum" would presumably be a method on Collection, I think 
>>> this would have to be a future extension to the proposal, and the overall 
>>> thing might have to be a function rather than a key path because it would 
>>> no longer have identity.
>> 
>> Also, less clever but potentially easier to reason about:
>> 
>>  extension Array where Element == Employee {
>>var sumOfSalary: Double {
>>  return // ...
>>}
>>  }
>> 
>> If you can express it in a computed property, you can refer to it via a key 
>> path:
>> 
>>  \Department.employees.sumOfSalary
> 
> Yeah, you can, but that's definitely an expressivity hit.

True, but there are some benefits to requiring a subscript/property rather than 
an arbitrary closure, particularly that it gives the operation a stable 
identity and structure so the key path can still be equated/hashed and 
(eventually) iterated through.

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


> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
> 
> 
>> On Apr 6, 2017, at 9:46 PM, John McCall  wrote:
>> 
>>> On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
 On Apr 6, 2017, at 20:37 , John McCall  wrote:
 
> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>  wrote:
> I tend to dislike the backslash as well, but can't suggest a good 
> alternative.
> 
> Does any of this allow for operations within the key path? e.g. 
> Department.employees.@sum.salary?
 
 You can express things like this in the feature as proposed using 
 subscripts:
 
 extension Collection {
 subscript(summing path: KeyPath) -> T {
 var sum: T = 0
 for let elt in self {
   sum += elt[keyPath: path]
 }
 return sum
 }
 }
>>> 
>>> I'm just remembering how AppKit/Cocoa lets you do things like this in a 
>>> very expressive way. Your proposal seems a bit cumbersome. Maybe when we 
>>> have custom annotations, they can be extended to use within key paths.
>> 
>> I'm not seriously endorsing this exact spelling.  It would be much better to 
>> be able to write something like:
>> \Department.employees.sum(of: \.salary)
>> However, since "sum" would presumably be a method on Collection, I think 
>> this would have to be a future extension to the proposal, and the overall 
>> thing might have to be a function rather than a key path because it would no 
>> longer have identity.
> 
> Also, less clever but potentially easier to reason about:
> 
>   extension Array where Element == Employee {
> var sumOfSalary: Double {
>   return // ...
> }
>   }
> 
> If you can express it in a computed property, you can refer to it via a key 
> path:
> 
>   \Department.employees.sumOfSalary

Yeah, you can, but that's definitely an expressivity hit.

John.


> 
> 
> 
>> Also, I do feel obliged to note that AppKit/Cocoa's "very expressive" way of 
>> doing this is a small number of hard-coded operators, whereas even the 
>> kindof-unfortunate subscript trick would be arbitrarily extensible.
> 
> Right.
> 
>   - Doug
> 
>> John.
>> 
>> 
>>> 
>>> Thanks.
>>> 
 
 ...
 
 \Department.employees[summing: \.salary]
 
 That's not actually a good name for the subscript, but maybe there's one 
 out there.
 
 John.
 
> 
> Also, in this example:
> 
> let firstFriendsNameKeyPath = \Person.friends[0].name
> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
> 
> Can't we do without the keyPath: argument name? The compiler knows it's a 
> keypath, it would be nicer to write
> 
> let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
> 
>> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding 
>> for Swift" begins now and runs through April 9, 2017. The revised 
>> proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>> The core team’s feedback from the first review of this proposal can be 
>> viewed at:
>> 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
>> 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/0161-key-paths.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 well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>>

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

2017-04-07 Thread Vanderlei Martinelli via swift-evolution

> On Apr 7, 2017, at 8:37 AM, Jonathan Hull via swift-evolution 
>  wrote:
> I think that is why he is saying (and I agree), that ‘fileprivate’ needs to 
> be the soft-default.  That way private will mean something.

Keywords aren't completely arbitrary.  Programmers will always reach for 
'private' first, both from familiarity with other languages and because of the 
obvious contrast with 'public'.  You can teach them not to do that, but that 
then becomes something they have to specifically learn instead of something 
that comes intuitively.

> His point that this gets rid of the primary use-case of ‘private’ (over 
> ‘fileprivate’) is also extremely relevant.

That depends very much on what you put in a single file.  If you generally just 
put a single type and its extensions in a file, then yes, 'private' and 
'fileprivate' are essentially the same, other than for nested types.  If you 
put other code in the same file, 'private' remains meaningfully stronger than 
'fileprivate'.  In both cases, 'private' is reinforced as a default choice; but 
you do lose that ability to prevent extensions from directly accessing the 
stored properties of a type, which I agree is a significant loss.

John.

> 
> 
>> On Apr 7, 2017, at 4:51 AM, Gwendal Roué via swift-evolution 
>> > wrote:
>> 
>> 
>>> Le 7 avr. 2017 à 13:44, Matthew Johnson via swift-evolution 
>>> > a écrit :
>>> 
>>> No.  I believe it makes the language worse, not better.  It doesn’t address 
>>> the real problems with access control.  The largest problem is the 
>>> inability to form scopes between files and the entire module.  The problem 
>>> with `fileprivate` and `private` is a naming problem, not a semantics 
>>> problem.
>> 
>> This is the base of your argument, and I think it is wrong, considering that 
>> code is a living matter, not a static one.
>> 
>> Too many properties initially declared as `private` have to be declared 
>> `fileprivate` later, because the code is evolving. And this change is 
>> usually performed just to tame a compiler error.
>> 
>> This is why the current private/fileprivate situation is actually a 
>> semantics problem. Private is not stable enough to mean anything.
>> 
>> Gwendal Roué
>> 
>> ___
>> 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] [Review] SE-0168: Multi-Line String Literals

2017-04-07 Thread Ben Cohen via swift-evolution

> On Apr 6, 2017, at 12:35 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 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?

A firm +1. This is an important feature for a number of different use cases. I 
should note that improving ergonomics for scripting, testing, and knocking 
together quick sample code are goals in themselves, even if you feel it would 
be bad to include big gobs of string literal in “real” code – you can simply 
ignore this feature if you feel it’s inappropriate in that use case. Unlike, 
say, adding keywords, it does not expand the overall surface area of the 
language in a way that will harm existing use or be confusing to people 
encountering it for the first time.

I understand the concerns re clarifying the exact behavior. I think these are 
more assumptions that need to be explicitly documented than flaws that would 
block accepting the proposal once those clarifications are added and circulated.

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

Yes. I find myself wanting this on a regular basis.

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

Yes, and also fits well with the current focus on String improvements in Swift 
4.

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

Of the various different options from different languages, I feel this is the 
best. The syntax is lightweight, which is important. The ability to cut+paste* 
text directly is a big win over continuation quotes, which I find fiddly to 
maintain and ugly to read. I like the ability to indent, especially for 
scripting. Triple quotes are simpler than heredoc, including for new users.

*most text – I don’t think code including specific cases like including 
triple-quotes or other escaped values is a showstopper, so long as these 
exceptions are explicitly called out.

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

A fair amount.

> 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] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

I would like to see a much more coherent and simple access control system
in Swift. And since the proposal to revert `private` to what it was before
was rejected, it is better that` private` means really `private`. Then -1
for this proposal.

(I think we could learn a lot from C # in this question [and others too],
anyway.)

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

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

2017-04-07 Thread Félix Cloutier via swift-evolution

It probably depends on the positioning of the initializer. I strongly associate 
the collection initializer to the special case of UnsafeBufferPointer, 
and the result strings will probably be passed back to C at some point, where 
an embedded NUL terminates the string (inconsistently with what Swift does). As 
a Swift-first feature, parsing the whole buffer regardless of embedded NULs 
makes sense, but as an interop feature, that's almost certainly not what 
developers will be looking for.

That probably passes the bar of being reasonable, though. I'd advise 
documenting that it doesn't stop on NUL characters.

Félix

> Le 6 avr. 2017 à 17:34, Ben Cohen  a écrit :
> 
> 
>> On Apr 5, 2017, at 10:32 PM, Félix Cloutier > > wrote:
>> 
>> During the proposal phase, we asked how this would handle fixed-length 
>> strings with an optional NUL terminator. For instance, in a C `struct Foo { 
>> char name[8]; };`, `name` stops at the first \0, or at the eighth byte, 
>> whichever comes first. IIRC, Ben said that it would be handled, but I'd like 
>> to have it clarified.
>> 
>> Is it correct to assume that a UnicodeEncoding is expected to return 
>> UnicodeParseResult.emptyInput when it sees a NUL character (thus stopping 
>> before the end of the buffer if necessary)? Is it also correct to assume 
>> that if you need this functionality, you'll be looking at code like this?
>> 
>> var result = ""
>> UnicodeEncoding.parseForward(bufferPointer) { result += $0 }
>> 
> 
> 
> Hi Félix,
> 
> Having talked about it among the team, it feels like we should add an 
> initializer from a Collection of code units to this proposal.  Therefore 
> given a pointer p to some utf8 and a length n, you would write:
> 
> let b = UnsafeBuffer(start: p, count: n)
> // naming opinions on the argument labels welcomed, this is probably what I’d 
> go for...
> let s = String(b, fromEncoding: UTF8.self)
> 
> Similar to the C string inits, this would only be a repairing initializer.
> 
> Your request goes a little bit further though. For that, I would say that it 
> probably doesn’t deserve a special dedicated initializer. You could instead 
> search for the nil using index(of:):
> 
> let i = b.index(of: 0)
> let s = String(b[.. 
> Does this sound reasonable?
> 
>>> Le 5 avr. 2017 à 11:39, John McCall via swift-evolution 
>>> > a écrit :
>>> 
>>> Hello, Swift community!
>>> 
>>> The review of "SE-163: String Revision: Collection Conformance, C Interop, 
>>> Transcoding" begins now and runs through next Tuesday, April 11th. The 
>>> proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.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/0155-normalize-enum-case-representation.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 well with the feel and direction of Swift?
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at 
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> 
>>> Thank you,
>>> 
>>> John McCall
>>> Review Manager
>>> ___
>>> 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

2017-04-07 Thread Víctor Pimentel Rodríguez via swift-evolution

> On Apr 7, 2017, at 8:32 AM, Jonathan Hull via swift-evolution 
>  wrote:
>> On Apr 7, 2017, at 3:51 AM, Goffredo Marocchi > > wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On 7 Apr 2017, at 09:56, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
 What is your evaluation of the proposal?
>>> 
>>> Strong -1.  Just rename ‘fileprivate’ to be less annoying.
>> 
>> So, we keep being told it won't happen and our current Bly suggestion 
>> discussing this proposal cannot be to just keep asking for it, can it?
> 
> We were told we can’t do the double rename.  I believe renaming ‘fileprivate’ 
> is still on the table (or at least it will have to be at some point when we 
> consider submodules).

We could, in some future update, introduce a new keyword and deprecate 
'fileprivate'.  Whether this impacts submodules really remains to be seen — 
there are about twenty different things that people mean by "submodules", and 
it's not at all clear that we should be aiming for a sub-file granularity 
instead of a super-file granularity.  I understand that some people just seem 
personally offended by the existence of files, though.

We will not be changing the meaning of 'private' after Swift 4.

John.

> 
> If renaming ‘fileprivate’ is truly off the table, we should definitely NOT 
> accept this proposal (for all the reasons I and others have stated).  We 
> should keep the status quo, horrible as it may be.
> ___
> 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] Type-based ‘private’ access within a file

On Fri, Apr 7, 2017 at 5:47 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> Setting aside source compatibility concerns for a brief moment, is there
> anyone who would choose this approach over reverting SE-0025, renaming the
> current modifier, or maintaining the current access modifiers?  If this is
> nobody’s first choice that should be a big cautionary sign.
>

After migrating several codebases, I think the best for me would be moving
in the direction explained in this proposal. For these reasons:

- In the migration to Swift 4, my team's code would work right away,
without any changes at all (well, at least because of this proposal).
- When my team have the time to do it, we can replace all of our
fileprivate usages for private ones, since we just use them to share
properties between same-file extensions.

So at the end this proposal will impact my team very little at first, we
will have less merge issues (hello Swift 3) and eventually the code will
be, for us, cleaner and easier to read. All the other proposals will not
give my team this smooth transition.

And, IMHO, I think that having access to really private details between two
types probably leads to programmer errors, so my next preferred step after
this one would be removing fileprivate altogether.

But I understand that Swift as a language must be gradually shaped.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file

2017-04-07 Thread Matthew Johnson via swift-evolution

> On Apr 7, 2017, at 10:32 AM, BJ Homer  wrote:
> 
> 
> On Apr 7, 2017, at 9:23 AM, Matthew Johnson  > wrote:
> 
>> The most common thing is to have some stored properties that are private and 
>> include a handful of fileprivate (or higher) methods that operate on these 
>> properties in the type declaration.  All members that don’t need direct 
>> access to these properties are placed in extensions specifically to prevent 
>> the direct access to stored properties which they don’t need.  This 
>> minimizes the lines of code with access to such properties.
> 
> Is there a reason this could not be implemented by putting all the sensitive 
> stored properties in a separate type from the rest of the code?

This has already been discussed extensively in the threads.  The problem with 
this approach under the current proposal is that there is no way to hide that 
type or its members from the rest of the file.  It can be extended anywhere in 
the file which means the kind of encapsulation intended by users of scoped 
access is not really available.  This is a kind of half-solution that relies on 
not extending the separate type and therefore offers a weaker guarantee while 
requiring extra boilerplate.  It is also a kind of half-solution for those who 
wanted to revert SE-0025.  

Setting aside source compatibility concerns for a brief moment, is there anyone 
who would choose this approach over reverting SE-0025, renaming the current 
modifier, or maintaining the current access modifiers?  If this is nobody’s 
first choice that should be a big cautionary sign.  It would indicate that this 
is the result of “design by committee” where nobody really likes it and it is 
at best the closest to consensus we could get.  I don’t think “this is the best 
we can do because of source compatibility” is an appropriate justification for 
accepting this kind of solution.  If source compatibility is such a paramount 
concern we should probably maintain the status quo or keep looking for a 
better, more source-compatible solution in the future (probably Swift 5).

I think one of the goals for Swift is to try and avoid that kind of decision 
making.  If I’m going to be dissatisfied with part of the language I would 
rather it be for some other reason than that SE has caused the language to 
suffer from “design by committee” kinds of flaws.

> 
> -BJ

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

Re: [swift-evolution] Type-based ‘private’ access within a file


> On Apr 7, 2017, at 9:23 AM, Matthew Johnson  wrote:
> 
> The most common thing is to have some stored properties that are private and 
> include a handful of fileprivate (or higher) methods that operate on these 
> properties in the type declaration.  All members that don’t need direct 
> access to these properties are placed in extensions specifically to prevent 
> the direct access to stored properties which they don’t need.  This minimizes 
> the lines of code with access to such properties.

Is there a reason this could not be implemented by putting all the sensitive 
stored properties in a separate type from the rest of the code?

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

Re: [swift-evolution] Type-based ‘private’ access within a file

> It does not remove the scoped access control, it only relaxes it in 
> extensions to types in the same file.

Many of the use cases for scoped access given during the review of SE-0159 
specifically related to restricting access between extensions in the same file. 
I don't personally use this, but it seems it is definitely used by some 
developers. 

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

Re: [swift-evolution] Type-based ‘private’ access within a file

2017-04-07 Thread Matthew Johnson via swift-evolution


> On Apr 7, 2017, at 9:48 AM, David Hart via swift-evolution 
>  wrote:
> 
>> 
>> On 7 Apr 2017, at 15:41, BJ Homer via swift-evolution 
>> > wrote:
>> 
>> -0.5
>> 
>> SE-0159 was rejected because it was determined that some developers are 
>> actively using strongly-scoped access control. This proposal removes that 
>> strong scoping, so I do not see how we can reasonably reject that proposal 
>> but accept this one.
> 
> I don’t know what you mean by strong in strong-scoped access, but your 
> statement seems false. It does not remove the scoped access control, it only 
> relaxes it in extensions to types in the same file.

This relaxation makes the resulting scoping decidedly less strong.  It is no 
longer lexical and would require a user to consider all code in the file.  This 
means the strong, compiler-verified guarantee of scoped access that a small 
number of lines can see a member is eliminated.  The whole file must be 
considered.  As others have noted, that defeats the primary purpose of having 
scoped access control in the first place.

> 
>> The entire reason we're having this discussion is that "fileprivate" is such 
>> an awkward term for something that's so common in the language. I think the 
>> main thing we need to fix is the naming of that keyword.
> 
> The name of fileprivate is not reason for this proposal. fileprivate has an 
> awkward name precisely because it was planned for it to be used less often. 
> This proposal’s goal is to make private more attractive to fulfil that 
> original goal. fileprivate’s awkwardness is good, because it attracts 
> attention to it when it is used.

Your previous proposal eliminated this distinction entirely and if I understand 
correctly you still believe that is the best solution.  With that in mind, do 
you really consider it important to call special attention to same-file, 
cross-type members?  If we’re going to have a distinction in the language, do 
you really consider this a more important and useful distinction than the 
distinction supporting the use cases for scoped access?  If the answer to 
either of those questions is no I find it hard to understand how this issue is 
not simply about having the ability to say `private` most of the time (which is 
a naming issue not a semantics issue).

> 
>> I continue to believe that the best solution is to revert "private" to mean 
>> file scope as in Swift 2, and introduce a new "scoped" keyword for those 
>> developers who are specifically desiring the scoped functionality. This was 
>> rejected during the discussion because the migration would be too 
>> disruptive, but it is only disruptive if the migrator rewrites 
>> "private"->"scoped". I assert that most developers would not *want* that 
>> migration to happen; most developers use "private" because they want the 
>> default less-than-internal access control. The few developers who are using 
>> specifically scoped control can modify their code manually. Under this 
>> model, scoped access control is still available for those who need it, and 
>> most users can once again use "private" in cases where it is the natural 
>> default. 
>> 
>> This proposal proposes that "fileprivate" would become a marker to call out 
>> cases where exceptional across-type access is happening. In practice, I 
>> don't believe that will happen, simply because there are many existing cases 
>> of "fileprivate" out there, and this proposal does not suggest migrating 
>> them.
>> 
>> I also disagree that it's useful to call out "fileprivate" as an exceptional 
>> case. It's slightly useful, I'll acknowledge, but it would be *more* useful 
>> to call out the exceptional cases where scope-only control is being used.
>> 
>> So I disagree with the proposal. But I give it only -0.5 because even with 
>> all of that, this is a better definition for "private" than the current one.
>> 
>> -BJ
>> 
>> On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>>> Hello Swift Community,
>>> 
>>> In rejecting SE-0159 
>>> ,
>>>  the core team described a potential direction we would like to investigate 
>>> for “private” access control that admits a limited form of type-based 
>>> access control within files. The core team is seeking some discussion here 
>>> and a motivated volunteer to put together a proposal along these lines for 
>>> review in the Swift 4 time-frame (i.e., very soon). To be clear, the core 
>>> team it’s sure this is the right direction to go… but it appears promising 
>>> and we would *love* to be able to settle the access-control issue.
>>> 
>>> The design, specifically, is that a “private” member declared within a type 
>>> “X” or an extension thereof would be accessible from:
>>> 
>>>

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

2017-04-07 Thread Vladimir.S via swift-evolution


On 07.04.2017 16:56, Shawn Erickson via swift-evolution wrote:

-1 (strongish) on this proposal for the reason I comment earlier in the
discussion thread.

This weakens private for not an atypical use case of private that I
currently have. It muddies the water between fileprivate and private making
private more confusing and in away surprising. We have a clear and explicit
way in fileprivate to do what this proposal does by tweaking private. I get
that folks don't like fileprivate the word but I don't see that being a
strong enough reason to take things in this direction. It also builds on
file based access scoped which I believe is not the direction we should be
going in a modern language such as swift.

If changes are this strongly desired I believe we should bite the bullet
and rename "private" to "scope[d]" and "fileprivate" to "private". Then
work on making this renamed private work across files coupled either with a
submodule concept (likely tagging wholes file as existing in a module)
and/or making it work across extensions or class trees. ...or as suggested
by others leave "private" as is and just rename "fileprivate" to "shared"


.. or to "local", as "shared" is confusing if it is shared with all module. 
The meaning of "local" is also not 100% obvious, but:

* IMO it is not hard to tech public->internal->local->private
(internal for module, local for file/submodule, private for scope)
* Don't need to change anything in meaning of current access modifiers
* We even can keep 'fileprivate' as an alias(depricated?) for 'local', so 
we can have 100% source compatibility
* 'local' is very short and good looking keyword, that's important given it 
will be used often
* 'private' still be the most strict access level, soft default. Then you 
can promote to next level('local') if decide you need wider access scope.
* Yes, I remember, 'local' was rejected previously, but world is changing, 
currently many(most?) of us agree that 'fileprivate' more harmful than 
other not clear meaning but good looking word; that 'fileprivate' is still 
used very often and *will* be used often; and IIRC during the SE-0025 there 
was an intention to fix *later* awkward 'fileprivate' keyword, but now we 
was told "this is the last chance, nothing related to access modifiers will 
be in scope of any future Swift and renaming is not in scope of current 
stage also". So given this all, I think we can re-consider 'local' keyword.


Seems like such proposal also will have a huge support of the community.

Btw, when was *that* moment(which most of us missed, as I understand) we 
were *allowed* to discuss access modifier changes?



or something like that so it can expand it capability as I outline a
sentence earlier.

This proposal doesn't help like I think a more comprehensive rework would,
it actually hurts my usage of current private.



On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor > wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations
and Extensions" begins now and runs through April 11, 2017. The
proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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 well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

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

Thank you,

-Doug

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

2017-04-07 Thread Greg Titus via swift-evolution

Mostly as a matter of historical interest:

The hard-coding of collection operators for KVC in Cocoa was more of a scope of 
documentation or API style decision than anything. The original implementation 
of KVC came from Enterprise Objects Framework (which then became WebObjects), 
and in both of those frameworks collection operators could be added just by 
implementing correctly named category methods on NSArray/NSSet. I.e. the 
implementation of valueForKeyPath: constructed a selector from the part 
following the ‘@‘ and checked to see if it existed.

- Greg

> On Apr 6, 2017, at 9:46 PM, John McCall via swift-evolution 
>  wrote:
> I'm not seriously endorsing this exact spelling.  It would be much better to 
> be able to write something like:
>  \Department.employees.sum(of: \.salary)
> However, since "sum" would presumably be a method on Collection, I think this 
> would have to be a future extension to the proposal, and the overall thing 
> might have to be a function rather than a key path because it would no longer 
> have identity.
> 
> Also, I do feel obliged to note that AppKit/Cocoa's "very expressive" way of 
> doing this is a small number of hard-coded operators, whereas even the 
> kindof-unfortunate subscript trick would be arbitrarily extensible.
> 
> John.
> 
> 
>> 
>> Thanks.
>> 
>>> 
>>> ...
>>> 
>>> \Department.employees[summing: \.salary]
>>> 
>>> That's not actually a good name for the subscript, but maybe there's one 
>>> out there.
>>> 
>>> John.
>>> 
 
 Also, in this example:
 
 let firstFriendsNameKeyPath = \Person.friends[0].name
 let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
 
 Can't we do without the keyPath: argument name? The compiler knows it's a 
 keypath, it would be nicer to write
 
 let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
 
> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
> Swift" begins now and runs through April 9, 2017. The revised proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> The core team’s feedback from the first review of this proposal can be 
> viewed at:
> 
> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
> 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/0161-key-paths.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 well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 
 -- 
 Rick Mann
 rm...@latencyzero.com
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
> 
> ___
> 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] Type-based ‘private’ access within a file

2017-04-07 Thread David Hart via swift-evolution


> On 7 Apr 2017, at 15:41, BJ Homer via swift-evolution 
>  wrote:
> 
> -0.5
> 
> SE-0159 was rejected because it was determined that some developers are 
> actively using strongly-scoped access control. This proposal removes that 
> strong scoping, so I do not see how we can reasonably reject that proposal 
> but accept this one.

I don’t know what you mean by strong in strong-scoped access, but your 
statement seems false. It does not remove the scoped access control, it only 
relaxes it in extensions to types in the same file.

> The entire reason we're having this discussion is that "fileprivate" is such 
> an awkward term for something that's so common in the language. I think the 
> main thing we need to fix is the naming of that keyword.

The name of fileprivate is not reason for this proposal. fileprivate has an 
awkward name precisely because it was planned for it to be used less often. 
This proposal’s goal is to make private more attractive to fulfil that original 
goal. fileprivate’s awkwardness is good, because it attracts attention to it 
when it is used.

> I continue to believe that the best solution is to revert "private" to mean 
> file scope as in Swift 2, and introduce a new "scoped" keyword for those 
> developers who are specifically desiring the scoped functionality. This was 
> rejected during the discussion because the migration would be too disruptive, 
> but it is only disruptive if the migrator rewrites "private"->"scoped". I 
> assert that most developers would not *want* that migration to happen; most 
> developers use "private" because they want the default less-than-internal 
> access control. The few developers who are using specifically scoped control 
> can modify their code manually. Under this model, scoped access control is 
> still available for those who need it, and most users can once again use 
> "private" in cases where it is the natural default. 
> 
> This proposal proposes that "fileprivate" would become a marker to call out 
> cases where exceptional across-type access is happening. In practice, I don't 
> believe that will happen, simply because there are many existing cases of 
> "fileprivate" out there, and this proposal does not suggest migrating them.
> 
> I also disagree that it's useful to call out "fileprivate" as an exceptional 
> case. It's slightly useful, I'll acknowledge, but it would be *more* useful 
> to call out the exceptional cases where scope-only control is being used.
> 
> So I disagree with the proposal. But I give it only -0.5 because even with 
> all of that, this is a better definition for "private" than the current one.
> 
> -BJ
> 
> On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> Hello Swift Community,
>> 
>> In rejecting SE-0159 
>> ,
>>  the core team described a potential direction we would like to investigate 
>> for “private” access control that admits a limited form of type-based access 
>> control within files. The core team is seeking some discussion here and a 
>> motivated volunteer to put together a proposal along these lines for review 
>> in the Swift 4 time-frame (i.e., very soon). To be clear, the core team it’s 
>> sure this is the right direction to go… but it appears promising and we 
>> would *love* to be able to settle the access-control issue.
>> 
>> The design, specifically, is that a “private” member declared within a type 
>> “X” or an extension thereof would be accessible from:
>> 
>>  * An extension of “X” in the same file
>>  * The definition of “X”, if it occurs in the same file
>>  * A nested type (or extension thereof) of one of the above that occurs 
>> in the same file
>> 
>> This design has a number of apparent benefits:
>>  + “private” becomes the right default for “less than whole module” 
>> visibility, and aligns well with Swift coding style that divides a type’s 
>> definition into a number of extensions.
>>  + “fileprivate” remains for existing use cases, but now it’s use it 
>> more rare, which has several advantages:
>>  + It fits well with the "progressive disclosure” philosophy 
>> behind Swift: you can use public/internal/private for a while before 
>> encountering and having to learn about “fileprivate”   (note: we thought 
>> this was going to be true of SE-0025 
>> ,
>>  but we were clearly wrong)
>>  + When “fileprivate” occurs, it means there’s some interesting 
>> coupling between different types in the same file. That makes fileprivate a 
>> useful alert to the reader rather than, potentially, something that we 
>> routinely use and overlook so that we can separate implementations into 
>> extensions.
>>  + “private” is more

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

2017-04-07 Thread Shawn Erickson via swift-evolution

-1 (strongish) on this proposal for the reason I comment earlier in the
discussion thread.

This weakens private for not an atypical use case of private that I
currently have. It muddies the water between fileprivate and private making
private more confusing and in away surprising. We have a clear and explicit
way in fileprivate to do what this proposal does by tweaking private. I get
that folks don't like fileprivate the word but I don't see that being a
strong enough reason to take things in this direction. It also builds on
file based access scoped which I believe is not the direction we should be
going in a modern language such as swift.

If changes are this strongly desired I believe we should bite the bullet
and rename "private" to "scope[d]" and "fileprivate" to "private". Then
work on making this renamed private work across files coupled either with a
submodule concept (likely tagging wholes file as existing in a module)
and/or making it work across extensions or class trees. ...or as suggested
by others leave "private" as is and just rename "fileprivate" to "shared"
or something like that so it can expand it capability as I outline a
sentence earlier.

This proposal doesn't help like I think a more comprehensive rework would,
it actually hurts my usage of current private.

On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor  wrote:

> Hello Swift community,
>
> The review of SE-0169 "Improve Interaction Between private Declarations
> and Extensions" begins now and runs through April 11, 2017. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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 well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file