Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

[Nate Cook via swift-evolution]

> On Nov 30, 2016, at 6:15 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> on Wed Nov 30 2016, Kevin Ballard  > wrote:
> 
>> This sounds like a sensible idea. But there is one behavioral change you
>> haven't addressed, which is that this changes how indexes work on the
>> slice. With all other slice types that come to mind, the slice shares
>> the same indexes as the base, e.g.
>> 
>>  let ary = Array(0..<10)
>> 
>>  print(ary[3]) // prints 3
>> 
>>  print(ary[2..<5][3]) // still prints 3
> 
> This is an important invariant that we need to maintain.
> 
>> UnsafeBufferPointer is indexed using 0-based integers, so with your
>> proposal, slicing an UnsafeBufferPointer produces a value that uses
>> different indexes. We could solve this by adding a new field, but that
>> would break the expectation that startIndex is always zero. 
> 
> I'm not sure that's an expectation we're obligated to honor.  Of course,
> once you get into “unsafe” territory like this, breaking even the
> expectations that aren't based on documented guarantees can be really
> dangerous.
> 
> We probably ought to have wrapped those integers in some Index type
> specific to UnsafeBufferPointer, so zero wasn't even a value.
> 
>> But we can't just ignore this problem, because algorithms that are
>> designed around collections may assume that slices preserve indexes.
>> 
>> In addition, since you point out that UnsafeRawBufferPointer is already
>> its own subsequence, and that type also guarantees that startIndex is
>> always zero, it sounds like we already have an instance of this problem
>> in the stdlib, and so this needs to be addressed with
>> UnsafeRawBufferPointer as well.
> 
> Sounds like it!

Argh, thanks to Kevin for pointing all this out!

I can see at least three approaches to resolving the inconsistency between the 
two sets of buffer types and correcting index sharing for raw buffer pointers.

1) Switch to using Slice as a wrapper for UnsafeRawBufferPointer.
2) Make all buffer pointers their own slices, keeping integer-based indices, 
but remove the zero-based index expectation. With this we'd need to add an 
additional stored property to keep track of the relative offset from the 
"original" buffer.
3) Make all buffer pointers their own slices but use a different index type. If 
the indices were just wrapped pointers, that would handle the index sharing 
without needing an additional property on the buffer. We could also maintain 
integer-based stridable conformance (which greatly simplifies index 
arithmetic), since the indices would just offset by a byte for raw buffers or a 
stride for typed buffers.

The first option would certainly be the smallest change; the third seems like 
it would do the most good, for the reasons Dave laid out. I've tried the third 
option out here for raw buffers:

https://github.com/apple/swift/compare/master...natecook1000:nc-buffer-indices

Thanks!
Nate


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

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

[Ramiro Feria Purón via swift-evolution]

*I might even be willing to inhibit deduction,by default, of all generic
function type parameters that don't appear inthe parameter list.*

^ If this was adopted, what Dave is proposing is:

func f() -> T // error: generic parameter T must be explicit
func f() -> T   // ok



On Thu, 1 Dec 2016 at 11:17 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Mon Nov 28 2016, Douglas Gregor  wrote:
>
> >> On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution
> >  wrote:
> >>
> >> Problem:
> >>
> >> Currently, it is not possible to be explicit about the generic
> parameters (type parameters) in a
> > generic function call. Type parameters are inferred from actual
> parameters:
> >
> >>
> >> func f(_ t: T) {
> >>
> >> //..
> >> }
> >>
> >> f(5)// T inferred to be Int
> >> f("xzcvzxcvx")  // T inferred to be string
> >>
> >> If no type parameter is involved in the formal parameters, the type
> parameter needs to be used somehow as part of the return type. For example:
> >>
> >> func g(_ x: Int) -> [T] {
> >>
> >> var result: [T] = []
> >>
> >> //..
> >>
> >> return result
> >> }
> >>
> >> In such cases, the type parameters must be inferrable from the context:
> >>
> >> g(7)// Error: T cannot be inferred
> >> let array = g(7)// Error: T cannot be inferred
> >> let array: [String] = g(7)  // Ok: T inferred to be String
> >> let array = g(7)// Error: Cannot explicitly specialise
> generic function
> >>
> >>
> >>
> >> Proposed Solution:
> >>
> >> Allow explicit type parameters in generic function call:
> >>
> >> let _ = g(7)// Ok
> >>
> >>
> >>
> >> Motivation:
> >>
> >> Consider the following contrived example:
> >>
> >> class Vehicle {
> >> var currentSpeed = 0
> >> //..
> >> }
> >>
> >> class Bicycle: Vehicle {
> >> //..
> >> }
> >>
> >> class Car: Vehicle {
> >> //..
> >> }
> >>
> >> @discardableResult
> >> func processAll(in vehicles: [Vehicle], condition:
> (Vehicle) -> Bool) -> [T] {
> >>
> >> var processed: [T] = []
> >>
> >> for vehicle in vehicles {
> >> guard let t = vehicle as? T, condition(vehicle) else { continue
> }
> >> //..
> >> processed.append(t)
> >> }
> >>
> >> return processed
> >> }
> >>
> >> func aboveSpeedLimit(vehicle: Vehicle) -> Bool {
> >> return vehicle.currentSpeed >= 100
> >> }
> >>
> >>
> >> let processedVehicles = processAll(in: vehicles, condition:
> aboveSpeedLimit) // Uh, T inferred to
> > be Vehicle!
> >> let processedCars: [Car] = processAll(in: vehicles, condition:
> aboveSpeedLimit) // T inferred to
> > be Car
> >> processAll(in: vehicles, condition: aboveSpeedLimit) // This
> should be allowed under this
> > proposal
> >>
> >>
> >> Notes:
> >>
> >> If necessary, the (real life) Swift code that lead to the proposal
> could be shared.
> >
> > This seems completely reasonable to me. I had always expected us to
> > implement this feature, but we never got around to it, and it wasn’t a
> > high priority because one can always use type inference. Additionally,
> > there were a few places where we originally thought we wanted this
> > feature, but prefer the more-explicit form where the user is required
> > to explicitly pass along a metatype. unsafeBitCast is one such case:
> >
> >   func unsafeBitCast(_ x: T, to: U.Type) -> U
> >
> > Even if we had the ability to provide explicit type arguments, we
> > would *not* want to change this signature to
> >
> >   func unsafeBitCast(_ x: T) -> U // bad idea
> >
> > because while it makes the correct usage slightly cleaner:
> >
> >   unsafeBitCast(something)   // slightly prettier, but...
> >
> > it would enable type inference to go wild with unsafe casts:
> >
> >   foo(unsafeBitCast(something))   // just cast it to.. whatever
> >
> > which is… not great.
>
> Yeah, but IMO ideally we'd have a way to inhibit deduction of some
> generic type parameters.  I might even be willing to inhibit deduction,
> by default, of all generic function type parameters that don't appear in
> the parameter list.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Derrick Ho via swift-evolution]

I like this proposal!

+1

Oldvalue and newvalue have different meanings. I have witnesses programmers
overriding oldvalue with the name newvalue and vice versa.

Of course if you are good at reading the documentation then you would not
make the mistake.

Swift should be a language that prevents a programmer from making mistakes!

I am in favor of disallowing the name changes. Because it is much more
clear if it is an oldvalue or newvalue.

If a different name is desired there are two solutions, create a new
variable or add a capture list.

set (newValue: TheType) {
let temp = newValue
}

set { [temp = newValue] in

}

I think either of these would make this change easier to convert.

The second one would probably be easier to convert.

//current
set (temp) {

}

// Proposed and much more clear.
set { [temp = newValue] in

}

On Thu, Dec 1, 2016 at 3:01 PM Will Field-Thompson via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm also against this (though I like the first alternative about warning
> on set(oldValue) etc.).
>
> While I think there may be value in either preventing name overrides or
> requiring them here, I don't believe it's worth a breaking change. Then
> again, I have never personally encountered the problem (I tend not to
> override names), so maybe those who have feel differently.
>
> I also think that if this proposal goes through I would prefer not to
> allow the current name overriding syntax, even in the self-documenting
> case. At that point, the self-documenting case seems like unnecessary
> syntactic noise. It makes sense for a team where observer names are
> frequently overridden, but when that's disallowed, I feel that the
> self-documenting case adds very little.
>
> - Will
>
>
> On Thu, Dec 1, 2016 at 3:40 AM Tino Heth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> -1
>
> I'm more or less neutral towards the change itself, but combined with the
> breaking effect, that's a clear "no".
>
> None the less, I hope that the whole topic with all its magic words
> (willSet, didSet, newValue, oldValue…) will be reworked in the future,
> which would be another argument not to fiddle with it now*
>
> - Tino
>
> *
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html
> ___
> 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] Proposal: Allow explicit type parameter specification in generic function call

[Ramiro Feria Purón via swift-evolution]

*Unlike C++'s templates, a Swift's generic function is semantically a
single function.*

Anton, could you provide further insight on this?


On Fri, 2 Dec 2016 at 01:03 Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> I disagree with the suggestion. Unlike C++'s templates, a Swift's generic
> function is semantically a single function. One can say that together with
> a metatype parameter, we pass in witness table.
>
> What I think we should do is make metatypes easier to use. *Adrian and I
> have a PR* that has already been waiting for almost a month:
> https://github.com/apple/swift-evolution/pull/553
> Plus, removal of .self could simplify such calls.
> ___
> 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] Proposal: Allow explicit type parameter specification in generic function call

[Ramiro Feria Purón via swift-evolution]

*Yeah, this makes sense. Presumably this means that one could also write*

* foo<>(1)*

*where everything is still deduced. In C++, this syntax exists and means
that non-template functions named “foo” are ignored.*

Yes, it means so. One could have:

foo()

foo<>() // redundant

foo<_>()// redundant

foo()

foo<_, _>() // redundant

foo() // redundant

foo<_, U>()

foo()

//..

One historical reason to allow redundant cases has been to ease automatic
code generation.

*This could be a more general feature that works wherever a type is
specified and deduction works. For example, today you can do, e.g,*

* let d1: Dictionary = [ “Hello” : 2017 ]*

*and we’ll infer the type arguments. It wouldn’t be unreasonable to allow *

* let d2: Dictionary<_, Int32> = [ “Hello”: 2017 ]*

*or*

* let d3: [ _: Int32 ] = [ “Hello”: 2017 ]*

*or *

* let d4 = [ “Hello”: 2017 ] as [ _: Int32 ]*

*to partially specify the types of the result. I think this is a
separate-but-interesting proposal (that is out of scope for Swift 4 stage
1).*

Yes, yes, yes, yes and yes. Yes! A very rewarding outcome from the
discussion! We should start a co-authored proposal asap.

*As I noted in my reply to Dave, I personally don’t want this: I feel that
the idiom used by unsafeBitCast produces more readable code with
already-existing features.*

In this aspect I disagree. The argument is the following:

One of the problems generic functions as a language feature aim to assist
with (eradicate) is the questionable pattern of using formal arguments in
ordinary functions for the *sole* purpose of passing type information. It
is not only about duplicated code. And the problem with the pattern is that
there is nothing that tells the compiler and other code analysing tools
that the parameter has been used only for that purpose. Nor the human eye
without using additional knowledge.Thus, when that pattern is used in a
generic function, it is like having the antithesis of the feature while
using the feature itself. And this is a reason why I believe the discussion
goes beyond a syntactic convenience.

Emphasising on the proposed explicit keyword above, this would be a very
convenient way to pass in formation to the compiler (and the user) that
would be otherwise hosted by the author of the function (as it is the case
of the unsafeBitCast example).

Best regards,
Ramiro


On Thu, 1 Dec 2016 at 15:53 Douglas Gregor  wrote:

> On Nov 30, 2016, at 4:05 PM, Ramiro Feria Purón <
> ramiro.feria.pu...@gmail.com> wrote:
>
> Formally, perhaps the proposal should include the following:
>
> 1. Missing type parameters are assumed to be implicit and trailing (as in
> the particular case of all type parameters missing).
>
>
> Yeah, this makes sense. Presumably this means that one could also write
>
> foo<>(1)
>
> where everything is still deduced. In C++, this syntax exists and means
> that non-template functions named “foo” are ignored.
>
> 2. _ is allowed as a placeholder when specifying explicit parameters in a
> function call. The corresponding parameter is assumed to be implicit.
>
>
> This could be a more general feature that works wherever a type is
> specified and deduction works. For example, today you can do, e.g,
>
> let d1: Dictionary = [ “Hello” : 2017 ]
>
> and we’ll infer the type arguments. It wouldn’t be unreasonable to allow
>
> let d2: Dictionary<_, Int32> = [ “Hello”: 2017 ]
>
> or
>
> let d3: [ _: Int32 ] = [ “Hello”: 2017 ]
>
> or
>
> let d4 = [ “Hello”: 2017 ] as [ _: Int32 ]
>
> to partially specify the types of the result. I think this is a
> separate-but-interesting proposal (that is out of scope for Swift 4 stage
> 1).
>
>
> In addition to this, and following the discussion on the unsafeBitCast 
> example,
> it might be a good idea to incorporate to the proposal adding an (optional)
> explicit keyword for type parameters in generic function definitions:
>
> func unsafeBitCast(_ x: T) -> U
>
> foo(unsafeBitCast(something))  // error: explicit type parameter
> required
> foo(unsafeBitCast(something))   // ok
>
>
> As I noted in my reply to Dave, I personally don’t want this: I feel that
> the idiom used by unsafeBitCast produces more readable code with
> already-existing features.
>
> - Doug
>
>
> Regards,
> Ramiro
>
>
>
>
> On Thu, 1 Dec 2016 at 01:36 Ramiro Feria Purón <
> ramiro.feria.pu...@gmail.com> wrote:
>
> Or perhaps in a more "swifty" way, use _ for implicit type parameters,
> i.e.:
>
> f<_,T>()
>
> On Thu, 1 Dec 2016 at 01:13 Ramiro Feria Purón <
> ramiro.feria.pu...@gmail.com> wrote:
>
> Douglas,
>
> Regarding the question on the restriction for type parameters to appear on
> the signature, the answer is remain. The proposal does not intend this
> restriction to be lifted.
>
> One might expect to find a few legitimate cases where having it lifted
> would be handy or desirable. They seem to emerge often, for example,
> while developing components using Core Data. From a real 

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

[Dave Abrahams via swift-evolution]

on Wed Nov 30 2016, Douglas Gregor  wrote:

>> On Nov 30, 2016, at 4:09 PM, Dave Abrahams via swift-evolution
>  wrote:
>> 
>> 
>> on Mon Nov 28 2016, Douglas Gregor
>> 
>> >
>> wrote:
>> 
 On Nov 21, 2016, at 3:05 PM, Ramiro Feria Purón via swift-evolution
>>>  wrote:
 
 Problem:
 
 Currently, it is not possible to be explicit about the generic parameters 
 (type parameters) in a
>>> generic function call. Type parameters are inferred from actual parameters:
>>> 
 
 func f(_ t: T) {
 
//..
 }
 
 f(5)// T inferred to be Int
 f("xzcvzxcvx")  // T inferred to be string 
 
 If no type parameter is involved in the formal parameters, the type 
 parameter needs to be used somehow as part of the return type. For example:
 
 func g(_ x: Int) -> [T] {
 
var result: [T] = []
 
//..
 
return result
 }
 
 In such cases, the type parameters must be inferrable from the context:
 
 g(7)// Error: T cannot be inferred
 let array = g(7)// Error: T cannot be inferred
 let array: [String] = g(7)  // Ok: T inferred to be String
 let array = g(7)// Error: Cannot explicitly specialise 
 generic function
 
 
 
 Proposed Solution:
 
 Allow explicit type parameters in generic function call:
 
 let _ = g(7)// Ok
 
 
 
 Motivation:
 
 Consider the following contrived example:
 
 class Vehicle {
var currentSpeed = 0
//..
 }
 
 class Bicycle: Vehicle {
//..
 }
 
 class Car: Vehicle {
//..
 }
 
 @discardableResult
 func processAll(in vehicles: [Vehicle], condition: (Vehicle) 
 -> Bool) -> [T] {
 
var processed: [T] = []
 
for vehicle in vehicles {
guard let t = vehicle as? T, condition(vehicle) else { continue }
//..
processed.append(t)
}
 
return processed
 }
 
 func aboveSpeedLimit(vehicle: Vehicle) -> Bool {
return vehicle.currentSpeed >= 100
 }
 
 
 let processedVehicles = processAll(in: vehicles, condition: 
 aboveSpeedLimit) // Uh, T inferred to
>>> be Vehicle!
 let processedCars: [Car] = processAll(in: vehicles, condition: 
 aboveSpeedLimit) // T inferred to
>>> be Car
 processAll(in: vehicles, condition: aboveSpeedLimit) // This 
 should be allowed under this
>>> proposal
 
 
 Notes:
 
 If necessary, the (real life) Swift code that lead to the proposal could 
 be shared.
>>> 
>>> This seems completely reasonable to me. I had always expected us to
>>> implement this feature, but we never got around to it, and it wasn’t a
>>> high priority because one can always use type inference. Additionally,
>>> there were a few places where we originally thought we wanted this
>>> feature, but prefer the more-explicit form where the user is required
>>> to explicitly pass along a metatype. unsafeBitCast is one such case:
>>> 
>>> func unsafeBitCast(_ x: T, to: U.Type) -> U
>>> 
>>> Even if we had the ability to provide explicit type arguments, we
>>> would *not* want to change this signature to
>>> 
>>> func unsafeBitCast(_ x: T) -> U // bad idea
>>> 
>>> because while it makes the correct usage slightly cleaner:
>>> 
>>> unsafeBitCast(something)   // slightly prettier, but...
>>> 
>>> it would enable type inference to go wild with unsafe casts:
>>> 
>>> foo(unsafeBitCast(something))   // just cast it to.. whatever   
>>> 
>>> which is… not great.
>> 
>> Yeah, but IMO ideally we'd have a way to inhibit deduction of some
>> generic type parameters.
>
> Well, I’d say we already have it: it’s the pass-a-metatype approach
> already used by unsafeBitCast, and I think usages of that API read
> really, really well as it is.

IMO they are marred by “.self,” but that's really a minor issue. More
importantly, they suggest that the metatype argument will be used in
some dynamic way (e.g. by calling a static method or an init), instead
of just as a way to get the right type inference.  In some cases that
can make a dramatic difference in the resulting semantics.

func polymorphicSomething(_: T.Type) {
  ...
}

class Base {}
class Derived : Base {}

func otherThing(x: Base) {
  // Surprise! I'm going to ignore the dynamic type you gave me and
  // just use Base
  polymorphicSomething(type(of: y)) 
}

otherThing(Derived())

This is exactly why we have

 MemoryLayout.size

and not

 memoryLayout(Foo.self).size

>>  I might even be willing to inhibit deduction,
>> by default, of all generic function type 

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Gonçalo Alvarez Peixoto via swift-evolution]

@Brandon

*Is anyone starting to think the current access control model will become
more burdensome over time?*

*People will want to add and subtract to it for years to come...which tells
me it's not very flexible. I'm beginning to feel like it is an old style
model trying to fit into a modern language. *

.Most definitely. We've mentioned earlier in this thread the usage of file
private feels somehow we're basing swift design on compiler related
constructs.

*For example, fileprivate and private encourage stuffing a lot of code into
one file just to use that access control level. If you want to break this
into more manageable chunks you have to make it internal or move it into a
new module which is very complicated to do in Xcode (I.e requiring a new
target like a framework). *

*.*Agreed. As stated before, this might lead into some kind of pattern
where types are chunked into the same file for the sakes of member access
convenience. I strongly believe we should aim at promoting code clarity and
readability while enhancing single responsibility principle's good
practices.

*This keeps leading me back to having submodules or creating modules on
demand. I think that would open up this system to great complexity.*

*Want to keep something private to a specific class but private to anything
outside of it? Make it internal to the same "submodule". *

*I think we could keep tacking on things to access control, but I don't
think it is really solving everyone's needs. I think a more flexible system
would allow people to adapt it to their needs instead of structuring
everything around a rigid system that forces you to do it swift's way. *

Don't you feel that would defeat the purpose of access control levels?
Correct if I'm wrong, but I don't think there's much to gain from trying to
dodge the need for private (whether scope private, fileprivate or
eventually typeprivate) members no matter how modularised your code is.
Also, I believe it an unworthy effort, as I think we could run the risk of
creating problems further in the chain of access control levels? I just
think we'd be pushing the problem further up the hill.

Best,
Gonçalo

2016-12-01 20:40 GMT+00:00 Brandon Knope :

>
>
> > This keeps leading me back to having submodules or creating modules on
> demand. I think that would open up this system to great complexity.
>
> I meant "flexibility"...not complexity. Freudian slip? 
>
> Brandon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0145: Package Manager Version Pinning (Revised)

[Alexis via swift-evolution]

Haven’t had a chance to catch up on the latest discussion, but I just saw that 
the Yarn developers posted an excellent piece on lockfiles this week:

https://yarnpkg.com/blog/2016/11/24/lockfiles-for-all 


They argue lockfiles should be commited by libraries (but still ignored by 
applications). The essential point is that this makes it easier for developers 
of the library to maintain a coherent build of the library when dependencies 
ship a bug. The focus is particularly on new developers, who would otherwise 
lack a lockfile.

> On Nov 20, 2016, at 12:48 AM, Anders Bertelrud  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0145: Package Manager Version Pinning" begins again after 
> revisions, starting now and running through November 28th. The proposal is 
> available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-build-dev and swift-evolution mailing lists at
> 
>   https://lists.swift.org/mailman/listinfo/swift-build-dev 
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to 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,
> 
> Anders Bertelrud
> 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] Proposal: Allow explicit type parameter specification in generic function call

[Goffredo Marocchi via swift-evolution]

It seems odd that no review or comment has been made as the PR seems a step in 
the right direction.

Sent from my iPhone

> On 1 Dec 2016, at 14:17, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> You forgot to mention Brent. ;)
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 1. Dezember 2016 um 15:03:07, Anton Zhilin (antonyzhi...@gmail.com) 
> schrieb:
> 
>> I disagree with the suggestion. Unlike C++'s templates, a Swift's generic 
>> function is semantically a single function. One can say that together with a 
>> metatype parameter, we pass in witness table.
>> 
>> What I think we should do is make metatypes easier to use. Adrian and I have 
>> a PR that has already been waiting for almost a month: 
>> https://github.com/apple/swift-evolution/pull/553
>> Plus, removal of .self could simplify such calls.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Brandon Knope via swift-evolution]

> This keeps leading me back to having submodules or creating modules on 
> demand. I think that would open up this system to great complexity.

I meant "flexibility"...not complexity. Freudian slip? 

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

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Brandon Knope via swift-evolution]

Is anyone starting to think the current access control model will become more 
burdensome over time?

People will want to add and subtract to it for years to come...which tells me 
it's not very flexible. I'm beginning to feel like it is an old style model 
trying to fit into a modern language. 

For example, fileprivate and private encourage stuffing a lot of code into one 
file just to use that access control level. If you want to break this into more 
manageable chunks you have to make it internal or move it into a new module 
which is very complicated to do in Xcode (I.e requiring a new target like a 
framework). 

This keeps leading me back to having submodules or creating modules on demand. 
I think that would open up this system to great complexity.

Want to keep something private to a specific class but private to anything 
outside of it? Make it internal to the same "submodule". 

I think we could keep tacking on things to access control, but I don't think it 
is really solving everyone's needs. I think a more flexible system would allow 
people to adapt it to their needs instead of structuring everything around a 
rigid system that forces you to do it swift's way. 

> On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution 
>  wrote:
> 
> Hello, everyone!
> 
> I would like to introduce a new proposal to swift evolution, but first I 
> would love to run it by all of you so I get everyone's feedback and enrich it.
> 
> This proposal consists of introducing a new typeprivate access control level 
> which allows for members to be accessed in all extensions of a given type, 
> whether lying within or in another file.
> 
> You'll find the proposal draft in:
> https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/-introduce-typeprivate-access-control-level.md
> 
> Thanks in advance for taking the time to evaluate the proposal.
> 
> Best regards,
> Gonçalo
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Will Field-Thompson via swift-evolution]

I'm also against this (though I like the first alternative about warning on
set(oldValue) etc.).

While I think there may be value in either preventing name overrides or
requiring them here, I don't believe it's worth a breaking change. Then
again, I have never personally encountered the problem (I tend not to
override names), so maybe those who have feel differently.

I also think that if this proposal goes through I would prefer not to allow
the current name overriding syntax, even in the self-documenting case. At
that point, the self-documenting case seems like unnecessary syntactic
noise. It makes sense for a team where observer names are frequently
overridden, but when that's disallowed, I feel that the self-documenting
case adds very little.

- Will

On Thu, Dec 1, 2016 at 3:40 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> -1
>
> I'm more or less neutral towards the change itself, but combined with the
> breaking effect, that's a clear "no".
>
> None the less, I hope that the whole topic with all its magic words
> (willSet, didSet, newValue, oldValue…) will be reworked in the future,
> which would be another argument not to fiddle with it now*
>
> - Tino
>
> *
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

[Dave Abrahams via swift-evolution]

on Thu Dec 01 2016, Jordan Rose  wrote:

>> On Nov 30, 2016, at 16:15, Dave Abrahams via swift-evolution
>  wrote:
>> 
>> 
>> on Wed Nov 30 2016, Kevin Ballard
>> 
>> >
>> wrote:
>> 
>>> This sounds like a sensible idea. But there is one behavioral change you
>>> haven't addressed, which is that this changes how indexes work on the
>>> slice. With all other slice types that come to mind, the slice shares
>>> the same indexes as the base, e.g.
>>> 
>>>  let ary = Array(0..<10)
>>> 
>>>  print(ary[3]) // prints 3
>>> 
>>>  print(ary[2..<5][3]) // still prints 3
>> 
>> This is an important invariant that we need to maintain.
>> 
>>> UnsafeBufferPointer is indexed using 0-based integers, so with your
>>> proposal, slicing an UnsafeBufferPointer produces a value that uses
>>> different indexes. We could solve this by adding a new field, but that
>>> would break the expectation that startIndex is always zero. 
>> 
>> I'm not sure that's an expectation we're obligated to honor.  Of course,
>> once you get into “unsafe” territory like this, breaking even the
>> expectations that aren't based on documented guarantees can be really
>> dangerous.
>> 
>> We probably ought to have wrapped those integers in some Index type
>> specific to UnsafeBufferPointer, so zero wasn't even a value.
>
> Since UnsafeBufferPointer is like an Array, I think it is supposed to
> have integer indexes from the start of the buffer. 

I'm not sure it's important that the indices be integers. Once we get
into this unsafe corner of the language, it might be better if they
weren't.

-- 
-Dave

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

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

[Jordan Rose via swift-evolution]

> On Nov 30, 2016, at 16:15, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Nov 30 2016, Kevin Ballard  > wrote:
> 
>> This sounds like a sensible idea. But there is one behavioral change you
>> haven't addressed, which is that this changes how indexes work on the
>> slice. With all other slice types that come to mind, the slice shares
>> the same indexes as the base, e.g.
>> 
>>  let ary = Array(0..<10)
>> 
>>  print(ary[3]) // prints 3
>> 
>>  print(ary[2..<5][3]) // still prints 3
> 
> This is an important invariant that we need to maintain.
> 
>> UnsafeBufferPointer is indexed using 0-based integers, so with your
>> proposal, slicing an UnsafeBufferPointer produces a value that uses
>> different indexes. We could solve this by adding a new field, but that
>> would break the expectation that startIndex is always zero. 
> 
> I'm not sure that's an expectation we're obligated to honor.  Of course,
> once you get into “unsafe” territory like this, breaking even the
> expectations that aren't based on documented guarantees can be really
> dangerous.
> 
> We probably ought to have wrapped those integers in some Index type
> specific to UnsafeBufferPointer, so zero wasn't even a value.

Since UnsafeBufferPointer is like an Array, I think it is supposed to have 
integer indexes from the start of the buffer. (It's what we're telling people 
to use as the currency type for what would be pointer/size pairs in C.) So I 
think Kevin's point is valid, and UnsafeBufferPointer cannot be its own slice 
type.

Jordan

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

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Gonçalo Alvarez Peixoto via swift-evolution]

@Aron, I did take a look at that document while developing the proposal. As
you stated, it's a little old, however the principles of access control and
their purpose remain pretty much the same.

".keep private details of a class hidden from the rest of the app
 .keep interna details of a framework hidden from the client app"

Both these rules still get respected with the introduction of a new level
of access control. *typeprivate *would not allow for member access within
any other then the *type* itself.

@Jay, while I do appreciate your idea, I'm afraid this proposal aims at
something a lot less complex. One may argue the changes in Swift's design
to accommodate it may facilitate and open door to more complex changes like
the one you suggest, still I believe those changes are most welcome in the
name creating a safer and easier to handle access control policy. This
proposal aims only at opening access to private members to any extension
over that type.

2016-12-01 17:47 GMT+00:00 Martin Waitz via swift-evolution <
swift-evolution@swift.org>:

> Hi,
>
> Am 2016-12-01 11:08, schrieb Álvaro Monteiro via swift-evolution:
> > - Typeprivate would allow to abandon the odd fileprivate. Access level
> > would be constrained to swift constructs (structs, classes and
> > extensions) and not to a compiler artifact (file).
>
> Files are not compiler artifacts but design artifacts.
> They group related stuff which was designed together and which should be
> reviewed together.
>
> I really like `fileprivate` and how Swift currently handles access control.
>
> --
> Martin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Martin Waitz via swift-evolution]

Hi,

Am 2016-12-01 11:08, schrieb Álvaro Monteiro via swift-evolution:
> - Typeprivate would allow to abandon the odd fileprivate. Access level
> would be constrained to swift constructs (structs, classes and
> extensions) and not to a compiler artifact (file).

Files are not compiler artifacts but design artifacts.
They group related stuff which was designed together and which should be 
reviewed together.

I really like `fileprivate` and how Swift currently handles access control.

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

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Jay Abbott via swift-evolution]

We really need a place for discussions that apply to deferred issues. Some
previous suggestions from myself and others have been:

   - A Discourse board
   - Tag emails [4.1] (or something else) if they are known to relate to
   deferred proposals.
   - A ‘deferred’ directory for complete proposals in the swift-evolution
   repo to give deferred topics more visibility and a central place for
   discussion around

Until then, I’ll just pile on…

I’ve previously suggested an idea similar to this where a type can define
its own named access groups and then use them for access control. I didn’t
flesh it out in full (as this is a deferred topic anyway) but the concept
was something along these lines…

A class might define a group called Subclasses and that would then be
available to use on properties/functions like access(Subclasses) and
another group called Friends used with access(Friends). This would give the
most flexibility and allow a potentially complex combination of access
controls to be moved elsewhere and re-used in the function definitions that
use it.

Here’s some throw-away syntax to demonstrate a few possibilities:

accessgroup Subclasses {
type: Self
extensions: true // Extensions of types matching 'type' can access
file: true // Anything in this file can access
}accessgroup Friends {
type: UIView, Bob!, Jeff // Any UIView or Jeff type (including
subtypes) and Bob (not including subtypes) can access.
}

This would be defined inside a type - so named groups are type-specific.
This structure can then be used to define whatever type of access we decide
would be useful - access by named modules / submodules? access by direct
subtypes only? access only from specific functions? access from
protocol-conforming types - only the functions of that protocol or any
function in the conforming class? etc.

You can go wild of course with what can be defined in an accessgroup - the
idea here is that we start simple and then discussions about adding other
access control features become a lot easier. We could even go so far as to
say that existing private internal etc. keywords are synonyms for
access(private), access(internal) where private and internal are
always-defined (reserved) accessgroup names.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[João David via swift-evolution]

@Tino: Regarding the following statement - "Even if there was a change of mind, 
fileprivate is still needed for essential things like implementing Equatable.”
How exactly is that so? Am I missing something?

> > - Typeprivate would allow to abandon the odd fileprivate. Access level 
> > would be constrained to swift constructs (structs, classes and extensions) 
> > and not to a compiler artifact (file).
> Actually, imho fileprivate isn't odd or "unswift"* — it's one of the three 
> original levels, which all rely on the layout of the filesystem ("same file?" 
> and "same folder/module?").
> Even if there was a change of mind, fileprivate is still needed for essential 
> things like implementing Equatable.
>
> But I'm not arguing against typeprivate at all (nor against access control in 
> general ;-)
>
> - Tino
>
> * I tend not to use attributes like "swifty"… most of the time, it just means 
> "I think this is the right choice"
>
>
>

João David
iOS Developer / Researcher
CIAFEL - University of Porto
Rua Dr Plácido Costa, 91
4200-450 Porto
Portugal

+351 93 363 19 27 | Skype: joaotdavid
joao...@fade.up.pt

Please visit the iSOPARC and 
iSOFIT for iPad application website.














-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Aron Lindberg via swift-evolution]

I know it is a little old, but this is a nice read about the motivation for 
Swift's original access modifiers and why 'Protected' was not defined as an 
access level.

https://developer.apple.com/swift/blog/?id=11 
 

I think the point here is that access levels have been a heated topic since 
before Swift 1.0

> On 1 Dec 2016, at 17.12, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> This discussion has been had on this list several times already. Using a name 
> other than fileprivate, in particular, was part of the original discussion 
> and the core team selected the current spelling.
> 
> As Tino mentioned, submodules are a topic that the community has already 
> expressed some interest in incorporating in the future and is listed as a 
> possible topic by the core team for Swift 4 stage 2. At that time, it would 
> seem obvious that submodule access levels would be introduced. It seems that 
> this idea would be largely duplicative of that functionality, and it would 
> destroy the current deliberately chosen file-based design for access levels.
> 
> On Thu, Dec 1, 2016 at 08:42 João David via swift-evolution 
> > wrote:
> @Daniel, agree.
> 
> 
> Sent from my iPhone. Erroneous words are a feature, not a typo.
> 
> On 1 Dec 2016, at 14:23, Daniel Leping  > wrote:
> 
>> Gonçalo, I can suggest a bit different API to avoid clashing. Something like:
>> 
>> private (file, set)
>> 
>> Instead of:
>> 
>> private (file) (set)
>> 
>> Looks easier to me as it poses a possibility just to list the attributes in 
>> a pretty much standard way.
>> 
>> On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swift-evolution 
>> > wrote:
>> @Daniel
>> I am very fond of your idea, as I believe it add extra flexibility to this 
>> solution, as Álvaro mentioned. My only concern is somehow related to 
>> semantics.
>> Should we add the extra scope detail as you suggest, then it could clash 
>> with the current way of setting a setter as private or fileprivate:
>> 
>> Current:
>> fileprivate(set)
>> 
>> Suggested:
>> private(file)(set)
>> 
>> Still, of all the hurdles one might face, this one I believe is definitely 
>> the one that poses the less threat!
>> 
>> @Tino
>> As you imply on a previous email, this solution might even facilitate the 
>> introduction of new levels of access control all throughout modules, whether 
>> internally and externally. While I do agree complexity does raise an issue 
>> in designing a fine solution for access control, I insist this concern 
>> should not block the language's evolution into finer grained control and 
>> better focused levels of scope. Quoting Álvaro:  "communication is something 
>> that everyone agrees is a essential in swift and access control is one of 
>> the many ways developers have to properly describe (and communicate) an API."
>> 
>> Also Tino, you state:
>> "The question for me is how much complexity should be accepted as a tradeoff 
>> for increased expressiveness?
>> "private, internal, public" was quite simple, but the current system is 
>> already quite complicated, and it doesn't scale well."
>> 
>> In fact, I consider this change a great opportunity for the current system 
>> to be revisited in a gradual manner.
>> As to the equatable issue you pointed out, is there a reason why replacing 
>> the fileprivate access control level by with a typeprivate would not solve 
>> the problem raised with private?
>> 
>> There's yet another issue I would like to reinforce, one raised on previous 
>> emails. As stated before, I do believe fileprivate, as a compiler related 
>> construct, opens the door for one to access members from another member, as 
>> long as they'r all sitting within the same file. This creates conditions for 
>> a odd and dangerous pattern. While I don't think fileprivate aims at 
>> promoting several type implementation within the same file, it certainly 
>> opens that door. That's one pattern a typeprivate access control level would 
>> grant no advantages in using.
>> 
>> Best,
>> Gonçalo
>> ___
>> 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] Swift evolution proposal: introduce typeprivate access control level

[Xiaodi Wu via swift-evolution]

This discussion has been had on this list several times already. Using a
name other than fileprivate, in particular, was part of the original
discussion and the core team selected the current spelling.

As Tino mentioned, submodules are a topic that the community has already
expressed some interest in incorporating in the future and is listed as a
possible topic by the core team for Swift 4 stage 2. At that time, it would
seem obvious that submodule access levels would be introduced. It seems
that this idea would be largely duplicative of that functionality, and it
would destroy the current deliberately chosen file-based design for access
levels.

On Thu, Dec 1, 2016 at 08:42 João David via swift-evolution <
swift-evolution@swift.org> wrote:

> @Daniel, agree.
>
>
> Sent from my iPhone. Erroneous words are a feature, not a typo.
>
> On 1 Dec 2016, at 14:23, Daniel Leping  wrote:
>
> Gonçalo, I can suggest a bit different API to avoid clashing. Something
> like:
>
> private (file, set)
>
> Instead of:
>
> private (file) (set)
>
> Looks easier to me as it poses a possibility just to list the attributes
> in a pretty much standard way.
>
> On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> *@Daniel*
> I am very fond of your idea, as I believe it add extra flexibility to this
> solution, as Álvaro mentioned. My only concern is somehow related to
> semantics.
> Should we add the extra scope detail as you suggest, then it could clash
> with the current way of setting a setter as private or fileprivate:
>
> Current:
> fileprivate(set)
>
> Suggested:
> private(file)(set)
>
> Still, of all the hurdles one might face, this one I believe is definitely
> the one that poses the less threat!
>
> *@Tino*
> As you imply on a previous email, this solution might even facilitate the
> introduction of new levels of access control all throughout modules,
> whether internally and externally. While I do agree complexity does raise
> an issue in designing a fine solution for access control, I insist this
> concern should not block the language's evolution into finer grained
> control and better focused levels of scope. Quoting Álvaro:  "communication
> is something that everyone agrees is a essential in swift and access
> control is one of the many ways developers have to properly describe (and
> communicate) an API."
>
> Also Tino, you state:
> "The question for me is how much complexity should be accepted as a
> tradeoff for increased expressiveness?
> "private, internal, public" was quite simple, but the current system is
> already quite complicated, and it doesn't scale well."
>
> In fact, I consider this change a great opportunity for the current system
> to be revisited in a gradual manner.
> As to the equatable issue you pointed out, is there a reason why replacing
> the fileprivate access control level by with a typeprivate would not solve
> the problem raised with private?
>
> There's yet another issue I would like to reinforce, one raised on
> previous emails. As stated before, I do believe fileprivate, as a compiler
> related construct, opens the door for one to access members from another
> member, as long as they'r all sitting within the same file. This creates
> conditions for a odd and dangerous pattern. While I don't think fileprivate
> aims at promoting several type implementation within the same file, it
> certainly opens that door. That's one pattern a typeprivate access control
> level would grant no advantages in using.
>
> Best,
> Gonçalo
> ___
> 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] Swift evolution proposal: introduce typeprivate access control level

[João David via swift-evolution]

@Daniel, agree.

Sent from my iPhone. Erroneous words are a feature, not a typo.

> On 1 Dec 2016, at 14:23, Daniel Leping  wrote:
> 
> Gonçalo, I can suggest a bit different API to avoid clashing. Something like:
> 
> private (file, set)
> 
> Instead of:
> 
> private (file) (set)
> 
> Looks easier to me as it poses a possibility just to list the attributes in a 
> pretty much standard way.
> 
>> On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swift-evolution 
>>  wrote:
>> @Daniel
>> I am very fond of your idea, as I believe it add extra flexibility to this 
>> solution, as Álvaro mentioned. My only concern is somehow related to 
>> semantics.
>> Should we add the extra scope detail as you suggest, then it could clash 
>> with the current way of setting a setter as private or fileprivate:
>> 
>> Current:
>> fileprivate(set)
>> 
>> Suggested:
>> private(file)(set)
>> 
>> Still, of all the hurdles one might face, this one I believe is definitely 
>> the one that poses the less threat!
>> 
>> @Tino
>> As you imply on a previous email, this solution might even facilitate the 
>> introduction of new levels of access control all throughout modules, whether 
>> internally and externally. While I do agree complexity does raise an issue 
>> in designing a fine solution for access control, I insist this concern 
>> should not block the language's evolution into finer grained control and 
>> better focused levels of scope. Quoting Álvaro:  "communication is something 
>> that everyone agrees is a essential in swift and access control is one of 
>> the many ways developers have to properly describe (and communicate) an API."
>> 
>> Also Tino, you state:
>> "The question for me is how much complexity should be accepted as a tradeoff 
>> for increased expressiveness?
>> "private, internal, public" was quite simple, but the current system is 
>> already quite complicated, and it doesn't scale well."
>> 
>> In fact, I consider this change a great opportunity for the current system 
>> to be revisited in a gradual manner.
>> As to the equatable issue you pointed out, is there a reason why replacing 
>> the fileprivate access control level by with a typeprivate would not solve 
>> the problem raised with private?
>> 
>> There's yet another issue I would like to reinforce, one raised on previous 
>> emails. As stated before, I do believe fileprivate, as a compiler related 
>> construct, opens the door for one to access members from another member, as 
>> long as they'r all sitting within the same file. This creates conditions for 
>> a odd and dangerous pattern. While I don't think fileprivate aims at 
>> promoting several type implementation within the same file, it certainly 
>> opens that door. That's one pattern a typeprivate access control level would 
>> grant no advantages in using.
>> 
>> Best,
>> Gonçalo
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Daniel Leping via swift-evolution]

Gonçalo, I can suggest a bit different API to avoid clashing. Something
like:

private (file, set)

Instead of:

private (file) (set)

Looks easier to me as it poses a possibility just to list the attributes in
a pretty much standard way.

On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swift-evolution <
swift-evolution@swift.org> wrote:

> *@Daniel*
> I am very fond of your idea, as I believe it add extra flexibility to this
> solution, as Álvaro mentioned. My only concern is somehow related to
> semantics.
> Should we add the extra scope detail as you suggest, then it could clash
> with the current way of setting a setter as private or fileprivate:
>
> Current:
> fileprivate(set)
>
> Suggested:
> private(file)(set)
>
> Still, of all the hurdles one might face, this one I believe is definitely
> the one that poses the less threat!
>
> *@Tino*
> As you imply on a previous email, this solution might even facilitate the
> introduction of new levels of access control all throughout modules,
> whether internally and externally. While I do agree complexity does raise
> an issue in designing a fine solution for access control, I insist this
> concern should not block the language's evolution into finer grained
> control and better focused levels of scope. Quoting Álvaro:  "communication
> is something that everyone agrees is a essential in swift and access
> control is one of the many ways developers have to properly describe (and
> communicate) an API."
>
> Also Tino, you state:
> "The question for me is how much complexity should be accepted as a
> tradeoff for increased expressiveness?
> "private, internal, public" was quite simple, but the current system is
> already quite complicated, and it doesn't scale well."
>
> In fact, I consider this change a great opportunity for the current system
> to be revisited in a gradual manner.
> As to the equatable issue you pointed out, is there a reason why replacing
> the fileprivate access control level by with a typeprivate would not solve
> the problem raised with private?
>
> There's yet another issue I would like to reinforce, one raised on
> previous emails. As stated before, I do believe fileprivate, as a compiler
> related construct, opens the door for one to access members from another
> member, as long as they'r all sitting within the same file. This creates
> conditions for a odd and dangerous pattern. While I don't think fileprivate
> aims at promoting several type implementation within the same file, it
> certainly opens that door. That's one pattern a typeprivate access control
> level would grant no advantages in using.
>
> Best,
> Gonçalo
> ___
> 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] Proposal: Allow explicit type parameter specification in generic function call

[Adrian Zubarev via swift-evolution]

You forgot to mention Brent. ;)

-- 
Adrian Zubarev
Sent with Airmail

Am 1. Dezember 2016 um 15:03:07, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

I disagree with the suggestion. Unlike C++'s templates, a Swift's generic 
function is semantically a single function. One can say that together with a 
metatype parameter, we pass in witness table.

What I think we should do is make metatypes easier to use. Adrian and I have a 
PR that has already been waiting for almost a month: 
https://github.com/apple/swift-evolution/pull/553
Plus, removal of .self could simplify such calls.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Gonçalo Alvarez Peixoto via swift-evolution]

*@Daniel*
I am very fond of your idea, as I believe it add extra flexibility to this
solution, as Álvaro mentioned. My only concern is somehow related to
semantics.
Should we add the extra scope detail as you suggest, then it could clash
with the current way of setting a setter as private or fileprivate:

Current:
fileprivate(set)

Suggested:
private(file)(set)

Still, of all the hurdles one might face, this one I believe is definitely
the one that poses the less threat!

*@Tino*
As you imply on a previous email, this solution might even facilitate the
introduction of new levels of access control all throughout modules,
whether internally and externally. While I do agree complexity does raise
an issue in designing a fine solution for access control, I insist this
concern should not block the language's evolution into finer grained
control and better focused levels of scope. Quoting Álvaro:  "communication
is something that everyone agrees is a essential in swift and access
control is one of the many ways developers have to properly describe (and
communicate) an API."

Also Tino, you state:
"The question for me is how much complexity should be accepted as a
tradeoff for increased expressiveness?
"private, internal, public" was quite simple, but the current system is
already quite complicated, and it doesn't scale well."

In fact, I consider this change a great opportunity for the current system
to be revisited in a gradual manner.
As to the equatable issue you pointed out, is there a reason why replacing
the fileprivate access control level by with a typeprivate would not solve
the problem raised with private?

There's yet another issue I would like to reinforce, one raised on previous
emails. As stated before, I do believe fileprivate, as a compiler related
construct, opens the door for one to access members from another member, as
long as they'r all sitting within the same file. This creates conditions
for a odd and dangerous pattern. While I don't think fileprivate aims at
promoting several type implementation within the same file, it certainly
opens that door. That's one pattern a typeprivate access control level
would grant no advantages in using.

Best,
Gonçalo
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

[Anton Zhilin via swift-evolution]

I disagree with the suggestion. Unlike C++'s templates, a Swift's generic
function is semantically a single function. One can say that together with
a metatype parameter, we pass in witness table.

What I think we should do is make metatypes easier to use. *Adrian and I
have a PR* that has already been waiting for almost a month:
https://github.com/apple/swift-evolution/pull/553
Plus, removal of .self could simplify such calls.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Daniel Leping via swift-evolution]

Let's add "private (ancestors)" on top. As a framework developer I really
miss it.

On Thu, 1 Dec 2016 at 15:34 Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> @Tino: Regarding the following statement - "Even if there was a change of
> mind, fileprivate is still needed for essential things like implementing
> Equatable.”
> How exactly is that so? Am I missing something?
>
>
> class Eq: Equatable {
> private var value = 0
> }
>
> func ==(lhs: Eq, rhs: Eq) -> Bool {
> return lhs.value == rhs.value
> }
>
> This doesn't compile — but it works fine when you declare value to be
> fileprivate.
> There are other cases where fileprivate is the best choice, but this is
> quite common (of course, it's always possible to use internal instead… but
> we could as well remove all levels and keep nothing but public)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Tino Heth via swift-evolution]

> @Tino: Regarding the following statement - "Even if there was a change of 
> mind, fileprivate is still needed for essential things like implementing 
> Equatable.”
> How exactly is that so? Am I missing something?

class Eq: Equatable {
private var value = 0
}

func ==(lhs: Eq, rhs: Eq) -> Bool {
return lhs.value == rhs.value
}

This doesn't compile — but it works fine when you declare value to be 
fileprivate.
There are other cases where fileprivate is the best choice, but this is quite 
common (of course, it's always possible to use internal instead… but we could 
as well remove all levels and keep nothing but public)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Tino Heth via swift-evolution]

> private(scope) decl 
> 
> Where scope is optional and defaults to full private. Can take "file" and 
> "type" values. I.e:
> 
> private (file) var i = 1
> private func a()
> private (type) func b()
> 
> This way we can have a very fine grained access levels and maintain a better 
> structure. Who knows maybe in Swift 5 there will be need for more.
There might be submodules someday, which could be incorporated as well:
private(submodule)
or even
private(module: "MyLib", file: "Helpers.swift", type: Foo)
for a declaration that can be accessed from several locations.

We could even go further with
overridable(module) callable(subclass) func foo()

The question for me is how much complexity should be accepted as a tradeoff for 
increased expressiveness?
"private, internal, public" was quite simple, but the current system is already 
quite complicated, and it doesn't scale well.

The whole topic has come up several times, and I keep referring to file access 
rights in Unix… so afaics, we are basically talking about ACLs for source.

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

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Álvaro Monteiro via swift-evolution]

@Daniel:

Very good idea because and it makes access control much more flexible.

@Tino:

Couldn't agree with you more about the usage of "swifty". I think it's
applicable here because communication is something that everyone agrees is
a essential in swift and access control is one of the many ways developers
have to properly describe (and communicate) an API.

On Thu, Dec 1, 2016 at 10:22 AM, João David via swift-evolution <
swift-evolution@swift.org> wrote:

> Exactly. Totally agree Tino.
>
> Sent from my iPhone. Erroneous words are a feature, not a typo.
>
> On 1 Dec 2016, at 09:31, Tino Heth <2...@gmx.de> wrote:
>
>
> It also means that anybody who want to access your private var will just
> have to write an extension to expose it.
>
> imho this is wrong thinking:
> Access control is no tool to offer real "protection" — it can't stop
> someone who wants to break a system.
> Especially in the world of open source, it is merely an advice from the
> author not to do certain things.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[João David via swift-evolution]

Exactly. Totally agree Tino.

Sent from my iPhone. Erroneous words are a feature, not a typo.

> On 1 Dec 2016, at 09:31, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> It also means that anybody who want to access your private var will just 
>> have to write an extension to expose it.
> imho this is wrong thinking:
> Access control is no tool to offer real "protection" — it can't stop someone 
> who wants to break a system.
> Especially in the world of open source, it is merely an advice from the 
> author not to do certain things.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Tino Heth via swift-evolution]

> - Typeprivate would allow to abandon the odd fileprivate. Access level would 
> be constrained to swift constructs (structs, classes and extensions) and not 
> to a compiler artifact (file).
Actually, imho fileprivate isn't odd or "unswift"* — it's one of the three 
original levels, which all rely on the layout of the filesystem ("same file?" 
and "same folder/module?").
Even if there was a change of mind, fileprivate is still needed for essential 
things like implementing Equatable.

But I'm not arguing against typeprivate at all (nor against access control in 
general ;-)

- Tino

* I tend not to use attributes like "swifty"… most of the time, it just means 
"I think this is the right choice"
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Daniel Leping via swift-evolution]

How about making things more organized and move to syntax like this:

private(scope) decl

Where scope is optional and defaults to full private. Can take "file" and
"type" values. I.e:

private (file) var i = 1
private func a()
private (type) func b()

This way we can have a very fine grained access levels and maintain a
better structure. Who knows maybe in Swift 5 there will be need for more.

On Thu, 1 Dec 2016 at 12:08 Álvaro Monteiro via swift-evolution <
swift-evolution@swift.org> wrote:

> I think the idea behind this proposal is quite the contrary. It is about
> conveying the right message through the use of an expressive access control
> that addresses common use cases and leaves behind fileprivate which IMHO is
> a C inherited way of thinking.
>
> Let me try to be clear:
>
> - Private would work the same way as it does now: it would not be
> accessible through an extension.
> - Typeprivate would be accessible through an extension inside the module.
> - Typeprivate would allow to abandon the odd fileprivate. Access level
> would be constrained to swift constructs (structs, classes and extensions)
> and not to a compiler artifact (file).
> - Typeprivate would allow to address a very common use case: separate
> concerns of a swift struct/class through extensions and at the same time
> allow accessing private properties within this class/struct. At the moment
> you would have to have everything in the same file (and leverage
> fileprivate) or use internal and let it be accessible across the module.
> One good argument in favor of internal in these use cases would be that a
> given module should only be worried about what it exposes to consumers
> (public) and internally it's only a concern to the developers ("producers")
> of the module. I disagree with this because communication is one of the
> core tenets of swift and stating a property is internal just because is
> declared in another file is bizarre, unswift, error prone and it surely
> does not convey the right message the developer wants.
>
> On Thu, Dec 1, 2016 at 9:31 AM, Tino Heth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> It also means that anybody who want to access your private var will just
> have to write an extension to expose it.
>
> imho this is wrong thinking:
> Access control is no tool to offer real "protection" — it can't stop
> someone who wants to break a system.
> Especially in the world of open source, it is merely an advice from the
> author not to do certain things.
>
> ___
> 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] Swift evolution proposal: introduce typeprivate access control level

[Álvaro Monteiro via swift-evolution]

I think the idea behind this proposal is quite the contrary. It is about
conveying the right message through the use of an expressive access control
that addresses common use cases and leaves behind fileprivate which IMHO is
a C inherited way of thinking.

Let me try to be clear:

- Private would work the same way as it does now: it would not be
accessible through an extension.
- Typeprivate would be accessible through an extension inside the module.
- Typeprivate would allow to abandon the odd fileprivate. Access level
would be constrained to swift constructs (structs, classes and extensions)
and not to a compiler artifact (file).
- Typeprivate would allow to address a very common use case: separate
concerns of a swift struct/class through extensions and at the same time
allow accessing private properties within this class/struct. At the moment
you would have to have everything in the same file (and leverage
fileprivate) or use internal and let it be accessible across the module.
One good argument in favor of internal in these use cases would be that a
given module should only be worried about what it exposes to consumers
(public) and internally it's only a concern to the developers ("producers")
of the module. I disagree with this because communication is one of the
core tenets of swift and stating a property is internal just because is
declared in another file is bizarre, unswift, error prone and it surely
does not convey the right message the developer wants.

On Thu, Dec 1, 2016 at 9:31 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> It also means that anybody who want to access your private var will just
> have to write an extension to expose it.
>
> imho this is wrong thinking:
> Access control is no tool to offer real "protection" — it can't stop
> someone who wants to break a system.
> Especially in the world of open source, it is merely an advice from the
> author not to do certain things.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Tino Heth via swift-evolution]

-1

I'm more or less neutral towards the change itself, but combined with the 
breaking effect, that's a clear "no".

None the less, I hope that the whole topic with all its magic words (willSet, 
didSet, newValue, oldValue…) will be reworked in the future, which would be 
another argument not to fiddle with it now*

- Tino

* 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Tino Heth via swift-evolution]

> It also means that anybody who want to access your private var will just have 
> to write an extension to expose it.
imho this is wrong thinking:
Access control is no tool to offer real "protection" — it can't stop someone 
who wants to break a system.
Especially in the world of open source, it is merely an advice from the author 
not to do certain things.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[João David via swift-evolution]

Still better than exposing to any subclass implementation or direct external 
access IMHO.

Sent from my iPhone. Erroneous words are a feature, not a typo.

> On 1 Dec 2016, at 07:40, Jean-Daniel  wrote:
> 
> If you add a typeprivate accessor,  it means you expose your internal details 
> to all extensions and so breaks encapsulation.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution