Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Jun 28, 2016, at 10:51 PM, Paulo Faria  wrote:
> 
> 
>> On Jun 29, 2016, at 2:48 AM, Austin Zheng  wrote:
>> 
>> If you tested it, there's a problem with the current behavior independent of 
>> associated type inference, and it should be fixed whether or not the 
>> proposal is accepted.
> 
> I don’t think it should be an error. Normally we can have any number of 
> functions with the same name but different return types. By failing in this 
> specific case would be like saying that when you implement a protocol with an 
> associated type you can only return what’s defined in the associated type. I 
> don’t think that should be the behaviour we expect.

This seems very related to the near-miss checking I mentioned in my other reply 
to Austin. 

  - Doug

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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Paulo Faria via swift-evolution]

> On Jun 29, 2016, at 2:48 AM, Austin Zheng  wrote:
> 
> If you tested it, there's a problem with the current behavior independent of 
> associated type inference, and it should be fixed whether or not the proposal 
> is accepted.

I don’t think it should be an error. Normally we can have any number of 
functions with the same name but different return types. By failing in this 
specific case would be like saying that when you implement a protocol with an 
associated type you can only return what’s defined in the associated type. I 
don’t think that should be the behaviour we expect.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Austin Zheng via swift-evolution]

If you tested it, there's a problem with the current behavior independent of 
associated type inference, and it should be fixed whether or not the proposal 
is accepted.

> On Jun 28, 2016, at 10:47 PM, Paulo Faria  wrote:
> 
> 
>> On Jun 29, 2016, at 2:28 AM, Austin Zheng > > wrote:
>> 
>> I'm not sure this is a problem. Once you bind the associated types 
>> explicitly, the requirements using those associated types need to match the 
>> bound types otherwise the type checker will emit an error. If you have 
>> default associated types and default implementations, but then bind the 
>> associated types differently and do not update your type-specific 
>> implementations to use those other types, you will get an error message. 
>> This is how explicitly specifying associated types works today.
>> 
>> Austin
> 
> The problem is that it doesn’t give me any error message. I tested it.
>  
> 
> 

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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Jun 28, 2016, at 10:45 PM, Austin Zheng  wrote:
> 
> Thank you for your detailed feedback. Would it be helpful if I prepared a PR?

Yes, it would be very helpful. 

  - Doug

> 
> Austin
> 
>>> On Jun 28, 2016, at 10:33 PM, Douglas Gregor  wrote:
>>> 
>>> 
>>> On Jun 24, 2016, at 10:50 PM, Austin Zheng via swift-evolution 
>>>  wrote:
>>> 
>>> Hello all,
>>> 
>>> Per Chris Lattner's list of open Swift 3 design topics 
>>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put 
>>> together a proposal for removing type inference for associated types.
>>> 
>>> It can be found here: 
>>> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/-remove-assoctype-inference.md
>>> 
>>> Thoughts, criticism, and feedback welcome. There are at least two slightly 
>>> different designs in the proposal, and I'm sure people will have ideas for 
>>> even more.
>> 
>> Thanks for working on this. I have a couple of comments.
>> 
>> I don’t think we should be adding the ability to write ‘associatedtype’ 
>> declarations in classes/structs/enums. We already have the ability to 
>> explicitly state the associated type witness by declaring a typealias, 
>> struct, enum, or class with the appropriate name. Indeed, I feel like a lot 
>> of complexity of the proposal is linked to adding  ‘associatedtype’ 
>> declarations into the language, and I’d rather this proposal stay narrow.
>> 
>> I think it’s important for this proposal to show the other ways in which one 
>> can get associated type witnesses without writing them explicitly in the 
>> conforming type, even once inference goes away. For example, we have 
>> associated type defaults, e.g.,
>> 
>>  protocol P {
>>associatedtype Associated = Int
>>  }
>> 
>>  struct X : P {
>>// Associated becomes Int if not otherwise specified
>>  }
>> 
>> and with typealiases in protocol extensions becoming real and useful, one 
>> could also use protocol extensions:
>> 
>>  protocol P2 {
>>associatedtype Index
>>  }
>> 
>>  extension P2 {
>>typealias Index = Int
>>  }
>> 
>> which, of course, implies that one can use various tricks with constrained 
>> protocol extensions and such. There isn’t any proposed change here, but it 
>> illustrates that Swift programmers aren’t without recourse if type inference 
>> for associated types go away.
>> 
>> One concern with applying the above tricks is that existing code can change 
>> meaning when inference goes away. For example, let’s think about the 
>> “Iterator” type of a Sequence. It already uses default associated type 
>> witnesses (not associated type witness inference!) to give a default of 
>> IndexingIterator, e.g.,
>> 
>>  protocol Sequence {
>>associatedtype Iterator: IteratorType
>>func makeIterator() -> Iterator
>>  }
>> 
>>  protocol Collection : Sequence {
>>associatedtype Iterator = IndexingIterator
>>func makeIterator() -> Iterator  // redeclaration helps inference
>>  }
>> 
>> When a type that conforms to Collection doesn’t provide makeIterator, it 
>> gets a default one via:
>> 
>>  extension Collection where Iterator == IndexingIterator {
>>public func makeIterator() -> IndexingIterator { … }
>>  }
>> 
>> That will still work (yay). However, simply removing associated type 
>> inference means that a collection type that *does* provide 
>> makeIterator()—but not, directly, Iterator—would change behavior:
>> 
>>  struct IntCollection : Collection {
>>typealias Element = Int
>>func makeIterator() -> IntCollectionIterator { … }
>>  }
>> 
>> With associated type inference, we infer Iterator = IntCollectionIterator 
>> and select IntCollection.makeIterator() to satisfy the makeIterator() 
>> requirement.
>> 
>> Without associated type inference, we use the default Iterator = 
>> IndexingIterator and select the makeIterator() from the protocol 
>> extension (because IntCollection.makeIterator() now returns the wrong type), 
>> which turns an error of omission into an unpleasant surprise. We might need 
>> something like near-miss checking for defaulted protocol requirements (which 
>> we discussed in the thread at 
>> http://thread.gmane.org/gmane.comp.lang.swift.devel/1799) to help find those 
>> surprises. They already exist today, of course, but removing associated type 
>> inference would make them worse.
>> 
>> Finally, one of the chief concerns is that we won’t be able to provide a 
>> nice experience when conforming to the standard library’s collection 
>> protocols. I would *love* to see some more thought to into how we can use 
>> the above tools to handle it, although I suspect the only way to do that is 
>> to implement some part of this proposal experimentally and see what it takes 
>> to get the standard library and it’s tests 

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Paulo Faria via swift-evolution]

> On Jun 29, 2016, at 2:28 AM, Austin Zheng  wrote:
> 
> I'm not sure this is a problem. Once you bind the associated types 
> explicitly, the requirements using those associated types need to match the 
> bound types otherwise the type checker will emit an error. If you have 
> default associated types and default implementations, but then bind the 
> associated types differently and do not update your type-specific 
> implementations to use those other types, you will get an error message. This 
> is how explicitly specifying associated types works today.
> 
> Austin

The problem is that it doesn’t give me any error message. I tested it.
 


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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Douglas Gregor via swift-evolution]

> On Jun 24, 2016, at 10:50 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> Per Chris Lattner's list of open Swift 3 design topics 
> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369 
> ), I've put 
> together a proposal for removing type inference for associated types.
> 
> It can be found here: 
> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/-remove-assoctype-inference.md
>  
> 
> 
> Thoughts, criticism, and feedback welcome. There are at least two slightly 
> different designs in the proposal, and I'm sure people will have ideas for 
> even more.

Thanks for working on this. I have a couple of comments.

I don’t think we should be adding the ability to write ‘associatedtype’ 
declarations in classes/structs/enums. We already have the ability to 
explicitly state the associated type witness by declaring a typealias, struct, 
enum, or class with the appropriate name. Indeed, I feel like a lot of 
complexity of the proposal is linked to adding  ‘associatedtype’ declarations 
into the language, and I’d rather this proposal stay narrow.

I think it’s important for this proposal to show the other ways in which one 
can get associated type witnesses without writing them explicitly in the 
conforming type, even once inference goes away. For example, we have associated 
type defaults, e.g.,

protocol P {
  associatedtype Associated = Int
}

struct X : P {
  // Associated becomes Int if not otherwise specified
}

and with typealiases in protocol extensions becoming real and useful, one could 
also use protocol extensions:

protocol P2 {
  associatedtype Index
}

extension P2 {
  typealias Index = Int
}

which, of course, implies that one can use various tricks with constrained 
protocol extensions and such. There isn’t any proposed change here, but it 
illustrates that Swift programmers aren’t without recourse if type inference 
for associated types go away.

One concern with applying the above tricks is that existing code can change 
meaning when inference goes away. For example, let’s think about the “Iterator” 
type of a Sequence. It already uses default associated type witnesses (not 
associated type witness inference!) to give a default of 
IndexingIterator, e.g.,

protocol Sequence {
  associatedtype Iterator: IteratorType
  func makeIterator() -> Iterator
}

protocol Collection : Sequence {
  associatedtype Iterator = IndexingIterator
  func makeIterator() -> Iterator  // redeclaration helps inference
}

When a type that conforms to Collection doesn’t provide makeIterator, it gets a 
default one via:

extension Collection where Iterator == IndexingIterator {
  public func makeIterator() -> IndexingIterator { … }
}

That will still work (yay). However, simply removing associated type inference 
means that a collection type that *does* provide makeIterator()—but not, 
directly, Iterator—would change behavior:

struct IntCollection : Collection {
  typealias Element = Int
  func makeIterator() -> IntCollectionIterator { … }
}

With associated type inference, we infer Iterator = IntCollectionIterator and 
select IntCollection.makeIterator() to satisfy the makeIterator() requirement.

Without associated type inference, we use the default Iterator = 
IndexingIterator and select the makeIterator() from the protocol 
extension (because IntCollection.makeIterator() now returns the wrong type), 
which turns an error of omission into an unpleasant surprise. We might need 
something like near-miss checking for defaulted protocol requirements (which we 
discussed in the thread at 
http://thread.gmane.org/gmane.comp.lang.swift.devel/1799) to help find those 
surprises. They already exist today, of course, but removing associated type 
inference would make them worse.

Finally, one of the chief concerns is that we won’t be able to provide a nice 
experience when conforming to the standard library’s collection protocols. I 
would *love* to see some more thought to into how we can use the above tools to 
handle it, although I suspect the only way to do that is to implement some part 
of this proposal experimentally and see what it takes to get the standard 
library and it’s tests working again. How far can the tools above go toward 
reducing the need to specify various associated type witnesses in conforming 
types? What are the surprises?

- Doug


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

Re: [swift-evolution] [Proposal draft] NSError bridging

[Riley Testut via swift-evolution]

Love the proposal overall, but not sure about the CustomNSError name either. It 
doesn’t seem to read like a Swift protocol name.
 
Somewhat related, is there a reason these protocols don’t contain the 
“Protocol” suffix? Stands in stark contrast with the rest of the Swift protocol 
naming conventions (AFAIK).

> On Jun 28, 2016, at 4:33 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> Obviously, I’m in favor of this one. +1!
>> 
>> I think I did prefer the older name of CustomUserInfoError for the 
>> domain/code/userInfo protocol, rather than CustomNSError. This is just 
>> because I’d like to be able to do a global search through my project for 
>> “NSError” and have it turn up empty. Maybe a silly reason, I know. ;-)
> 
> 
> I’m floating CustomNSError as the protocol name because I don’t feel that 
> domain, core, or userInfo are fundamental to the Swift error model—they’re 
> about exposing things specifically to NSError.
> 
>   - Doug
> 
> ___
> 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] Remove type inference for associated types

[Austin Zheng via swift-evolution]

I'm not sure this is a problem. Once you bind the associated types explicitly, 
the requirements using those associated types need to match the bound types 
otherwise the type checker will emit an error. If you have default associated 
types and default implementations, but then bind the associated types 
differently and do not update your type-specific implementations to use those 
other types, you will get an error message. This is how explicitly specifying 
associated types works today.

Austin

> On Jun 28, 2016, at 10:17 PM, Paulo Faria via swift-evolution 
>  wrote:
> 
> 
>> On Jun 29, 2016, at 1:51 AM, Douglas Gregor > > wrote:
>> 
>> which might reduce the common case for conforming to the protocol to be, 
>> e.g.,
> 
> Just discovered another horrible implication of type inference removal for 
> the same use case. :OOO
> 
> This is the full code for the protocol
> 
> public protocol ResourceController {
> associatedtype DetailID: PathParameterInitializable = UpdateID
> associatedtype UpdateID: PathParameterInitializable
> associatedtype DestroyID: PathParameterInitializable = UpdateID
> 
> associatedtype CreateInput: StructuredDataInitializable = UpdateInput
> associatedtype UpdateInput: StructuredDataInitializable
> 
> associatedtype ListOutput: StructuredDataFallibleRepresentable = 
> UpdateOutput
> associatedtype CreateOutput: StructuredDataFallibleRepresentable = 
> UpdateOutput
> associatedtype DetailOutput: StructuredDataFallibleRepresentable = 
> UpdateOutput
> associatedtype UpdateOutput: StructuredDataFallibleRepresentable
> 
> func list() throws -> [ListOutput]
> func create(element: CreateInput) throws -> CreateOutput
> func detail(id: DetailID) throws -> DetailOutput
> func update(id: UpdateID, element: UpdateInput) throws -> UpdateOutput
> func destroy(id: DestroyID) throws
> }
> 
> extension ResourceController {
> public func list() throws -> [ListOutput] {
> throw ClientError.notFound
> }
> 
> public func create(element: CreateInput) throws -> CreateOutput {
> throw ClientError.notFound
> }
> 
> public func detail(id: DetailID) throws -> DetailOutput {
> throw ClientError.notFound
> }
> 
> public func update(id: UpdateID, element: UpdateInput) throws -> 
> UpdateOutput {
> throw ClientError.notFound
> }
> 
> public func destroy(id: DestroyID) throws {
> throw ClientError.notFound
> }
> }
> 
> Suppose we have an implementation like this:
> 
> public struct TodoController : ResourceController {
> public typealias CreateInput = NotTodo
> public typealias UpdateInput = NotTodo
> 
> public typealias ListOutput = NotTodo
> public typealias CreateOutput = NotTodo
> public typealias DetailOutput = NotTodo
> public typealias UpdateOutput = NotTodo
> 
> public typealias DetailID = NotString
> public typealias UpdateID = NotString
> public typealias DestroyID = NotString
> 
> public func list() throws -> [Todo] {
> ...
> }
> 
> public func create(element todo: Todo) throws -> Todo {
> ...
> }
> 
> public func detail(id: String) throws -> Todo {
> ...
> }
> 
> public func update(id: String, element todo: Todo) throws -> Todo {
> ...
> }
> 
> public func destroy(id: String) throws {
> ...
> }
> }
> 
> Notice that the typealiases and the function declarations don’t match. But 
> the compiler doesn’t complain because the protocol has default 
> implementations in the protocol extension. This means that if the person 
> implementing the protocol doesn’t make sure the types match exactly, there’s 
> gonna be unexpected behaviour. Which I’m sure he/she will take quite some 
> time to figure out. :(
> 
> 
> ___
> 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] Remove type inference for associated types

[Paulo Faria via swift-evolution]

> On Jun 29, 2016, at 1:51 AM, Douglas Gregor  wrote:
> 
> which might reduce the common case for conforming to the protocol to be, e.g.,

Just discovered another horrible implication of type inference removal for the 
same use case. :OOO

This is the full code for the protocol

public protocol ResourceController {
associatedtype DetailID: PathParameterInitializable = UpdateID
associatedtype UpdateID: PathParameterInitializable
associatedtype DestroyID: PathParameterInitializable = UpdateID

associatedtype CreateInput: StructuredDataInitializable = UpdateInput
associatedtype UpdateInput: StructuredDataInitializable

associatedtype ListOutput: StructuredDataFallibleRepresentable = 
UpdateOutput
associatedtype CreateOutput: StructuredDataFallibleRepresentable = 
UpdateOutput
associatedtype DetailOutput: StructuredDataFallibleRepresentable = 
UpdateOutput
associatedtype UpdateOutput: StructuredDataFallibleRepresentable

func list() throws -> [ListOutput]
func create(element: CreateInput) throws -> CreateOutput
func detail(id: DetailID) throws -> DetailOutput
func update(id: UpdateID, element: UpdateInput) throws -> UpdateOutput
func destroy(id: DestroyID) throws
}

extension ResourceController {
public func list() throws -> [ListOutput] {
throw ClientError.notFound
}

public func create(element: CreateInput) throws -> CreateOutput {
throw ClientError.notFound
}

public func detail(id: DetailID) throws -> DetailOutput {
throw ClientError.notFound
}

public func update(id: UpdateID, element: UpdateInput) throws -> 
UpdateOutput {
throw ClientError.notFound
}

public func destroy(id: DestroyID) throws {
throw ClientError.notFound
}
}

Suppose we have an implementation like this:

public struct TodoController : ResourceController {
public typealias CreateInput = NotTodo
public typealias UpdateInput = NotTodo

public typealias ListOutput = NotTodo
public typealias CreateOutput = NotTodo
public typealias DetailOutput = NotTodo
public typealias UpdateOutput = NotTodo

public typealias DetailID = NotString
public typealias UpdateID = NotString
public typealias DestroyID = NotString

public func list() throws -> [Todo] {
...
}

public func create(element todo: Todo) throws -> Todo {
...
}

public func detail(id: String) throws -> Todo {
...
}

public func update(id: String, element todo: Todo) throws -> Todo {
...
}

public func destroy(id: String) throws {
...
}
}

Notice that the typealiases and the function declarations don’t match. But the 
compiler doesn’t complain because the protocol has default implementations in 
the protocol extension. This means that if the person implementing the protocol 
doesn’t make sure the types match exactly, there’s gonna be unexpected 
behaviour. Which I’m sure he/she will take quite some time to figure out. :(


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

Re: [swift-evolution] Optionals and nil in Switch statement

[Charlie Monroe via swift-evolution]

I nevertheless think that this is a bug and should be addressed. There is no 
reason where

if stringOptional == stringNonOptional { ... }

works, but pretty much the same construct doesn't work in the switch-case. It 
should be perhaps solved via a bugreport at http://bugs.swift.org 
 and via evolution, though...

> On Jun 29, 2016, at 12:31 AM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> I just got home and tested. The answer is yes, `case "text"?` does work.
> 
> let optStr : String? = "text"
> switch optStr {
> case nil : print("Nil")
> case "text"? : print("Success")
> default  : print("Default")
> }
> // Prints `Success`
> 
> 
> Nevin
> 
> On Tue, Jun 28, 2016 at 12:27 PM, Nevin Brackett-Rozinsky 
> > 
> wrote:
> Does `case "text"?` work?
> 
> 
> On Tuesday, June 28, 2016, Kevin Nattinger via swift-evolution 
> > wrote:
> Case .none:
> Case .some("string"):
> 
> 
> On Jun 28, 2016, at 06:40, Lucas Jordan via swift-evolution 
> > wrote:
> 
>> Forgive me if this was/is discussed already, I am new to the process here
>> 
>> (code is attached as a playground too)
>> 
>> 
>> 
>> Sometimes when I am working with a String? nil can be a reasonable value, 
>> and what I want to do is something like the following:
>> 
>> import UIKit
>> 
>> 
>> 
>> var str:String? = "Hello, playground"
>> 
>> 
>> 
>> switch str{
>> 
>> case nil:
>> 
>> print("Nil!")
>> 
>> case "Hello, playground":  //it would be super nice if this worked.
>> 
>> print("Match")
>> 
>> default:
>> 
>> print("Some other non nil value?")
>> 
>> }
>> 
>> 
>> 
>> But it does not work, the orange  text is a compile time error, "Expression 
>> pattern of type 'String' cannot match value of type 'String?'. I realize 
>> that this can be replaced with a let statement (case let s where s == 
>> "Hello, playground":), but that is verbose. 
>> 
>> Seems like the compiler could be OK with the orange text, since it is 
>> clearly not nil.
>> 
>> Thoughts?
>> 
>> -Lucas
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] [Returned for revision] SE-0077: Improved operator declarations

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

On Jun 28, 2016, at 6:32 PM, John McCall  wrote:

>> On Jun 28, 2016, at 9:12 AM, L. Mihalkovic  
>> wrote:
>> 
>> Question inline
>> Regards
>> LM
>> (From mobile)
>> On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution 
>>  wrote:
>> 
 On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution 
  wrote:
 I replaced `precedencegroup` with `precedence` and added `Precedence` 
 suffix to all precedence group names. See:
 
 https://github.com/Anton3/swift-evolution/blob/fix-operator-
 precedence/proposals/0077-operator-precedence.md
 
 My feelings:
 1. `precedencegroup` describes what it declares more precisely
 2. `precedence` is shorter (partially compensating for longer names)
 3. `precedence` can be correctly interpreted as "precedence level"
 4. `precedence` looks nicer overall
>>> 
>>> Keep in mind that this is a pretty marginal feature.  I'm not sure 
>>> "precedence" is a reasonable enough thing to take as a keyword for it.
>>> 
>>> John.
>> 
>> Would a meta-circular definition be possible (proposed a version using 
>> enums)? I remember a mail from chris about moving certain things currently 
>> backed into the compiler towards the stdlib, is this one a possible 
>> candidate...
> 
> This is already strongly library-determined.  The library defines what 
> operators exist and defines their precedence w.r.t. each other and a small 
> number of built-in operators.  Operator precedence has to be communicated to 
> the compiler somehow in order to parse code.  This proposal is just deciding 
> the syntax of that communication.
> 
> I see no reason to use a more conceptually complex approach when a simple 
> declaration will do.

Np... I thought that enums instead of keywords would also make them naturally 
discoverable when a reflection API gets created. Felt odd to see so many new 
language keywd assigned to a single feature. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Partial list of open Swift 3 design topics

[Dmitri Gribenko via swift-evolution]

On Tue, Jun 28, 2016 at 10:03 PM, David Waite
 wrote:
>
> On Jun 28, 2016, at 10:15 PM, Dmitri Gribenko via swift-evolution
>  wrote:
>
> On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution
>  wrote:
>
>
> I am also for removing associated type inference, and I guess if it needs to
> be done, its now. Concerning SubSequence, isn’t that supposed to be away
> post Swift-3 once we have some of the more powerful generics?
>
>
> I'm not aware of any generics features that will allow us to remove
> SubSequence.
>
>
> Generalized existentials provide an intelligent default value on Sequence
> for SubSequence and Iterator, if Element was an associated type. There would
> still be efficiencies possible if you were able to specify these associated
> types as concrete types.

I would be very concerned about performance regressions because of
SubSequence being defined as an existential.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Yep, that’s what I meant. I should probably go back and re-write the
proposal if it’s not clear.

BTW, when does the window for proposals close? Is this in the scope for
Swift 3?


On Tue, Jun 28, 2016 at 9:54 PM David Waite 
wrote:

> Hi Saagar,
>
> If I understand your proposal correctly, you are suggesting that we remove
> T! and just force people to use T? or T.  This is a commonly rejected
> proposal (though not on the list yet) that frequently comes up.  The
> problem with your proposal is that you don’t provide any solutions to the
> problems that T! is currently solving: that of two-phase initialization and
> importing of APIs that have not been nullability audited.  It isn’t
> pragmatic to handle these cases as T?
>
> -Chris
>
>
> Chris,
>
> I believe he only is speaking to removing the ability to use IUOs as
> function parameters, not as properties (for 2-phase init) or return values
> (for unaudited API). The question would be what the impact would be of
> unaudited API being imported as accepting an explicit optional rather than
> IUO.
>
> -DW
>
>
> Remove implicitly unwrapped optionals as function parameters
>
>- Proposal: SE-
>- Author: Swift Developer 
>- Status: *Awaiting review*
>- Review manager: TBD
>
> Introduction
>
> Swift, in contrast with Objective-C, makes a distinction between values
> that may be nil and values that can never be nil through its use of
> Optionals. Due to the fact that Objective-C does not make this distinction,
> Objective-C functions that do not use the Nullability
>  annotations are imported
> with parameters of the implicitly unwrapped optional type. Unfortunately,
> this allows users to write their own Swift code that looks like this:
>
> func foo(bar: Int!) {
> //…
> }
>
> Due to the confusion this may cause, we would like to propose the *removal
> of implicitly unwrapped optionals as function parameters*. Discussion on
> this topic may be found here
> .
> Motivation
>
> Implicitly unwrapped optionals are currently allowed in function
> declarations. Consider the following function:
>
> func triple(forceUnwrapping aNumber: Int) -> Int {
> return aNumber * 3
> }
>
> let possiblyNil = Int("foo")
> triple(forceUnwrapping: possiblyNil)
>
> possiblyNil is an Int?; thus, this example will not compile due to
> triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift
> beginner writing code that looks like this to "fix" the problem:
>
> func triple(forceUnwrapping aNumber: Int!) -> Int {
> return aNumber * 3
> }
>
> let possiblyNil = Int("foo")
> triple(forceUnwrapping: possiblyNil)
>
> While this version compiles, it crashes due to the force unwrapping of a
> nil value. Unfortunately, the compiler "hides" this fact by making it
> seem like it's acceptable to pass in nil–it doesn't make the forced
> unwrapping *explicit*.
> Proposed solution
>
> The safest solution, in this case, is to prevent the use of implicitly
> unrwapped optionals in function signatures. By forcing users to write
>
> func triple(forceUnwrapping aNumber: Int) -> Int {
> return aNumber * 3
> }
>
> or
>
> func triple(forceUnwrapping aNumber: Int?) -> Int {
> return aNumber * 3
> }
>
> the compiler will complain, reminding users that they should probably
> attempt to safely unwrap the optional before using it.
> Detailed design
>
> The proposal will prevent the use of implicitly unwrapped optionals in
> function signatures for both Swift code as well as imported Objective-C
> code. As non-annotated Objective-C functions are currently imported as
> implicitly unwrapped, they will be converted to optionals as a preliminary
> step. Non-audited frameworks can be audited in the future so that they can
> be tagged with _Nonnull if necessary.
> Impact on existing code
>
> This is a proposal is a source breaking change, but it should be easily
> mitigated using a migrator. Existing functions with implicitly unwrapped
> optionals can be changed to optional; users can easily shadow variables
> with a guard or change their function to non-optional.
> Alternatives consideredImporting Objective-C functions as-is, but
> disallowing implictly unwrapped optionals in Swift code
>
> This reduces the burden on existing frameworks and adding Nullability
> annotations, but creates a sort of disconnect between Objective-C and Swift
> in that it prevents Swift developers from writing functions with implicitly
> unwrapped optionals.
> Doing nothing
>
> Obviously, this has the benefit of keeping the current behavior and not
> requiring a migrator. However, I believe that the unsafe behavior that this
> encourages is not worth keeping.
>
>
> On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko 
> wrote:
>
>> +1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a

Re: [swift-evolution] Partial list of open Swift 3 design topics

[David Waite via swift-evolution]

> On Jun 28, 2016, at 10:15 PM, Dmitri Gribenko via swift-evolution 
>  wrote:
> 
> On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution
> > wrote:
>> 
>> 
>> I am also for removing associated type inference, and I guess if it needs to
>> be done, its now. Concerning SubSequence, isn’t that supposed to be away
>> post Swift-3 once we have some of the more powerful generics?
> 
> I'm not aware of any generics features that will allow us to remove 
> SubSequence.

Generalized existentials provide an intelligent default value on Sequence for 
SubSequence and Iterator, if Element was an associated type. There would still 
be efficiencies possible if you were able to specify these associated types as 
concrete types.

-DW


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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Paulo Faria via swift-evolution]

> On Jun 29, 2016, at 1:51 AM, Douglas Gregor  wrote:
> 
> which might reduce the common case for conforming to the protocol to be, e.g.,

But yeah! I guess that could help In the case the type is the same! Thanks for 
the tip.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Paulo Faria via swift-evolution]

> On Jun 29, 2016, at 1:51 AM, Douglas Gregor  wrote:
> 
> Do these associated types have meaningful defaults? We’re not talking about 
> eliminating the ability to have default types for associated types, e.g.,
> 
>   public protocol ResourceController {
> associatedtype CreateInput
> associatedtype UpdateInput = CreateInput
> 
> associatedtype ListOutput
> associatedtype CreateOutput = ListOutput
> associatedtype DetailOutput = ListOutput
> associatedtype UpdateOutput = ListOutput
> 
> associatedtype DetailID
> associatedtype UpdateID = DetailID
> associatedtype DestroyID = DetailID
>   }
> 
> which might reduce the common case for conforming to the protocol to be, e.g.,
> 
>   extension TodoController : ResourceController {
> public typealias CreateInput = Todo
> public typealias ListOutput = Todo
> public typealias DetailID = String
>   }
> 
>   - Doug

Unfortunately no. The whole purpose of having so many associated types is that 
the user can simply chose the types he wants to use as the input and output of 
each function required in the protocol.

public protocol ResourceController {
associatedtype CreateInput: StructuredDataInitializable
associatedtype UpdateInput: StructuredDataInitializable

associatedtype ListOutput: StructuredDataFallibleRepresentable
associatedtype CreateOutput: StructuredDataFallibleRepresentable
associatedtype DetailOutput: StructuredDataFallibleRepresentable
associatedtype UpdateOutput: StructuredDataFallibleRepresentable

associatedtype DetailID: PathParameterInitializable
associatedtype UpdateID: PathParameterInitializable
associatedtype DestroyID: PathParameterInitializable

func list() throws -> [ListOutput]
func create(element: CreateInput) throws -> CreateOutput
func detail(id: DetailID) throws -> DetailOutput
func update(id: UpdateID, element: UpdateInput) throws -> UpdateOutput
func destroy(id: DestroyID) throws
}



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

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[David Waite via swift-evolution]

> Hi Saagar,
> 
> If I understand your proposal correctly, you are suggesting that we remove T! 
> and just force people to use T? or T.  This is a commonly rejected proposal 
> (though not on the list yet) that frequently comes up.  The problem with your 
> proposal is that you don’t provide any solutions to the problems that T! is 
> currently solving: that of two-phase initialization and importing of APIs 
> that have not been nullability audited.  It isn’t pragmatic to handle these 
> cases as T?
> 
> -Chris

Chris,

I believe he only is speaking to removing the ability to use IUOs as function 
parameters, not as properties (for 2-phase init) or return values (for 
unaudited API). The question would be what the impact would be of unaudited API 
being imported as accepting an explicit optional rather than IUO.

-DW
> 
>> Remove implicitly unwrapped optionals as function parameters
>> 
>> Proposal: SE- 
>> 
>> Author: Swift Developer 
>> Status: Awaiting review
>> Review manager: TBD
>> Introduction
>> 
>> Swift, in contrast with Objective-C, makes a distinction between values that 
>> may be nil and values that can never be nil through its use of Optionals. 
>> Due to the fact that Objective-C does not make this distinction, Objective-C 
>> functions that do not use the Nullability 
>>  annotations are imported 
>> with parameters of the implicitly unwrapped optional type. Unfortunately, 
>> this allows users to write their own Swift code that looks like this:
>> 
>> func foo(bar: Int!) {
>> //…
>> }
>> Due to the confusion this may cause, we would like to propose the removal of 
>> implicitly unwrapped optionals as function parameters. Discussion on this 
>> topic may be found here 
>> .
>> 
>> Motivation
>> 
>> Implicitly unwrapped optionals are currently allowed in function 
>> declarations. Consider the following function:
>> 
>> func triple(forceUnwrapping aNumber: Int) -> Int {
>> return aNumber * 3
>> }
>> 
>> let possiblyNil = Int("foo")
>> triple(forceUnwrapping: possiblyNil)
>> possiblyNil is an Int?; thus, this example will not compile due to 
>> triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift 
>> beginner writing code that looks like this to "fix" the problem:
>> 
>> func triple(forceUnwrapping aNumber: Int!) -> Int {
>> return aNumber * 3
>> }
>> 
>> let possiblyNil = Int("foo")
>> triple(forceUnwrapping: possiblyNil)
>> While this version compiles, it crashes due to the force unwrapping of a nil 
>> value. Unfortunately, the compiler "hides" this fact by making it seem like 
>> it's acceptable to pass in nil–it doesn't make the forced unwrapping 
>> explicit.
>> 
>> Proposed solution
>> 
>> The safest solution, in this case, is to prevent the use of implicitly 
>> unrwapped optionals in function signatures. By forcing users to write
>> 
>> func triple(forceUnwrapping aNumber: Int) -> Int {
>> return aNumber * 3
>> }
>> or
>> 
>> func triple(forceUnwrapping aNumber: Int?) -> Int {
>> return aNumber * 3
>> }
>> the compiler will complain, reminding users that they should probably 
>> attempt to safely unwrap the optional before using it.
>> 
>> Detailed design
>> 
>> The proposal will prevent the use of implicitly unwrapped optionals in 
>> function signatures for both Swift code as well as imported Objective-C 
>> code. As non-annotated Objective-C functions are currently imported as 
>> implicitly unwrapped, they will be converted to optionals as a preliminary 
>> step. Non-audited frameworks can be audited in the future so that they can 
>> be tagged with _Nonnull if necessary.
>> 
>> Impact on existing code
>> 
>> This is a proposal is a source breaking change, but it should be easily 
>> mitigated using a migrator. Existing functions with implicitly unwrapped 
>> optionals can be changed to optional; users can easily shadow variables with 
>> a guard or change their function to non-optional.
>> 
>> Alternatives considered
>> 
>> Importing Objective-C functions as-is, but disallowing implictly unwrapped 
>> optionals in Swift code
>> 
>> This reduces the burden on existing frameworks and adding Nullability 
>> annotations, but creates a sort of disconnect between Objective-C and Swift 
>> in that it prevents Swift developers from writing functions with implicitly 
>> unwrapped optionals.
>> 
>> Doing nothing
>> 
>> Obviously, this has the benefit of keeping the current behavior and not 
>> requiring a migrator. However, I believe that the unsafe behavior that this 
>> encourages is not worth keeping.
>> 
>> 
>> 
>> On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko > > wrote:
>> +1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a 
>> carryover from Java. They show up in method signatures from 
>> non-nullable-annotated 

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Douglas Gregor via swift-evolution]

> On Jun 28, 2016, at 9:45 PM, Paulo Faria  wrote:
> 
> 
>> On Jun 28, 2016, at 3:34 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
 Finally, I am very concerned that there are protocols such as Collection,
 with many inferrable associated types, and that conforming to these
 protocols could become *much* uglier.
> 
> Unfortunately I have a specific use case in which this argument would be very 
> strong.
> 
> Basically this:
> 
> extension TodoController : ResourceController {}
> 
> Would have to become this:
> 
> extension TodoController : ResourceController {
> public typealias CreateInput = Todo
> public typealias UpdateInput = Todo
> 
> public typealias ListOutput = Todo
> public typealias CreateOutput = Todo
> public typealias DetailOutput = Todo
> public typealias UpdateOutput = Todo
> 
> public typealias DetailID = String
> public typealias UpdateID = String
> public typealias DestroyID = String
> }
> 
> I could reduce the amount of associated types but this would reduce the 
> flexibility of the protocol by a huge factor and would make it much less 
> powerful. I’m very torn about this because I do want generics to get better. 
> Specifically I’m looking forward to conditional conformances. But this would 
> be a too high cost imho. I know this is just one example. But maybe there are 
> more examples like this out there. I have to admit this one really got to me. 
> :(


Do these associated types have meaningful defaults? We’re not talking about 
eliminating the ability to have default types for associated types, e.g.,

public protocol ResourceController {
  associatedtype CreateInput
  associatedtype UpdateInput = CreateInput

  associatedtype ListOutput
  associatedtype CreateOutput = ListOutput
  associatedtype DetailOutput = ListOutput
  associatedtype UpdateOutput = ListOutput

  associatedtype DetailID
  associatedtype UpdateID = DetailID
  associatedtype DestroyID = DetailID
}

which might reduce the common case for conforming to the protocol to be, e.g.,

extension TodoController : ResourceController {
  public typealias CreateInput = Todo
  public typealias ListOutput = Todo
  public typealias DetailID = String
}

- Doug

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

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 28, 2016, at 8:04 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Jun 27, 2016, at 1:26 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> Hey, all. An engineer at Apple noticed the following behavior:
>> 
>> 1. class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) 
>> runtime name
>> 2. @objc class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) 
>> runtime name
>> 3. @objc(Foo) class Foo: NSObject → exposed to Objective-C, unmangled 
>> runtime name
>> 
>> (and 4. @objc class Foo → illegal, classes must have ObjC heritage to be 
>> @objc.)
>> 
>> They specifically observed that (1) and (2) have the same behavior, and 
>> suggested that maybe (2) should be shorthand for (3).
>> 
>> Pros:
>> - There aren't two ways to spell (1).
>> - Removing the mangling (and module uniquing) from the runtime name is 
>> probably one of the most common uses of @objc on a class.
>> 
>> Cons:
>> - It's a source-breaking change, for all that the "@objc" in (2) is 
>> redundant.
>> - For protocols, (1) and (2) are not equivalent, because @objc isn't 
>> inherited there.
>> - Mangling is used to namespace class names at run time; if you drop that, 
>> the ObjC name should probably have a prefix. (This applies more to 
>> frameworks than apps, though.)
> 
> I’m -1 on this, because bare “@objc” in other contexts means “make sure this 
> is exposed to Objective-C, but I don’t want to be explicit about the name” 
> while “@objc(something)” means “make sure this is exposed to Objective-C, and 
> ‘something’ is the name”. 
> 

-1 
Please'o'please ... I find it useful for complexifying simple swift names into 
the kind that typically exists on the objc side.


>   - Doug
> 
> 
> ___
> 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] Remove type inference for associated types

[Paulo Faria via swift-evolution]

> On Jun 28, 2016, at 3:34 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>>> Finally, I am very concerned that there are protocols such as Collection,
>>> with many inferrable associated types, and that conforming to these
>>> protocols could become *much* uglier.

Unfortunately I have a specific use case in which this argument would be very 
strong.

Basically this:

extension TodoController : ResourceController {}

Would have to become this:

extension TodoController : ResourceController {
public typealias CreateInput = Todo
public typealias UpdateInput = Todo

public typealias ListOutput = Todo
public typealias CreateOutput = Todo
public typealias DetailOutput = Todo
public typealias UpdateOutput = Todo

public typealias DetailID = String
public typealias UpdateID = String
public typealias DestroyID = String
}

I could reduce the amount of associated types but this would reduce the 
flexibility of the protocol by a huge factor and would make it much less 
powerful. I’m very torn about this because I do want generics to get better. 
Specifically I’m looking forward to conditional conformances. But this would be 
a too high cost imho. I know this is just one example. But maybe there are more 
examples like this out there. I have to admit this one really got to me. :(___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Setter methods for vars

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 29, 2016, at 1:11 AM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Really?? Or we just have #set and #get and no lenses, and it's done for Swift 
> 3?
> 
> I never heard of lenses (Google does not help here). Was this serious or were 
> you joking?

http://days2012.scala-lang.org/sites/days2012/files/morris_lenses.pdf

Not a joke at all. Read first sentence for brief definition.

> Unless you can explain why #set and #get without lenses would be bad... or 
> maybe #set and #get *are* lenses, in which case I'm not sure what you were 
> trying to say. Reflexion -> Reflection?
> 
> -Michael
> 
>> Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution 
>> :
>> 
>> This looks like lenses. I think we need to wait until after Swift 3 to 
>> discuss it, and come up with a bigger design that ties to reflexion.
>> 
>>> On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution 
>>>  wrote:
>>> 
>>> So you're proposing that `#set(aVariableName)` should translate to 
>>> `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue 
>>> like `self.users` or `users` or `vc.viewControllers`..
>>> 
>>> I think this would be a good extension to Swift. (`users.set` does not work 
>>> BTW, because maybe the `users` object has a `set` property.. maybe I wanted 
>>> to refer to the `set` property which also happens to refer to a closure 
>>> value.)
>>> 
>>> `#set(aVariableName)` also feels consistent with the 
>>> `#keyPath(aVariableName)` property and falls into a similar category. Maybe 
>>> `#setter(aVariableName)` would be even more clear? Furthermore, I want to 
>>> additionally propose to introduce `#get(aVariableName)` (or 
>>> `#getter(aVariableName)`) too.
>>> 
>>> -Michael
>>> 
 Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution 
 :
 
 Proposal:
 
 I propose adding setter methods to vars, which could look something like 
 this: `ApiClient().fetchUsers().then(#set(users))`
 
 Initially I thought it should work like this: 
 `ApiClient().fetchUsers().then(users.set)`
 but to accomplish a line of code that flows grammatically, I believe 
 putting "set" where it would naturally fall if the code was being read as 
 a sentence is more Swifty.
 
 Rationale:
 
 The following code makes me smile:
 
 ApiClient().fetchUsers().then(displayUsers)
 
 It exemplifies the beauty of Swift. First-class functions make this line 
 of code read very well. Consider some alternatives:
 
 1. ApiClient().fetchUsers().then { displayUsers($0) }
 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }
 
 Using the lessons learned from Swift API Design Guidelines (WWDC 2016 
 Session 403) having an emphasis on clarity, my analysis of the 
 alternatives is:
 
 1. $0 adds no additional information as to the type or explanation of what 
 the argument is, thus adding nothing to the line of code for clarity, and 
 therefore should be omitted
 2. adding "users" also adds nothing to the clarity of the code. The 
 function, properly, contains the information necessary to reason about the 
 argument it takes and what it does, and therefore adding "users" is 
 redundant
 3. Not only is "users" redundant, but also is the explicit type label. The 
 `displayUsers` method will only accept one type of argument, so we're 
 duplicating information that the compiler (and autocomplete) already gives 
 us
 
 With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is 
 the Swiftiest option.
 I want to extend this same logic to when I find myself writing code like 
 this:
 
 ApiClient().fetchUsers().then { users in
 self.users = users
 }
 
 or alternatively, because "users" is likely redundant information again,
 
 ApiClient().fetchUsers().then { self.users = $0 }
 
 Personally I steer clear of `$0` as much as possible, because I very 
 rarely feel that it provides the information necessary for code clarity. 
 But beyond that, this code no longer reads as nicely as the code we had 
 before. 
 
 Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a 
 sentence and reads grammatically, `ApiClient().fetchUsers().then { 
 self.users = $0 }` no longer does.
 
 I think this feature could have a simple implementation where the compiler 
 replaces `#set(X)` with `{ X = $0 }`, and I believe it would go a long way 
 with respect to code clarity, especially when X is something longer like 
 `self.view.bounds.origin.x`
 
 
 Looking forward to hearing thoughts from the community,
 Austin 

[swift-evolution] [Review] SE-0107: UnsafeRawPointer API

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of “SE-0107: UnsafeRawPointer API” begins now and runs through July 
4, 2016. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and 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,

-Chris Lattner
Review Manager


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

[swift-evolution] [Accepted] SE-0106: Add a macOS Alias for the OSX Platform Configuration Test

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0106-rename-osx-to-macos.md

The core team is proactively accepting SE-0106 "Add a macOS Alias for the OSX 
Platform Configuration Test” without a formal review, under the rationale that 
the proposal is “obvious” and probably should have been treated as a bug fix.  
Adding aliases for other uses of “OS X” in the language to use macOS are also 
proactively accepted.

Thank you Erica Sadun for raising this issue!

-Chris Lattner
Review Manager

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

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Chris Lattner via swift-evolution]

> On Jun 27, 2016, at 4:42 PM, Saagar Jha via swift-evolution 
>  wrote:
> 
> Alright, I’ve written it up a proposal; you can find it here 
> . This is 
> my first proposal (and anyways I’ve been told that I can be unclear), so if 
> you guys see anything that should be changed feel free to let me know. Here 
> it is inline:
> 
Hi Saagar,

If I understand your proposal correctly, you are suggesting that we remove T! 
and just force people to use T? or T.  This is a commonly rejected proposal 
(though not on the list yet) that frequently comes up.  The problem with your 
proposal is that you don’t provide any solutions to the problems that T! is 
currently solving: that of two-phase initialization and importing of APIs that 
have not been nullability audited.  It isn’t pragmatic to handle these cases as 
T?

-Chris

> Remove implicitly unwrapped optionals as function parameters
> 
> Proposal: SE- 
> 
> Author: Swift Developer 
> Status: Awaiting review
> Review manager: TBD
> Introduction
> 
> Swift, in contrast with Objective-C, makes a distinction between values that 
> may be nil and values that can never be nil through its use of Optionals. Due 
> to the fact that Objective-C does not make this distinction, Objective-C 
> functions that do not use the Nullability 
>  annotations are imported with 
> parameters of the implicitly unwrapped optional type. Unfortunately, this 
> allows users to write their own Swift code that looks like this:
> 
> func foo(bar: Int!) {
> //…
> }
> Due to the confusion this may cause, we would like to propose the removal of 
> implicitly unwrapped optionals as function parameters. Discussion on this 
> topic may be found here 
> .
> 
> Motivation
> 
> Implicitly unwrapped optionals are currently allowed in function 
> declarations. Consider the following function:
> 
> func triple(forceUnwrapping aNumber: Int) -> Int {
> return aNumber * 3
> }
> 
> let possiblyNil = Int("foo")
> triple(forceUnwrapping: possiblyNil)
> possiblyNil is an Int?; thus, this example will not compile due to 
> triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift 
> beginner writing code that looks like this to "fix" the problem:
> 
> func triple(forceUnwrapping aNumber: Int!) -> Int {
> return aNumber * 3
> }
> 
> let possiblyNil = Int("foo")
> triple(forceUnwrapping: possiblyNil)
> While this version compiles, it crashes due to the force unwrapping of a nil 
> value. Unfortunately, the compiler "hides" this fact by making it seem like 
> it's acceptable to pass in nil–it doesn't make the forced unwrapping explicit.
> 
> Proposed solution
> 
> The safest solution, in this case, is to prevent the use of implicitly 
> unrwapped optionals in function signatures. By forcing users to write
> 
> func triple(forceUnwrapping aNumber: Int) -> Int {
> return aNumber * 3
> }
> or
> 
> func triple(forceUnwrapping aNumber: Int?) -> Int {
> return aNumber * 3
> }
> the compiler will complain, reminding users that they should probably attempt 
> to safely unwrap the optional before using it.
> 
> Detailed design
> 
> The proposal will prevent the use of implicitly unwrapped optionals in 
> function signatures for both Swift code as well as imported Objective-C code. 
> As non-annotated Objective-C functions are currently imported as implicitly 
> unwrapped, they will be converted to optionals as a preliminary step. 
> Non-audited frameworks can be audited in the future so that they can be 
> tagged with _Nonnull if necessary.
> 
> Impact on existing code
> 
> This is a proposal is a source breaking change, but it should be easily 
> mitigated using a migrator. Existing functions with implicitly unwrapped 
> optionals can be changed to optional; users can easily shadow variables with 
> a guard or change their function to non-optional.
> 
> Alternatives considered
> 
> Importing Objective-C functions as-is, but disallowing implictly unwrapped 
> optionals in Swift code
> 
> This reduces the burden on existing frameworks and adding Nullability 
> annotations, but creates a sort of disconnect between Objective-C and Swift 
> in that it prevents Swift developers from writing functions with implicitly 
> unwrapped optionals.
> 
> Doing nothing
> 
> Obviously, this has the benefit of keeping the current behavior and not 
> requiring a migrator. However, I believe that the unsafe behavior that this 
> encourages is not worth keeping.
> 
> 
> 
> On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko  > wrote:
> +1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a 
> carryover from Java. They show up in method signatures from 
> non-nullable-annotated Java, but you can't 

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Sean Heber via swift-evolution]

Now that's just silly!

l8r
Sean

Sent from my iPad

> On Jun 28, 2016, at 10:49 PM, Greg Titus  wrote:
> 
> I’m honestly shocked that y’all (that I’ve seen) haven’t come up with 
> Syntax.LiterallyIntegerLiteral yet.
> 
> 
> 
>> On Jun 28, 2016, at 8:39 PM, Sean Heber via swift-evolution 
>>  wrote:
>> 
>> Arg. Dang it!
>> 
>> Syntax.ExpressibleAsIntegerLiteral
>> Syntax.FromIntegerLiteral
>> Syntax.IntegerLiteralManifestation
>> Syntax.GhostOfIntegerLiteral
>> Syntax.FormerlyKnownAsIntegerLiteral
>> 
>> l8r
>> Sean 
>> 
>> Sent from my iPad
>> 
>> On Jun 28, 2016, at 10:29 PM, Erica Sadun  wrote:
>> 
 On Jun 28, 2016, at 9:21 PM, Sean Heber  wrote:
 
 IntegerLiteralExpressable?
 
 Does Apple employ any philosophers? We might need one...
 
 l8r
 Sean
 
>>> 
>>> Aand...welcome to last night.
>>> 
>>> The problem being, that people see this and think that the type can be
>>> expressed as an integer literal, not that an integer literal can be 
>>> expressing
>>> the type. (I won't even bring up other associations for that word since
>>> most of the subscribers of this mailing list have not been nursing mothers
>>> although some may be familiar with the technique.)
>>> 
>>> -- E
>>> 
>>> 
 
> On Jun 28, 2016, at 10:02 PM, Erica Sadun  wrote:
> 
> 
>> On Jun 28, 2016, at 8:08 PM, Sean Heber  wrote:
>> 
>> What about..
>> 
>> Syntax.ConvertibleFromIntegerLiteral
>> etc..
> 
> I like it but Dave has already expressed that this isn't conversion. This
> is something distinct, magical, and more importantly, ineffable.
> 
> He says it means an instance of the type can be written as a literal, and
> not converted from a literal. He writes:
> 
>> Conformance to this protocol does *not* mean you can initialize the type 
>> with
>> a literal. 
>> 
>> Proof:
>> 
>> func f() -> T {
>> return T(integerLiteral: 43) // Error
>> return T(43) // Also an Error
>> }
>> 
>> It means an instance of the type can be *written* as a literal:
>> 
>> func f() -> T {
>> return 43   // OK
>> }
>>> 
> 
> So we're looking at something more like:
> 
> Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf
> 
> -- E
> 
> 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

[Matthew Judge via swift-evolution]

> On Jun 28, 2016, at 22:16, Matthew Johnson  wrote:
> 
> 
>>> On Jun 28, 2016, at 9:06 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Jun 28, 2016, at 19:03, Matthew Judge  wrote:
>>> 
>>> Comments inline.
>>> 
 On Jun 28, 2016, at 04:14, David Hart via swift-evolution 
  wrote:
 
 Hello everybody,
 
 I tried using the access rules defined in SE-0025 in some code of mine to 
 see what effect it would have. I came out of the experiment more 
 disappointed than I thought. Here are several reasons:
 
 1) The new rules make `private` more prominent compared to `fileprivate` 
 (the latter has a somewhat worse name). But at the same time, the Swift 
 community has developed a style of coding where a type is defined through 
 a set of extensions. To hide members from other types, but have access to 
 them inside the type extensions, we have often used `private` and placed 
 the type and its extensions in the same file. Because `private` is scoped, 
 we are forced into using `fileprivate` pervasively (which is uglier), 
 using `internal` instead (which is less safe) or moving the extension code 
 into the type's scope (which is against the way Swift code is being 
 written today). All of these options look worse to be than before SE-0025.
>>> 
>>> If I understand SE-0025 (even with the amendment) you can still spell the 
>>> access modifier to types as 'private' and get the same characteristics as 
>>> the pre-SE-0025 meaning or private, so I'm not sure I understand the 
>>> concern here. However (continued below)
 
 2) The new amended rules look complicated to me. I think they have the 
 risk of being confusing in practice, but we’ll have to see.
 
>>> 
>>> I definitely agree that the amended rules look complicated. It seems to me 
>>> that the amended set of rules is favoring simplifying the implementation 
>>> over simplifying the mental model.
>>> 
>>> My impression of what SE-0025 decided was that 'private' meant private to 
>>> the enclosing scope. If the access modifying 'private' was applied to a 
>>> type at the file scope, then it was synonymous with fileprivate and the 
>>> default access of members of that type should be fileprivate.
>>> 
>>> If a inner type was declared private, than the default access of members of 
>>> that inner type should be private to the Outer type, not fileprivate. There 
>>> is currently no way of expressing this access explicitly, but it does not 
>>> seem like an especially useful thing to need to spell.
>>> 
>>> Said in code, my impression of SE-0025 is that 
>>> 
>>> private class Outer { // exactly equivalent to fileprivate
>>> var myVar = 0 // default: fileprivate
>>> private class Inner { // private to Outer
>>> var hiddenVar = 0 // default: private to Outer
>>> private var reallyHiddenVar = 0 // default private to Inner
>>> }
>>> }
>> 
>> This is definitely one of the considered alternatives. Both Brent and I 
>> didn’t like the idea of an access level that you couldn’t actually spell, 
>> and even if we got past that, we’d still need a way to refer to it in 
>> documentation and diagnostics. I would count that as a larger change than 
>> just allowing ‘fileprivate’ in places that previously would have been called 
>> redundant.
> 
> This was really the fact that didn’t receive adequate attention during 
> discussion and review - that the semantics everyone understood it to have 
> implied visibility for members that you cannot state explicitly.  It didn’t 
> bother me initially, but the diagnostics point Jordan makes is pretty 
> important (I think we could handle it ok in documentation).  Good diagnostics 
> are extremely important and they must be both clear and concise.  In order to 
> have good diagnostics we need a name for the visibility that everyone knows 
> so it may as well be part of the language.
> 

I don't want to reopen the bike shedding, but this issue was one of the main 
reasons I was in favor of the 'private(file)' spelling. 'private(Outer)', 
'private(Inner)', etc. fall out as fairly obvious spellings for these cases in 
my mind.  (The only big negative I see to those spellings is the potential for 
confusion for anyone too used to type-based access modifiers: that something 
marked 'private(Outer)' would not be visible in 'extension Outer {}')

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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Chris Lattner via swift-evolution]

> On Jun 28, 2016, at 11:25 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> 
>> Finally, I am very concerned that there are protocols such as Collection,
>> with many inferrable associated types, and that conforming to these
>> protocols could become *much* uglier.
> 
> That’s the general concern I have as well: how much boilerplate does this 
> add? In many cases, we get some of the associated type witnesses for 
> Collection types for free, and I don’t know to what extent we can emulate 
> that with defaulted associated type requirements and typealiases in protocol 
> extensions.
> 
> That said, I’ll take some minor regressions in this area for the massive 
> simplification that this proposal brings.

Another point to add to Doug’s great summary: instead of keeping it, it is 
better in many ways to remove this feature in Swift 3, improve the generics 
model throughout Swift 4 cycle, and then consider adding inference back when we 
know more.  

The benefits of adding it back will be even more clear in the future, and the 
implementation cost will also be more knowable as the rest of the generics 
system is baked out.

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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Greg Titus via swift-evolution]

I’m honestly shocked that y’all (that I’ve seen) haven’t come up with 
Syntax.LiterallyIntegerLiteral yet.



> On Jun 28, 2016, at 8:39 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> Arg. Dang it!
> 
> Syntax.ExpressibleAsIntegerLiteral
> Syntax.FromIntegerLiteral
> Syntax.IntegerLiteralManifestation
> Syntax.GhostOfIntegerLiteral
> Syntax.FormerlyKnownAsIntegerLiteral
> 
> l8r
> Sean 
> 
> Sent from my iPad
> 
> On Jun 28, 2016, at 10:29 PM, Erica Sadun  wrote:
> 
>>> On Jun 28, 2016, at 9:21 PM, Sean Heber  wrote:
>>> 
>>> IntegerLiteralExpressable?
>>> 
>>> Does Apple employ any philosophers? We might need one...
>>> 
>>> l8r
>>> Sean
>>> 
>> 
>> Aand...welcome to last night.
>> 
>> The problem being, that people see this and think that the type can be
>> expressed as an integer literal, not that an integer literal can be 
>> expressing
>> the type. (I won't even bring up other associations for that word since
>> most of the subscribers of this mailing list have not been nursing mothers
>> although some may be familiar with the technique.)
>> 
>> -- E
>> 
>> 
>>> 
 On Jun 28, 2016, at 10:02 PM, Erica Sadun  wrote:
 
 
> On Jun 28, 2016, at 8:08 PM, Sean Heber  wrote:
> 
> What about..
> 
> Syntax.ConvertibleFromIntegerLiteral
> etc..
 
 I like it but Dave has already expressed that this isn't conversion. This
 is something distinct, magical, and more importantly, ineffable.
 
 He says it means an instance of the type can be written as a literal, and
 not converted from a literal. He writes:
 
> Conformance to this protocol does *not* mean you can initialize the type 
> with
> a literal. 
> 
> Proof:
> 
> func f() -> T {
> return T(integerLiteral: 43) // Error
> return T(43) // Also an Error
> }
> 
> It means an instance of the type can be *written* as a literal:
> 
> func f() -> T {
> return 43   // OK
> }
>> 
 
 So we're looking at something more like:
 
 Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf
 
 -- E
 
 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Partial list of open Swift 3 design topics

[Chris Lattner via swift-evolution]

> On Jun 28, 2016, at 11:00 AM, Douglas Gregor  wrote:
> 
> 
>> On Jun 28, 2016, at 9:49 AM, Austin Zheng  wrote:
>> 
>> This makes sense. If nobody objects I'll prepare a proposal today. 
>> 
>> By the way, on the topic of design topics: is there any core team support 
>> for removing associated type inference? I have a proposal there that I would 
>> like to move into the formal review stage at some point. 
> 
> Well, *I* want to remove associated type inference because I feel that we 
> shouldn’t have global inference like this in Swift. I am, however, concerned 
> about the standard library’s ability to make conformances to the Collection 
> protocols provide meaningful defaults for, e.g., the SubSequence associated 
> type.

I am also +1 on the concept, but haven’t had a chance to fully consider the 
ramifications.

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

Re: [swift-evolution] Partial list of open Swift 3 design topics

[Chris Lattner via swift-evolution]

> On Jun 28, 2016, at 7:36 AM, Wallacy  wrote:
> 
> And something about Property Behaviors? It's a very good proposal, and can 
> solve many problems cited in other proposals in this list.

I’m also looking forward to property behaviors, but there is a ton of open 
design work left to be done.  They are clearly post-swift-3.0 at this point.

-Chris

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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Sean Heber via swift-evolution]

Arg. Dang it!

Syntax.ExpressibleAsIntegerLiteral
Syntax.FromIntegerLiteral
Syntax.IntegerLiteralManifestation
Syntax.GhostOfIntegerLiteral
Syntax.FormerlyKnownAsIntegerLiteral

l8r
Sean 

Sent from my iPad

On Jun 28, 2016, at 10:29 PM, Erica Sadun  wrote:

>> On Jun 28, 2016, at 9:21 PM, Sean Heber  wrote:
>> 
>> IntegerLiteralExpressable?
>> 
>> Does Apple employ any philosophers? We might need one...
>> 
>> l8r
>> Sean
>> 
> 
> Aand...welcome to last night.
> 
> The problem being, that people see this and think that the type can be
> expressed as an integer literal, not that an integer literal can be expressing
> the type. (I won't even bring up other associations for that word since
> most of the subscribers of this mailing list have not been nursing mothers
> although some may be familiar with the technique.)
> 
> -- E
> 
> 
>> 
>>> On Jun 28, 2016, at 10:02 PM, Erica Sadun  wrote:
>>> 
>>> 
 On Jun 28, 2016, at 8:08 PM, Sean Heber  wrote:
 
 What about..
 
 Syntax.ConvertibleFromIntegerLiteral
 etc..
>>> 
>>> I like it but Dave has already expressed that this isn't conversion. This
>>> is something distinct, magical, and more importantly, ineffable.
>>> 
>>> He says it means an instance of the type can be written as a literal, and
>>> not converted from a literal. He writes:
>>> 
 Conformance to this protocol does *not* mean you can initialize the type 
 with
 a literal. 
 
 Proof:
 
 func f() -> T {
 return T(integerLiteral: 43) // Error
 return T(43) // Also an Error
 }
 
 It means an instance of the type can be *written* as a literal:
 
 func f() -> T {
 return 43   // OK
 }
> 
>>> 
>>> So we're looking at something more like:
>>> 
>>> Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf
>>> 
>>> -- E
>>> 
>>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Erica Sadun via swift-evolution]

> On Jun 28, 2016, at 9:21 PM, Sean Heber  wrote:
> 
> IntegerLiteralExpressable?
> 
> Does Apple employ any philosophers? We might need one...
> 
> l8r
> Sean
> 

Aand...welcome to last night.

The problem being, that people see this and think that the type can be
expressed as an integer literal, not that an integer literal can be expressing
the type. (I won't even bring up other associations for that word since
most of the subscribers of this mailing list have not been nursing mothers
although some may be familiar with the technique.)

-- E


> 
>> On Jun 28, 2016, at 10:02 PM, Erica Sadun  wrote:
>> 
>> 
>>> On Jun 28, 2016, at 8:08 PM, Sean Heber  wrote:
>>> 
>>> What about..
>>> 
>>> Syntax.ConvertibleFromIntegerLiteral
>>> etc..
>> 
>> I like it but Dave has already expressed that this isn't conversion. This
>> is something distinct, magical, and more importantly, ineffable.
>> 
>> He says it means an instance of the type can be written as a literal, and
>> not converted from a literal. He writes:
>> 
>>> Conformance to this protocol does *not* mean you can initialize the type 
>>> with
>>> a literal. 
>>> 
>>> Proof:
>>> 
>>> func f() -> T {
>>>  return T(integerLiteral: 43) // Error
>>>  return T(43) // Also an Error
>>> }
>>> 
>>> It means an instance of the type can be *written* as a literal:
>>> 
>>> func f() -> T {
>>>  return 43   // OK
>>> }
 
>> 
>> So we're looking at something more like:
>> 
>> Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf
>> 
>> -- E
>> 
>> 

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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Sean Heber via swift-evolution]

IntegerLiteralExpressable?

Does Apple employ any philosophers? We might need one...

l8r
Sean

Sent from my iPad

> On Jun 28, 2016, at 10:02 PM, Erica Sadun  wrote:
> 
> 
>> On Jun 28, 2016, at 8:08 PM, Sean Heber  wrote:
>> 
>> What about..
>> 
>> Syntax.ConvertibleFromIntegerLiteral
>> etc..
> 
> I like it but Dave has already expressed that this isn't conversion. This
> is something distinct, magical, and more importantly, ineffable.
> 
> He says it means an instance of the type can be written as a literal, and
> not converted from a literal. He writes:
> 
>> Conformance to this protocol does *not* mean you can initialize the type with
>> a literal. 
>> 
>> Proof:
>> 
>> func f() -> T {
>>   return T(integerLiteral: 43) // Error
>>   return T(43) // Also an Error
>> }
>> 
>> It means an instance of the type can be *written* as a literal:
>> 
>> func f() -> T {
>>   return 43   // OK
>> }
>>> 
> 
> So we're looking at something more like:
> 
> Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf
> 
> -- E
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Erica Sadun via swift-evolution]

> On Jun 28, 2016, at 8:08 PM, Sean Heber  wrote:
> 
> What about..
> 
> Syntax.ConvertibleFromIntegerLiteral
> etc..

I like it but Dave has already expressed that this isn't conversion. This
is something distinct, magical, and more importantly, ineffable.

He says it means an instance of the type can be written as a literal, and
not converted from a literal. He writes:

> Conformance to this protocol does *not* mean you can initialize the type with
> a literal. 
> 
> Proof:
> 
>  func f() -> T {
>return T(integerLiteral: 43) // Error
>return T(43) // Also an Error
>  }
> 
> It means an instance of the type can be *written* as a literal:
> 
>  func f() -> T {
>return 43   // OK
>  }
>> 

So we're looking at something more like:

Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf

-- E


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

Re: [swift-evolution] Request for quickie proposal and review

[Erica Sadun via swift-evolution]

Please look through:

https://gist.github.com/erica/af357a47ec5c1d26028769e1676af799

Let me know what corrections you want. Once you do so, I'll put it in as a pull 
request. Who do you want as the author
or should I put in "Administrative", "Core Team", or something similar?

-- E

> On Jun 28, 2016, at 8:04 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> Hi,
> 
> It occurred to us a couple weeks ago that the name `Value` was
> a terrible name for the first parameter to `ManagedBuffer` et al, so I
> prepared this patch that renames it to `Header`.  
> 
> https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121
> 
> I would be immensely grateful if someone would like to volunteer to
> write up a quick proposal for this change and pushing it the process.
> 
> TIA,
> 
> -- 
> 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] Request for quickie proposal and review

[Erica Sadun via swift-evolution]

Dave:

I think this should be changed:

return withUnsafeMutablePointers { (v, e) in return body(v) }

should be

return withUnsafeMutablePointers { (h, e) in return body(h) }

-- E

> On Jun 28, 2016, at 8:04 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> Hi,
> 
> It occurred to us a couple weeks ago that the name `Value` was
> a terrible name for the first parameter to `ManagedBuffer` et al, so I
> prepared this patch that renames it to `Header`.  
> 
> https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121
> 
> I would be immensely grateful if someone would like to volunteer to
> write up a quick proposal for this change and pushing it the process.
> 
> TIA,
> 
> -- 
> 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] [Discussion] A Problem With SE-0025?

[Matthew Johnson via swift-evolution]

> On Jun 28, 2016, at 9:06 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
>> 
>> On Jun 28, 2016, at 19:03, Matthew Judge > > wrote:
>> 
>> Comments inline.
>> 
>> On Jun 28, 2016, at 04:14, David Hart via swift-evolution 
>> > wrote:
>> 
>>> Hello everybody,
>>> 
>>> I tried using the access rules defined in SE-0025 in some code of mine to 
>>> see what effect it would have. I came out of the experiment more 
>>> disappointed than I thought. Here are several reasons:
>>> 
>>> 1) The new rules make `private` more prominent compared to `fileprivate` 
>>> (the latter has a somewhat worse name). But at the same time, the Swift 
>>> community has developed a style of coding where a type is defined through a 
>>> set of extensions. To hide members from other types, but have access to 
>>> them inside the type extensions, we have often used `private` and placed 
>>> the type and its extensions in the same file. Because `private` is scoped, 
>>> we are forced into using `fileprivate` pervasively (which is uglier), using 
>>> `internal` instead (which is less safe) or moving the extension code into 
>>> the type's scope (which is against the way Swift code is being written 
>>> today). All of these options look worse to be than before SE-0025.
>> 
>> If I understand SE-0025 (even with the amendment) you can still spell the 
>> access modifier to types as 'private' and get the same characteristics as 
>> the pre-SE-0025 meaning or private, so I'm not sure I understand the concern 
>> here. However (continued below)
>>> 
>>> 2) The new amended rules look complicated to me. I think they have the risk 
>>> of being confusing in practice, but we’ll have to see.
>>> 
>> 
>> I definitely agree that the amended rules look complicated. It seems to me 
>> that the amended set of rules is favoring simplifying the implementation 
>> over simplifying the mental model.
>> 
>> My impression of what SE-0025 decided was that 'private' meant private to 
>> the enclosing scope. If the access modifying 'private' was applied to a type 
>> at the file scope, then it was synonymous with fileprivate and the default 
>> access of members of that type should be fileprivate.
>> 
>> If a inner type was declared private, than the default access of members of 
>> that inner type should be private to the Outer type, not fileprivate. There 
>> is currently no way of expressing this access explicitly, but it does not 
>> seem like an especially useful thing to need to spell.
>> 
>> Said in code, my impression of SE-0025 is that 
>> 
>> private class Outer { // exactly equivalent to fileprivate
>> var myVar = 0 // default: fileprivate
>> private class Inner { // private to Outer
>> var hiddenVar = 0 // default: private to Outer
>> private var reallyHiddenVar = 0 // default private to Inner
>> }
>> }
> 
> This is definitely one of the considered alternatives. Both Brent and I 
> didn’t like the idea of an access level that you couldn’t actually spell, and 
> even if we got past that, we’d still need a way to refer to it in 
> documentation and diagnostics. I would count that as a larger change than 
> just allowing ‘fileprivate’ in places that previously would have been called 
> redundant.

This was really the fact that didn’t receive adequate attention during 
discussion and review - that the semantics everyone understood it to have 
implied visibility for members that you cannot state explicitly.  It didn’t 
bother me initially, but the diagnostics point Jordan makes is pretty important 
(I think we could handle it ok in documentation).  Good diagnostics are 
extremely important and they must be both clear and concise.  In order to have 
good diagnostics we need a name for the visibility that everyone knows so it 
may as well be part of the language.

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

Re: [swift-evolution] Request for quickie proposal and review

[Erica Sadun via swift-evolution]

You got it.

Give me a few minutes

-- E



> On Jun 28, 2016, at 8:04 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> Hi,
> 
> It occurred to us a couple weeks ago that the name `Value` was
> a terrible name for the first parameter to `ManagedBuffer` et al, so I
> prepared this patch that renames it to `Header`.  
> 
> https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121
> 
> I would be immensely grateful if someone would like to volunteer to
> write up a quick proposal for this change and pushing it the process.
> 
> TIA,
> 
> -- 
> 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

[swift-evolution] Request for quickie proposal and review

[Dave Abrahams via swift-evolution]

Hi,

It occurred to us a couple weeks ago that the name `Value` was
a terrible name for the first parameter to `ManagedBuffer` et al, so I
prepared this patch that renames it to `Header`.  

https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121

I would be immensely grateful if someone would like to volunteer to
write up a quick proposal for this change and pushing it the process.

TIA,

-- 
Dave

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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Matthew Johnson via swift-evolution]

> On Jun 28, 2016, at 9:05 PM, Erica Sadun  wrote:
> 
>> 
>> On Jun 28, 2016, at 7:52 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Jun 28, 2016, at 6:13 PM, Dave Abrahams > wrote:
> Or we're clueless AND it's a bad name.
 
 It's possible, but until we have an objective rationale for why it's bad
 (arguments that it seems to imply what turns out to be the actual
 meaning of the protocol don't count!), *and* a better alternative, it's
 sort of moot.  If you don't like `Syntax.IntegerLiteral` or
 `Syntax.IntegerLiteralExpressible` then I'm out of suggestions.
 
> func f() -> T {
>return 42 // the answer to everything
> }
 
 Promotion means something very different; something that we actually
 expect to incorporate into the language one day.
>>> 
>>> Syntax.MarvinTheDepressedIntegerLiteral
>> You really have me laughing with some of these!  Thanks Erica. :)
> 
> A few more, with a slightly different approach that pushes the literal part 
> towards the end of the name:
> Syntax.SupportsIntegerLiterals
> Syntax.AcceptsIntegerLiterals
> Syntax.IncludesIntegerLiterals
> Syntax.IncorporatesIntegerLiterals

If you want to pick out your favorites I’ll be happy to update the proposal to 
include them in the alternatives section.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Sean Heber via swift-evolution]

What about..

Syntax.ConvertibleFromIntegerLiteral
etc..

l8r
Sean

Sent from my iPad

> On Jun 28, 2016, at 8:52 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jun 28, 2016, at 6:13 PM, Dave Abrahams  wrote:
 Or we're clueless AND it's a bad name.
>>> 
>>> It's possible, but until we have an objective rationale for why it's bad
>>> (arguments that it seems to imply what turns out to be the actual
>>> meaning of the protocol don't count!), *and* a better alternative, it's
>>> sort of moot.  If you don't like `Syntax.IntegerLiteral` or
>>> `Syntax.IntegerLiteralExpressible` then I'm out of suggestions.
>>> 
 func f() -> T {
return 42 // the answer to everything
 }
>>> 
>>> Promotion means something very different; something that we actually
>>> expect to incorporate into the language one day.
>> 
>> Next pitch:
>> Syntax.IntegerLiteralInsertion
>> Less successful attempts to brainstorm:
>> Syntax.IntegerLiteralAdvancement
>> Syntax.IntegerLiteralUpgrade
>> Syntax.FreelyIntegerReplaceable
>> Syntax.IntegerParkour
>> Syntax.TodayTheRoleOfTWillBePlayedByIntegerLiteral
>> Syntax.IntegerLiteralTypePoseur
>> Syntax.IntegerLiteral.Zigazigahh
>> Syntax.IntegerLiteralBoosterPack
>> Syntax.IntegerLevelUp
>> Syntax.IntegerElevator
>> Syntax.MarvinTheDepressedIntegerLiteral
> You really have me laughing with some of these!  Thanks Erica. :)
> 
> 
>> -- E
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

[Jordan Rose via swift-evolution]

> On Jun 28, 2016, at 19:03, Matthew Judge  wrote:
> 
> Comments inline.
> 
> On Jun 28, 2016, at 04:14, David Hart via swift-evolution 
> > wrote:
> 
>> Hello everybody,
>> 
>> I tried using the access rules defined in SE-0025 in some code of mine to 
>> see what effect it would have. I came out of the experiment more 
>> disappointed than I thought. Here are several reasons:
>> 
>> 1) The new rules make `private` more prominent compared to `fileprivate` 
>> (the latter has a somewhat worse name). But at the same time, the Swift 
>> community has developed a style of coding where a type is defined through a 
>> set of extensions. To hide members from other types, but have access to them 
>> inside the type extensions, we have often used `private` and placed the type 
>> and its extensions in the same file. Because `private` is scoped, we are 
>> forced into using `fileprivate` pervasively (which is uglier), using 
>> `internal` instead (which is less safe) or moving the extension code into 
>> the type's scope (which is against the way Swift code is being written 
>> today). All of these options look worse to be than before SE-0025.
> 
> If I understand SE-0025 (even with the amendment) you can still spell the 
> access modifier to types as 'private' and get the same characteristics as the 
> pre-SE-0025 meaning or private, so I'm not sure I understand the concern 
> here. However (continued below)
>> 
>> 2) The new amended rules look complicated to me. I think they have the risk 
>> of being confusing in practice, but we’ll have to see.
>> 
> 
> I definitely agree that the amended rules look complicated. It seems to me 
> that the amended set of rules is favoring simplifying the implementation over 
> simplifying the mental model.
> 
> My impression of what SE-0025 decided was that 'private' meant private to the 
> enclosing scope. If the access modifying 'private' was applied to a type at 
> the file scope, then it was synonymous with fileprivate and the default 
> access of members of that type should be fileprivate.
> 
> If a inner type was declared private, than the default access of members of 
> that inner type should be private to the Outer type, not fileprivate. There 
> is currently no way of expressing this access explicitly, but it does not 
> seem like an especially useful thing to need to spell.
> 
> Said in code, my impression of SE-0025 is that 
> 
> private class Outer { // exactly equivalent to fileprivate
> var myVar = 0 // default: fileprivate
> private class Inner { // private to Outer
> var hiddenVar = 0 // default: private to Outer
> private var reallyHiddenVar = 0 // default private to Inner
> }
> }

This is definitely one of the considered alternatives. Both Brent and I didn’t 
like the idea of an access level that you couldn’t actually spell, and even if 
we got past that, we’d still need a way to refer to it in documentation and 
diagnostics. I would count that as a larger change than just allowing 
‘fileprivate’ in places that previously would have been called redundant.

Jordan

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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Erica Sadun via swift-evolution]

> On Jun 28, 2016, at 7:52 PM, Matthew Johnson  wrote:
> 
>> 
>> On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jun 28, 2016, at 6:13 PM, Dave Abrahams >> > wrote:
 Or we're clueless AND it's a bad name.
>>> 
>>> It's possible, but until we have an objective rationale for why it's bad
>>> (arguments that it seems to imply what turns out to be the actual
>>> meaning of the protocol don't count!), *and* a better alternative, it's
>>> sort of moot.  If you don't like `Syntax.IntegerLiteral` or
>>> `Syntax.IntegerLiteralExpressible` then I'm out of suggestions.
>>> 
 func f() -> T {
return 42 // the answer to everything
 }
>>> 
>>> Promotion means something very different; something that we actually
>>> expect to incorporate into the language one day.
>> 
>> Syntax.MarvinTheDepressedIntegerLiteral
> You really have me laughing with some of these!  Thanks Erica. :)

A few more, with a slightly different approach that pushes the literal part 
towards the end of the name:
Syntax.SupportsIntegerLiterals
Syntax.AcceptsIntegerLiterals
Syntax.IncludesIntegerLiterals
Syntax.IncorporatesIntegerLiterals

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

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

[Matthew Judge via swift-evolution]

Comments inline.

> On Jun 28, 2016, at 04:14, David Hart via swift-evolution 
>  wrote:
> 
> Hello everybody,
> 
> I tried using the access rules defined in SE-0025 in some code of mine to see 
> what effect it would have. I came out of the experiment more disappointed 
> than I thought. Here are several reasons:
> 
> 1) The new rules make `private` more prominent compared to `fileprivate` (the 
> latter has a somewhat worse name). But at the same time, the Swift community 
> has developed a style of coding where a type is defined through a set of 
> extensions. To hide members from other types, but have access to them inside 
> the type extensions, we have often used `private` and placed the type and its 
> extensions in the same file. Because `private` is scoped, we are forced into 
> using `fileprivate` pervasively (which is uglier), using `internal` instead 
> (which is less safe) or moving the extension code into the type's scope 
> (which is against the way Swift code is being written today). All of these 
> options look worse to be than before SE-0025.

If I understand SE-0025 (even with the amendment) you can still spell the 
access modifier to types as 'private' and get the same characteristics as the 
pre-SE-0025 meaning or private, so I'm not sure I understand the concern here. 
However (continued below)
> 
> 2) The new amended rules look complicated to me. I think they have the risk 
> of being confusing in practice, but we’ll have to see.
> 

I definitely agree that the amended rules look complicated. It seems to me that 
the amended set of rules is favoring simplifying the implementation over 
simplifying the mental model.

My impression of what SE-0025 decided was that 'private' meant private to the 
enclosing scope. If the access modifying 'private' was applied to a type at the 
file scope, then it was synonymous with fileprivate and the default access of 
members of that type should be fileprivate.

If a inner type was declared private, than the default access of members of 
that inner type should be private to the Outer type, not fileprivate. There is 
currently no way of expressing this access explicitly, but it does not seem 
like an especially useful thing to need to spell.

Said in code, my impression of SE-0025 is that 

private class Outer { // exactly equivalent to fileprivate
var myVar = 0 // default: fileprivate
private class Inner { // private to Outer
var hiddenVar = 0 // default: private to Outer
private var reallyHiddenVar = 0 // default private to Inner
}
}

> More generally, I think that the scoping rules of `fileprivate` may have an 
> in insidious effect that favour moving code back into the type’s scope 
> instead of preferring the cleaner style of putting it into extensions.
> 
> Potential solution:
> 
> What is `private` members were also visible to all extensions of the type in 
> the same module?

Disagree with this solution... It seems like a complete rework of the mental 
model for access modifiers. None of the existing access modifiers work on types.

> 
> David.
> 
>> On 28 Jun 2016, at 01:19, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> Robert and I wrote up the changes in the form of an amendment to SE-0025: 
>> https://github.com/apple/swift-evolution/pull/383. Please let me know if we 
>> missed anything!
>> 
>> I talked briefly to Chris and he said the core team will decide whether it 
>> needs a full review period, or whether it counts as the “obvious” semantics 
>> and can thus be accepted without a formal review.
>> 

My apologies for getting a bit long winded so far, hopefully I'm not just 
rehashing the previous arguments.

In regards to Alternative 2 for "the private type issue" and creating an access 
modifier named 'parent' or leaving that access level as without a way to 
express it: I believe it is acceptable not to add the term. I would expect the 
most likely situation for this needing to be spelled would be a type accessable 
to the module with a member only visible to the file. This can already be 
expressed by fileprivate. 

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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[David Sweeris via swift-evolution]

I vote for IntegerParkour :-)

Sent from my iPhone

> On Jun 28, 2016, at 20:35, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 28, 2016, at 6:13 PM, Dave Abrahams  wrote:
>>> Or we're clueless AND it's a bad name.
>> 
>> It's possible, but until we have an objective rationale for why it's bad
>> (arguments that it seems to imply what turns out to be the actual
>> meaning of the protocol don't count!), *and* a better alternative, it's
>> sort of moot.  If you don't like `Syntax.IntegerLiteral` or
>> `Syntax.IntegerLiteralExpressible` then I'm out of suggestions.
>> 
>>> func f() -> T {
>>>return 42 // the answer to everything
>>> }
>> 
>> Promotion means something very different; something that we actually
>> expect to incorporate into the language one day.
> 
> Next pitch:
> Syntax.IntegerLiteralInsertion
> Less successful attempts to brainstorm:
> Syntax.IntegerLiteralAdvancement
> Syntax.IntegerLiteralUpgrade
> Syntax.FreelyIntegerReplaceable
> Syntax.IntegerParkour
> Syntax.TodayTheRoleOfTWillBePlayedByIntegerLiteral
> Syntax.IntegerLiteralTypePoseur
> Syntax.IntegerLiteral.Zigazigahh
> Syntax.IntegerLiteralBoosterPack
> Syntax.IntegerLevelUp
> Syntax.IntegerElevator
> Syntax.MarvinTheDepressedIntegerLiteral
> -- E
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[Dmitri Gribenko via swift-evolution]

On Tue, Jun 28, 2016 at 2:17 PM, Andrew Trick  wrote:
>
>> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko  wrote:
>>
>> Hi Andy,
>>
>> Everything is clear now, thank you!
>>
>> On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick  wrote:
>>> Initializing via a typed pointer, in addition to changing the temporal 
>>> memory state, also imposes a type on the allocated memory for the entire 
>>> lifetime of the memory itself, from allocation to deallocation.
>>
>> I see.  Given that UnsafeMutablePoiner.initialize() has this very
>> important difference in semantics, did you consider reflecting it in
>> the name?  Something like '.bindTypeAndInitialize()' -- but I'm sure a
>> better wording is possible.
>
> Yes, I did consider that. I’m still open to it--maybe 
> ‘.typedInitialize(with:). But...
>
> (1) It’s awkward. The developer isn’t interested in binding the type at that 
> point. It’s just a side effect of the way their unsafe pointer is being used.
>
> (2) It would imply that the ‘.bindAndInitialize' entry point is the only way 
> to bind the type of allocated memory. But once you have a typed pointer, it’s 
> easy to initialize memory via a simple assignment:
> ptrToA[0] = A() // where A is trivial
> If ptrToA was in an uninitialized state, then that also binds the type.

It would be good to call this out in the proposal (I did not get this
part from the clarifications that you posted this morning.)  So the
rule is that every typed store binds the type?

> Instead, I tried to focus on discouraging the unsafe pointer cast that leads 
> to this situation. The important thing is that we have an alternate “safe” 
> API so that most developers just don’t need to think about it.

That's a good goal.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Matthew Johnson via swift-evolution]

> On Jun 28, 2016, at 8:35 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 28, 2016, at 6:13 PM, Dave Abrahams > > wrote:
>>> Or we're clueless AND it's a bad name.
>> 
>> It's possible, but until we have an objective rationale for why it's bad
>> (arguments that it seems to imply what turns out to be the actual
>> meaning of the protocol don't count!), *and* a better alternative, it's
>> sort of moot.  If you don't like `Syntax.IntegerLiteral` or
>> `Syntax.IntegerLiteralExpressible` then I'm out of suggestions.
>> 
>>> func f() -> T {
>>>return 42 // the answer to everything
>>> }
>> 
>> Promotion means something very different; something that we actually
>> expect to incorporate into the language one day.
> 
> Next pitch:
> Syntax.IntegerLiteralInsertion
> Less successful attempts to brainstorm:
> Syntax.IntegerLiteralAdvancement
> Syntax.IntegerLiteralUpgrade
> Syntax.FreelyIntegerReplaceable
> Syntax.IntegerParkour
> Syntax.TodayTheRoleOfTWillBePlayedByIntegerLiteral
> Syntax.IntegerLiteralTypePoseur
> Syntax.IntegerLiteral.Zigazigahh
> Syntax.IntegerLiteralBoosterPack
> Syntax.IntegerLevelUp
> Syntax.IntegerElevator
> Syntax.MarvinTheDepressedIntegerLiteral
You really have me laughing with some of these!  Thanks Erica. :)


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

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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Erica Sadun via swift-evolution]

> On Jun 28, 2016, at 6:13 PM, Dave Abrahams  wrote:
>> Or we're clueless AND it's a bad name.
> 
> It's possible, but until we have an objective rationale for why it's bad
> (arguments that it seems to imply what turns out to be the actual
> meaning of the protocol don't count!), *and* a better alternative, it's
> sort of moot.  If you don't like `Syntax.IntegerLiteral` or
> `Syntax.IntegerLiteralExpressible` then I'm out of suggestions.
> 
>> func f() -> T {
>>return 42 // the answer to everything
>> }
> 
> Promotion means something very different; something that we actually
> expect to incorporate into the language one day.

Next pitch:
Syntax.IntegerLiteralInsertion
Less successful attempts to brainstorm:
Syntax.IntegerLiteralAdvancement
Syntax.IntegerLiteralUpgrade
Syntax.FreelyIntegerReplaceable
Syntax.IntegerParkour
Syntax.TodayTheRoleOfTWillBePlayedByIntegerLiteral
Syntax.IntegerLiteralTypePoseur
Syntax.IntegerLiteral.Zigazigahh
Syntax.IntegerLiteralBoosterPack
Syntax.IntegerLevelUp
Syntax.IntegerElevator
Syntax.MarvinTheDepressedIntegerLiteral
-- E



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

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Erica Sadun via swift-evolution]

> On Jun 28, 2016, at 6:08 PM, Dave Abrahams  wrote:
> -- 
> Dave

Reload https://gist.github.com/erica/57a64163870486468180b8bab8a6294e and 
please make sure I properly updated the comments, the design, the examples.

-- E

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

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Brandon Knope via swift-evolution]

Just wanting to point out that option 2 could look vastly different! Neither 
looks "pretty", but the first one sure looks good 

Brandon 

> On Jun 28, 2016, at 8:08 PM, Dave Abrahams  wrote:
> 
> 
>> on Tue Jun 28 2016, Brandon Knope  wrote:
>> 
>> Isn't dynamicType possibly changing soon to a method?
> 
> A free function, I think.
> 
>> This could look much different
> 
> Yes, It will be uglier.  But this very uncommon case is not important to
> optimize for beauty.
> 
> -- 
> Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Dave Abrahams via swift-evolution]

on Tue Jun 28 2016, Erica Sadun  wrote:

>> On Jun 28, 2016, at 2:57 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> No, it's exactly the opposite, as I keep saying.  Conformance to this
>> protocol does *not* mean you can initialize the type with a literal.
>> Proof:
>> 
>
>>  func f() -> T {
>>return T(integerLiteral: 43) // Error
>>return T(43) // Also an Error
>>  }
>> 
>> It means an instance of the type can be *written* as a literal:
>> 
>>  func f() -> T {
>>return 43   // OK
>>  }
>> 
>> Everybody's confused about the meaning of the protocol, and doesn't like
>> the proposed names because they imply exactly the actual meaning of the
>> protocol, which they misunderstand.
>
> Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot.  If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

> func f() -> T {
> return 42 // the answer to everything
> }

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

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

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Dave Abrahams via swift-evolution]

on Tue Jun 28 2016, Brandon Knope  wrote:

> Isn't dynamicType possibly changing soon to a method?

A free function, I think.

> This could look much different

Yes, It will be uglier.  But this very uncommon case is not important to
optimize for beauty.

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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Dave Abrahams via swift-evolution]

on Tue Jun 28 2016, Douglas Gregor  wrote:

>> On Jun 27, 2016, at 12:56 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Sat Jun 25 2016, Austin Zheng  wrote:
>> 
>
 On Jun 25, 2016, at 6:23 AM, Matthew Johnson  
 wrote:
 
 Hi Austin,
 
 I’m sorry to say, but this proposal makes me really sad.  I consider
 associated type inference one of the more elegant aspects of Swift.
 It would be very unfortunate to lose it.
>>> 
>>> There are lots of "elegant" things that Swift could do, but has chosen
>>> not to do for pragmatic reasons (e.g. generalized implicit
>>> conversions, type inference that crosses statement boundaries). Given
>>> how terrible the development experience can be right now in the worst
>>> case, I would happily trade off some measure of convenience for better
>>> tooling.
>> 
>> Well, the type checker's inference engine has *always* been kinda
>> unreliable,
>
> Dave is dramatically understating the pain that this inference has
> caused. 

What are you talking about? I did not characterize the magnitude of the
pain in any way whatsoever.

> Because this is the only place we do global type inference, it’s put
> tremendous pressure on the type checker that caused a huge number of
> bugs, crashes, and outright incomprehensible behavior. I reimplemented
> the inference of associated type witnesses in April of 2015
> (https://github.com/apple/swift/commit/126e404fe5bf0be81206f22c83a61f6689d18854
> ,
> for reference), when the existing implementation unbearable. It got
> *far* better, but it’s still not global *enough* to actually be
> predictable, and the legacy of this mis-feature manifests in a number
> of weird ways (e.g., typealiases in protocol extensions cannot be used
> to satisfy associated type requirements, weird rules for when a
> defaulted associated type gets used).
>
>> and the experience is made much worse by the lack of
>> recursive protocol requirements and the inability to express other
>> constraints that would better guide inference, and by the “underscored
>> protocols” such as _Indexable that are required to work around those
>> limitations.  IMO it's premature to remove this feature before the
>> inference engine is made sane, the generics features are added, and the
>> library is correspondingly cleaned up, because we don't really know what
>> the user experience would be.
>
> Well, there’s a chicken-and-egg problem. The complexity of this
> inference is getting in the way of other improvements. 

I figured that might be the case.  If we have to drop that inference in
order to evolve the other improvements in a sane way, I strongly endorse
doing so, at least temporarily :-) But I think we should be prepared to
re-evaluate the situation after the dust settles.

> For example, inference of associated types for conditional
> conformances requires that associated type witness deduction consider
> additional requirements, which is a complexity we would entirely avoid
>
>> Finally, I am very concerned that there are protocols such as Collection,
>> with many inferrable associated types, and that conforming to these
>> protocols could become *much* uglier.
>
> That’s the general concern I have as well: how much boilerplate does
> this add? In many cases, we get some of the associated type witnesses
> for Collection types for free, and I don’t know to what extent we can
> emulate that with defaulted associated type requirements and
> typealiases in protocol extensions.
>
> That said, I’ll take some minor regressions in this area for the
> massive simplification that this proposal brings.

It remains to be seen how minor the usability regressions are, of
course.

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

Re: [swift-evolution] [Proposal] Sealed classes by default

[John McCall via swift-evolution]

> On Jun 28, 2016, at 4:01 PM, Michael Peternell  
> wrote:
>> Am 29.06.2016 um 00:32 schrieb John McCall :
>> 
>> The decision to make class methods polymorphic by default was always 
>> premised on being able to undo that in obvious cases where methods are never 
>> overridden.  Making a class public so that clients can use it shouldn't 
>> cause significant performance degradations just because you forgot to also 
>> write "final".
>> 
>> John.
> 
> I do care about performance. For this reason I don't want a fully dynamic 
> language. I disagree about the "significant performance degradations just 
> because you forgot to also write `final`". I mentioned "performance" in my 
> original post only because it would be the only convincing argument - if 
> there were indeed superior performance when using `final`.
> 
> Of course, dynamic dispatch is much slower than static dispatch. But 
> optimized code does not spend much time dispatching. If a method takes 3 
> seconds to complete, and from that 2 seconds are used for dynamically 
> dispatching method calls, then I would say that it has not been optimized for 
> performance yet. How would such a function look like? The function being 
> dynamically dispatched should probably not be statically dispatched but 
> inlined completely. And for the rare case that the dispatch type really makes 
> all the difference, it's always possible to `final`ize (or `private`ize) some 
> of the used methods.

Getters and setters are major examples of methods that (1) are very likely to 
be made public on a public class, (2) are very, very profitable to devirtualize 
and inline within the class's implementation, and (3) most programmers will 
never think to mark final (and are very annoying to "inline").  Now, if the 
program contains some cubic algorithm, then of course this level of micro 
performance doesn't matter much; it's at best a constant factor on the Nested 
Loop Of Doom.  However, as a language implementor, it is not fair for me to 
assume that the program contains brazen inefficiencies that will swamp the 
impact of any decision I make; it is often the case that, after crossing off a 
few prominent hot-spots, programmers find themselves staring at profiles that 
are disconcertingly flat.  And a lot of programmers feel quite rightly that 
they shouldn't have to massively uglify their source code with annotations just 
to get a little bit of performance, especially if it feels like something the 
language ought to just know.

I also have some responsibility to the system to try to run code as efficiently 
as possible, even if the programmer (be it through laziness, ignorance, or — 
more likely — just being over-worked) didn't put much conscious effort into 
optimizing it.

Anyway, I think you're underselling the advantages of devirtualization.

First, modern systems do a *lot* of indirect calls.  On a typical iOS device, 
the indirect branch predictor is not very effective, not because its prediction 
algorithm is in any way inadequate but because its cache is just not large 
enough to deal with all the indirect branches being executed by (mostly) 
objc_msgSend.  (I am not a hardware expert, but as I understand it, it is not 
easy to just make these caches bigger.)  Just making a bunch of calls direct 
instead means those calls (1) won't miss in the cache and (2) won't contribute 
to thrashing the cache for other calls.

Second, devirtualization is a major enabling optimization.  Many methods are 
quite small, especially the ones that you probably don't think of as methods, 
like the implicit accessors for stored properties.  Being able to inline them, 
or even just reason about whether they change memory, can have a big impact.

Finally, the specific form of devirtualization in question here, where a method 
is proven to never be overridden (again, very common for accessors!), can have 
a significant impact separate from any calls because the method essentially no 
longer needs to be virtual.  That is, it can be removed from the virtual method 
tables completely, and we may be able to completely avoid emitting it.  That 
shrinks the size of global memory (and the binary), decrease the amount of work 
that has to be done at load-time, and improves locality within the virtual 
table.

I also think this is the right thing to do for library evolution, but yes, it 
is a very valuable optimization that we would otherwise struggle to do for 
public classes.

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

Re: [swift-evolution] [Proposal] Sealed classes by default

[Mark Lacey via swift-evolution]

> On Jun 28, 2016, at 4:01 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> 
>> Am 29.06.2016 um 00:32 schrieb John McCall :
>> 
>> The decision to make class methods polymorphic by default was always 
>> premised on being able to undo that in obvious cases where methods are never 
>> overridden.  Making a class public so that clients can use it shouldn't 
>> cause significant performance degradations just because you forgot to also 
>> write "final".
>> 
>> John.
> 
> I do care about performance. For this reason I don't want a fully dynamic 
> language. I disagree about the "significant performance degradations just 
> because you forgot to also write `final`". I mentioned "performance" in my 
> original post only because it would be the only convincing argument - if 
> there were indeed superior performance when using `final`.

There is, and it can be very substantial. Knowing a method is final enables the 
optimizer to devirtualize, and devirtualization enables type-based 
specialization for generic functions, as well as inlining (each of which enable 
further devirtualization, etc., etc.). Devirtualization also makes it possible 
to do specialization of function signatures, which can remove ARC overhead. 
When that kicks in it can be a substantial win by itself. It can also improve 
the results of interprocedural analysis, which can provide further benefit (and 
which we’ll likely rely on more for performance improvement in the future). For 
example we are currently able to stack-allocate some data that was heap 
allocated in Swift 2.x because we do escape analysis, which is only possible 
when you know all the potential callees at a call site.

I recall seeing performance differences of 40x (yes, 40x, not 40%) on 
small-to-moderately sized benchmarks that use generics due to whole module 
optimization being able to infer final for internal classes. Part of that 
performance difference can be accounted for by known issues with the 
performance of generic code, but even if we substantially improve that I 
believe we would still have cases where lack of devirtualizing, inlining, and 
specialization would result in substantially slower code. 

Mark

> 
> Of course, dynamic dispatch is much slower than static dispatch. But 
> optimized code does not spend much time dispatching. If a method takes 3 
> seconds to complete, and from that 2 seconds are used for dynamically 
> dispatching method calls, then I would say that it has not been optimized for 
> performance yet. How would such a function look like? The function being 
> dynamically dispatched should probably not be statically dispatched but 
> inlined completely. And for the rare case that the dispatch type really makes 
> all the difference, it's always possible to `final`ize (or `private`ize) some 
> of the used methods.
> 
> -Michael
> 
> ___
> 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] Setter methods for vars

[Austin Feight via swift-evolution]

Built-in lenses would solve this issue and much more, didn't know it was on
the list already!

*Austin Feight *| Chief Shipping Officer


150 E. 52nd Street, 22nd Floor, New York, NY 10022
www.chexology.com  | www.austindfeight.com

On Tue, Jun 28, 2016 at 7:33 PM, Michael Peternell via swift-evolution <
swift-evolution@swift.org> wrote:

> Haha, I think if we support lenses we should also support a QBit
> structure, because lenses are just special cases for QBits ;) That said, I
> think it's unlikely that lenses will be supported in Swift 4. We should
> wait for Swift 5 when the full QBit-library will be introduced
> (hardware-accellerated of course, but it deploys back until the iPhone 6S.)
>
> Good night guys (it's 1:30 am in my time zone...)
>
> -Michael
>
> > Am 29.06.2016 um 01:22 schrieb Sean Heber via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Lens are a term from functional programming theory (I think largely
> Haskell in particular?). I don't know much about it, but here's somewhere
> to start: https://www21.in.tum.de/teaching/fp/SS15/papers/17.pdf
> >
> > l8r
> > Sean
> >
> > Sent from my iPad
> >
> > On Jun 28, 2016, at 6:11 PM, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> Really?? Or we just have #set and #get and no lenses, and it's done for
> Swift 3?
> >>
> >> I never heard of lenses (Google does not help here). Was this serious
> or were you joking? Unless you can explain why #set and #get without lenses
> would be bad... or maybe #set and #get *are* lenses, in which case I'm not
> sure what you were trying to say. Reflexion -> Reflection?
> >>
> >> -Michael
> >>
> >>> Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution <
> swift-evolution@swift.org>:
> >>>
> >>> This looks like lenses. I think we need to wait until after Swift 3 to
> discuss it, and come up with a bigger design that ties to reflexion.
> >>>
>  On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  So you're proposing that `#set(aVariableName)` should translate to
> `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue
> like `self.users` or `users` or `vc.viewControllers`..
> 
>  I think this would be a good extension to Swift. (`users.set` does
> not work BTW, because maybe the `users` object has a `set` property.. maybe
> I wanted to refer to the `set` property which also happens to refer to a
> closure value.)
> 
>  `#set(aVariableName)` also feels consistent with the
> `#keyPath(aVariableName)` property and falls into a similar category. Maybe
> `#setter(aVariableName)` would be even more clear? Furthermore, I want to
> additionally propose to introduce `#get(aVariableName)` (or
> `#getter(aVariableName)`) too.
> 
>  -Michael
> 
> > Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Proposal:
> >
> > I propose adding setter methods to vars, which could look something
> like this: `ApiClient().fetchUsers().then(#set(users))`
> >
> > Initially I thought it should work like this:
> `ApiClient().fetchUsers().then(users.set)`
> > but to accomplish a line of code that flows grammatically, I believe
> putting "set" where it would naturally fall if the code was being read as a
> sentence is more Swifty.
> >
> > Rationale:
> >
> > The following code makes me smile:
> >
> > ApiClient().fetchUsers().then(displayUsers)
> >
> > It exemplifies the beauty of Swift. First-class functions make this
> line of code read very well. Consider some alternatives:
> >
> > 1. ApiClient().fetchUsers().then { displayUsers($0) }
> > 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
> > 3. ApiClient().fetchUsers().then { (users: [User]) in
> displayUsers(users) }
> >
> > Using the lessons learned from Swift API Design Guidelines (WWDC
> 2016 Session 403) having an emphasis on clarity, my analysis of the
> alternatives is:
> >
> > 1. $0 adds no additional information as to the type or explanation
> of what the argument is, thus adding nothing to the line of code for
> clarity, and therefore should be omitted
> > 2. adding "users" also adds nothing to the clarity of the code. The
> function, properly, contains the information necessary to reason about the
> argument it takes and what it does, and therefore adding "users" is
> redundant
> > 3. Not only is "users" redundant, but also is the explicit type
> label. The `displayUsers` method will only accept one type of argument, so
> we're duplicating information that the compiler (and autocomplete) already
> gives us
> >
> > With this I conclude that
> `ApiClient().fetchUsers().then(displayUsers)` is the Swiftiest option.
> > I want to extend this same logic to when I find myself writing code
> like this:
> >
> > 

Re: [swift-evolution] Setter methods for vars

[Michael Peternell via swift-evolution]

Haha, I think if we support lenses we should also support a QBit structure, 
because lenses are just special cases for QBits ;) That said, I think it's 
unlikely that lenses will be supported in Swift 4. We should wait for Swift 5 
when the full QBit-library will be introduced (hardware-accellerated of course, 
but it deploys back until the iPhone 6S.)

Good night guys (it's 1:30 am in my time zone...)

-Michael

> Am 29.06.2016 um 01:22 schrieb Sean Heber via swift-evolution 
> :
> 
> Lens are a term from functional programming theory (I think largely Haskell 
> in particular?). I don't know much about it, but here's somewhere to start: 
> https://www21.in.tum.de/teaching/fp/SS15/papers/17.pdf
> 
> l8r
> Sean
> 
> Sent from my iPad
> 
> On Jun 28, 2016, at 6:11 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
>> Really?? Or we just have #set and #get and no lenses, and it's done for 
>> Swift 3?
>> 
>> I never heard of lenses (Google does not help here). Was this serious or 
>> were you joking? Unless you can explain why #set and #get without lenses 
>> would be bad... or maybe #set and #get *are* lenses, in which case I'm not 
>> sure what you were trying to say. Reflexion -> Reflection?
>> 
>> -Michael
>> 
>>> Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution 
>>> :
>>> 
>>> This looks like lenses. I think we need to wait until after Swift 3 to 
>>> discuss it, and come up with a bigger design that ties to reflexion.
>>> 
 On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution 
  wrote:
 
 So you're proposing that `#set(aVariableName)` should translate to 
 `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue 
 like `self.users` or `users` or `vc.viewControllers`..
 
 I think this would be a good extension to Swift. (`users.set` does not 
 work BTW, because maybe the `users` object has a `set` property.. maybe I 
 wanted to refer to the `set` property which also happens to refer to a 
 closure value.)
 
 `#set(aVariableName)` also feels consistent with the 
 `#keyPath(aVariableName)` property and falls into a similar category. 
 Maybe `#setter(aVariableName)` would be even more clear? Furthermore, I 
 want to additionally propose to introduce `#get(aVariableName)` (or 
 `#getter(aVariableName)`) too.
 
 -Michael
 
> Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution 
> :
> 
> Proposal:
> 
> I propose adding setter methods to vars, which could look something like 
> this: `ApiClient().fetchUsers().then(#set(users))`
> 
> Initially I thought it should work like this: 
> `ApiClient().fetchUsers().then(users.set)`
> but to accomplish a line of code that flows grammatically, I believe 
> putting "set" where it would naturally fall if the code was being read as 
> a sentence is more Swifty.
> 
> Rationale:
> 
> The following code makes me smile:
> 
> ApiClient().fetchUsers().then(displayUsers)
> 
> It exemplifies the beauty of Swift. First-class functions make this line 
> of code read very well. Consider some alternatives:
> 
> 1. ApiClient().fetchUsers().then { displayUsers($0) }
> 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
> 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) 
> }
> 
> Using the lessons learned from Swift API Design Guidelines (WWDC 2016 
> Session 403) having an emphasis on clarity, my analysis of the 
> alternatives is:
> 
> 1. $0 adds no additional information as to the type or explanation of 
> what the argument is, thus adding nothing to the line of code for 
> clarity, and therefore should be omitted
> 2. adding "users" also adds nothing to the clarity of the code. The 
> function, properly, contains the information necessary to reason about 
> the argument it takes and what it does, and therefore adding "users" is 
> redundant
> 3. Not only is "users" redundant, but also is the explicit type label. 
> The `displayUsers` method will only accept one type of argument, so we're 
> duplicating information that the compiler (and autocomplete) already 
> gives us
> 
> With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` 
> is the Swiftiest option.
> I want to extend this same logic to when I find myself writing code like 
> this:
> 
> ApiClient().fetchUsers().then { users in
> self.users = users
> }
> 
> or alternatively, because "users" is likely redundant information again,
> 
> ApiClient().fetchUsers().then { self.users = $0 }
> 
> Personally I steer clear of `$0` as much as possible, because I very 
> rarely feel that 

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Matthew Johnson via swift-evolution]

> On Jun 28, 2016, at 3:24 PM, Austin Zheng  wrote:
> 
> Inline
> 
> On Mon, Jun 27, 2016 at 6:47 AM, Matthew Johnson  > wrote:
> 
> 
> Sent from my iPad
> 
> On Jun 25, 2016, at 12:41 PM, Austin Zheng  > wrote:
>> I actually think that the delineation between `associatedtype` and 
>> `typealias` should make this legal, and will change the proposal as such. It 
>> should be legal to bind an associated type to a type alias, and it should be 
>> possible to define a type alias that shadows (but does not conflict with) an 
>> associated type definition. This would fix the issue with retroactive 
>> modeling.
> 
> IIUC you're saying a type is allowed to have an `associatedtype` and 
> `typealias` (or nested type) both bound to the same name as long as they 
> resolve to the same type.  Is that correct?  That would at least preserve 
> current expressiveness.
> 
> Yes, that is exactly correct :).
> 
> I actually have an alternative (see the last sub-entry in the alternative 
> section) that would relax even that restriction. This would actually make the 
> language slightly more expressive, since you would _theoretically_ be able to 
> get around the typealias or nested type aliasing issues that exist today. I 
> argued a bit against it but it's there in case the core team disagrees.
>  
> 
>> 
>>> 
>>> // Module A
>>> public struct S {
>>> public typealias Foo = Int
>>> }
>>> 
>>> // Module B
>>> public protocol P {
>>> associatedtype Foo
>>> }
>>> 
>>> // Module C
>>> import A
>>> import B
>>> 
>>> // compiler error: `S` does not meet the `Foo` associatedtype requirement
>>> extension S : P {
>>> // compiler error: cannot define associatedtype `Foo` for `S` which 
>>> already declares typealias `Foo`
>>> associatedtype Foo = String
>>> }
>>> 
>>> I cannot support any proposal that breaks retroactive modeling in this way.
>> 
>> Addendum aside, retroactive modeling is already suboptimal or broken in 
>> multiple ways today - try conforming a protocol with associated type 
>> 'Element' to a different protocol whose 'Element' means something completely 
>> different.
> 
> Did you mean conforming a type to two protocols with an 'Element' 
> associatedtype?
> 
> I consider that issue to be in the realm of multiple conformances rather than 
> retroactive modeling.  I can still 
> 
> Yeah, I completely mangled that sentence.
> 
> I think it does fall into the realm of retroactive modeling, since an 
> existing type may be prevented from being retroactively conformed to a new 
> protocol by an existing conformance that it has.

I suppose you can look at it that way.  

Here’s a suggestion for your proposal: if we’re going to go as far as requiring 
explicit `associatedtype` declarations why not allow disambiguation?  If there 
are two protocols `Foo` and `Bar` both with an `Element` associated type maybe 
we should be able to write `Foo.Element` and `Bar.Element` if that is necessary 
to disambiguate.  This would also work in cases like the one you mention above 
when reference your alternative, but without introducing two different bindings 
for the same name.

It wouldn’t have made sense in the current syntax using `typealias` but if we 
use a declaration that *only* exists for the purpose of conformance it seems 
like allowing disambiguation is a rather obvious thing to do (once you think of 
the idea). 

>  
> 
> 
> Thank you for adding the clarifications.  I feel a little better knowing we 
> wouldn't lose expressive power, but still prefer the directed inference 
> suggested by Dmitri.
> 
> 
> And thank you for your honest feedback! 
> 

You’re welcome.  I’m still hoping we find a way out of this (the idea of 
writing these out for every conformance is a real bummer), but that hope is 
fading after reading Doug’s reply to Dmitri.  In the end I trust the core team 
will make the right decision.  It seems like the library folks would prefer to 
avoid dropping inference so I’m sure there will be a healthy debate by folks 
who are far more expert on this topic than I.

-Matthew

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

Re: [swift-evolution] Setter methods for vars

[Sean Heber via swift-evolution]

Lens are a term from functional programming theory (I think largely Haskell in 
particular?). I don't know much about it, but here's somewhere to start: 
https://www21.in.tum.de/teaching/fp/SS15/papers/17.pdf

l8r
Sean

Sent from my iPad

> On Jun 28, 2016, at 6:11 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Really?? Or we just have #set and #get and no lenses, and it's done for Swift 
> 3?
> 
> I never heard of lenses (Google does not help here). Was this serious or were 
> you joking? Unless you can explain why #set and #get without lenses would be 
> bad... or maybe #set and #get *are* lenses, in which case I'm not sure what 
> you were trying to say. Reflexion -> Reflection?
> 
> -Michael
> 
>> Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution 
>> :
>> 
>> This looks like lenses. I think we need to wait until after Swift 3 to 
>> discuss it, and come up with a bigger design that ties to reflexion.
>> 
>>> On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution 
>>>  wrote:
>>> 
>>> So you're proposing that `#set(aVariableName)` should translate to 
>>> `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue 
>>> like `self.users` or `users` or `vc.viewControllers`..
>>> 
>>> I think this would be a good extension to Swift. (`users.set` does not work 
>>> BTW, because maybe the `users` object has a `set` property.. maybe I wanted 
>>> to refer to the `set` property which also happens to refer to a closure 
>>> value.)
>>> 
>>> `#set(aVariableName)` also feels consistent with the 
>>> `#keyPath(aVariableName)` property and falls into a similar category. Maybe 
>>> `#setter(aVariableName)` would be even more clear? Furthermore, I want to 
>>> additionally propose to introduce `#get(aVariableName)` (or 
>>> `#getter(aVariableName)`) too.
>>> 
>>> -Michael
>>> 
 Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution 
 :
 
 Proposal:
 
 I propose adding setter methods to vars, which could look something like 
 this: `ApiClient().fetchUsers().then(#set(users))`
 
 Initially I thought it should work like this: 
 `ApiClient().fetchUsers().then(users.set)`
 but to accomplish a line of code that flows grammatically, I believe 
 putting "set" where it would naturally fall if the code was being read as 
 a sentence is more Swifty.
 
 Rationale:
 
 The following code makes me smile:
 
 ApiClient().fetchUsers().then(displayUsers)
 
 It exemplifies the beauty of Swift. First-class functions make this line 
 of code read very well. Consider some alternatives:
 
 1. ApiClient().fetchUsers().then { displayUsers($0) }
 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }
 
 Using the lessons learned from Swift API Design Guidelines (WWDC 2016 
 Session 403) having an emphasis on clarity, my analysis of the 
 alternatives is:
 
 1. $0 adds no additional information as to the type or explanation of what 
 the argument is, thus adding nothing to the line of code for clarity, and 
 therefore should be omitted
 2. adding "users" also adds nothing to the clarity of the code. The 
 function, properly, contains the information necessary to reason about the 
 argument it takes and what it does, and therefore adding "users" is 
 redundant
 3. Not only is "users" redundant, but also is the explicit type label. The 
 `displayUsers` method will only accept one type of argument, so we're 
 duplicating information that the compiler (and autocomplete) already gives 
 us
 
 With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is 
 the Swiftiest option.
 I want to extend this same logic to when I find myself writing code like 
 this:
 
 ApiClient().fetchUsers().then { users in
 self.users = users
 }
 
 or alternatively, because "users" is likely redundant information again,
 
 ApiClient().fetchUsers().then { self.users = $0 }
 
 Personally I steer clear of `$0` as much as possible, because I very 
 rarely feel that it provides the information necessary for code clarity. 
 But beyond that, this code no longer reads as nicely as the code we had 
 before. 
 
 Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a 
 sentence and reads grammatically, `ApiClient().fetchUsers().then { 
 self.users = $0 }` no longer does.
 
 I think this feature could have a simple implementation where the compiler 
 replaces `#set(X)` with `{ X = $0 }`, and I believe it would go a long way 
 with respect to code clarity, especially when X is something longer like 
 `self.view.bounds.origin.x`
 

Re: [swift-evolution] Setter methods for vars

[Michael Peternell via swift-evolution]

Really?? Or we just have #set and #get and no lenses, and it's done for Swift 3?

I never heard of lenses (Google does not help here). Was this serious or were 
you joking? Unless you can explain why #set and #get without lenses would be 
bad... or maybe #set and #get *are* lenses, in which case I'm not sure what you 
were trying to say. Reflexion -> Reflection?

-Michael

> Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution 
> :
> 
> This looks like lenses. I think we need to wait until after Swift 3 to 
> discuss it, and come up with a bigger design that ties to reflexion.
> 
>> On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> So you're proposing that `#set(aVariableName)` should translate to 
>> `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue 
>> like `self.users` or `users` or `vc.viewControllers`..
>> 
>> I think this would be a good extension to Swift. (`users.set` does not work 
>> BTW, because maybe the `users` object has a `set` property.. maybe I wanted 
>> to refer to the `set` property which also happens to refer to a closure 
>> value.)
>> 
>> `#set(aVariableName)` also feels consistent with the 
>> `#keyPath(aVariableName)` property and falls into a similar category. Maybe 
>> `#setter(aVariableName)` would be even more clear? Furthermore, I want to 
>> additionally propose to introduce `#get(aVariableName)` (or 
>> `#getter(aVariableName)`) too.
>> 
>> -Michael
>> 
>>> Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution 
>>> :
>>> 
>>> Proposal:
>>> 
>>> I propose adding setter methods to vars, which could look something like 
>>> this: `ApiClient().fetchUsers().then(#set(users))`
>>> 
>>> Initially I thought it should work like this: 
>>> `ApiClient().fetchUsers().then(users.set)`
>>> but to accomplish a line of code that flows grammatically, I believe 
>>> putting "set" where it would naturally fall if the code was being read as a 
>>> sentence is more Swifty.
>>> 
>>> Rationale:
>>> 
>>> The following code makes me smile:
>>> 
>>> ApiClient().fetchUsers().then(displayUsers)
>>> 
>>> It exemplifies the beauty of Swift. First-class functions make this line of 
>>> code read very well. Consider some alternatives:
>>> 
>>> 1. ApiClient().fetchUsers().then { displayUsers($0) }
>>> 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
>>> 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }
>>> 
>>> Using the lessons learned from Swift API Design Guidelines (WWDC 2016 
>>> Session 403) having an emphasis on clarity, my analysis of the alternatives 
>>> is:
>>> 
>>> 1. $0 adds no additional information as to the type or explanation of what 
>>> the argument is, thus adding nothing to the line of code for clarity, and 
>>> therefore should be omitted
>>> 2. adding "users" also adds nothing to the clarity of the code. The 
>>> function, properly, contains the information necessary to reason about the 
>>> argument it takes and what it does, and therefore adding "users" is 
>>> redundant
>>> 3. Not only is "users" redundant, but also is the explicit type label. The 
>>> `displayUsers` method will only accept one type of argument, so we're 
>>> duplicating information that the compiler (and autocomplete) already gives 
>>> us
>>> 
>>> With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is 
>>> the Swiftiest option.
>>> I want to extend this same logic to when I find myself writing code like 
>>> this:
>>> 
>>> ApiClient().fetchUsers().then { users in
>>> self.users = users
>>> }
>>> 
>>> or alternatively, because "users" is likely redundant information again,
>>> 
>>> ApiClient().fetchUsers().then { self.users = $0 }
>>> 
>>> Personally I steer clear of `$0` as much as possible, because I very rarely 
>>> feel that it provides the information necessary for code clarity. But 
>>> beyond that, this code no longer reads as nicely as the code we had before. 
>>> 
>>> Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a 
>>> sentence and reads grammatically, `ApiClient().fetchUsers().then { 
>>> self.users = $0 }` no longer does.
>>> 
>>> I think this feature could have a simple implementation where the compiler 
>>> replaces `#set(X)` with `{ X = $0 }`, and I believe it would go a long way 
>>> with respect to code clarity, especially when X is something longer like 
>>> `self.view.bounds.origin.x`
>>> 
>>> 
>>> Looking forward to hearing thoughts from the community,
>>> Austin Feight
>>> ___
>>> 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] Remove destructive consumption from Sequence

[Matthew Johnson via swift-evolution]

> On Jun 28, 2016, at 3:33 PM, Brent Royal-Gordon  
> wrote:
> 
>> This use case seems interesting enough to at least deserve some 
>> consideration before we decide to require iterators to have reference 
>> semantics.  IMO the fact that `next` is a mutating requirement provides a 
>> pretty strong indication of the destructive / consuming semantics of using 
>> an iterator.  Requiring reference semantics gives up flexibility and I’m not 
>> completely convinced it adds clarity (but still keeping an open mind about 
>> this).
> 
> My feeling is that, except for the trivial case of IndexingIterator and other 
> iterators over collections, all iterators *should* need reference semantics. 
> If your iterator can offer value semantics, then you should convert it into a 
> Collection to gain the benefits of indices.

Assuming we are going to pin down the requirement that Collection be finite (in 
the sense that iterating over the whole collection is practical in a real 
program running on a real device that is available today) then it is trivial to 
come up with value semantic iterators that cannot conform to Collection.  For 
example, iterators over infinite mathematical sequences.

> If it can't offer value semantics, then you should write it as a class so 
> those reference semantics are obvious.

I agree with this.

> This would get rid of the really ugly caveat that's always festered at the 
> heart of Iterator:
> 
 Obtain each separate iterator from separate calls to the sequence's 
 makeIterator() method rather than by copying. Copying an iterator is safe, 
 but advancing one copy of an iterator by calling its next() method may 
 invalidate other copies of that iterator. for-in loops are safe in this 
 regard.
> 
> The underlying cause of this requirement is that you can't know whether a 
> given iterator is a value type or a reference type. Let's fix that.

I would like to see us eventually have a way to specify a generic constraint 
indicating value semantics regardless of what happens with iterators.  If we 
gain that capability you *can* know that you have a value semantic iterator 
when you use that constraint.  

I am not firmly opposed to making iterators require reference semantics but I 
don’t think the pros and cons have been thoroughly discussed on the list yet so 
I am pointing out what I think are interesting use cases for value semantic 
iterators.

Swift is a language that embraces value semantics.  Many common iterators *can* 
be implemented with value semantics.  Just because we can’t implement *all* 
iterators with value semantics doesn’t mean we should require them to have 
reference semantics.  It just means you can’t *assume* value semantics when 
working with iterators in generic code unless / until we have a way to specify 
a value semantics constraint.  That’s not necessarily a bad thing especially 
when it leaves the door open to interesting future possibilities.

-Matthew

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

[Xiaodi Wu via swift-evolution]

I understand that that's your thinking. I just don't understand how you
arrived at your rule (2). It's not in the dictionary definition of the
words prefix and suffix. Nor do I find any documentation of such a rule in
Swift. Nor do I think you've shown that such a rule is necessary for
clearing up some actual confusion. Nor do I see that applying the rule and
using subscripts yields a superior solution to what we currently have.
On Tue, Jun 28, 2016 at 5:40 PM Brent Royal-Gordon 
wrote:

> > I was in the midst of writing a reply along the same lines, so I figured
> I'd add to David's reply here. There are two characteristics I would expect
> from a method named "prefix" or "suffix".
> >
> > First, it should return a subsequence containing zero to count elements.
> (By contrast, something named "first" should return nil or one element, but
> certainly no more.)
> >
> > Second, in the case of "prefix", the first element of the subsequence
> (if any) should be the first element of the sequence; in the case of
> "suffix", the last element of the subsequence (if any) should be the last
> element of the sequence.
>
> I would phrase these things slightly differently. In my thinking, a method
> with `prefix` or `suffix` in its name:
>
> 1. Operates on a subsequence at the beginning/end of the sequence,
>
> 2. Measured *relative* to the beginning/end.
>
> An index-based operation doesn't fit this definition because an index is
> not *relative* to anything—it's an *absolute* position within the sequence.
>
> Put another way, in my view, "prefix" and "suffix" don't merely mean
> "anchored at the beginning/end". A prefix or suffix is attached to a
> "middle". There is no middle in the index-based operations.
>
> It is, of course, very possible to use methods to express what the
> index-based operations do:
>
> friends.upTo(i)
> friends.through(i)
> friends.from(i)
>
> But at this point, we've basically arrived at `friends[to: i]` etc.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

[David Hart via swift-evolution]

> On 29 Jun 2016, at 00:40, Brent Royal-Gordon  wrote:
> 
>   2. Measured *relative* to the beginning/end.

This is the crux of our disagreement :) I don’t agree with point number 2.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Sealed classes by default

[Michael Peternell via swift-evolution]

> Am 29.06.2016 um 00:32 schrieb John McCall :
> 
> The decision to make class methods polymorphic by default was always premised 
> on being able to undo that in obvious cases where methods are never 
> overridden.  Making a class public so that clients can use it shouldn't cause 
> significant performance degradations just because you forgot to also write 
> "final".
> 
> John.

I do care about performance. For this reason I don't want a fully dynamic 
language. I disagree about the "significant performance degradations just 
because you forgot to also write `final`". I mentioned "performance" in my 
original post only because it would be the only convincing argument - if there 
were indeed superior performance when using `final`.

Of course, dynamic dispatch is much slower than static dispatch. But optimized 
code does not spend much time dispatching. If a method takes 3 seconds to 
complete, and from that 2 seconds are used for dynamically dispatching method 
calls, then I would say that it has not been optimized for performance yet. How 
would such a function look like? The function being dynamically dispatched 
should probably not be statically dispatched but inlined completely. And for 
the rare case that the dispatch type really makes all the difference, it's 
always possible to `final`ize (or `private`ize) some of the used methods.

-Michael

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

Re: [swift-evolution] Setter methods for vars

[David Hart via swift-evolution]

This looks like lenses. I think we need to wait until after Swift 3 to discuss 
it, and come up with a bigger design that ties to reflexion.

> On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution 
>  wrote:
> 
> So you're proposing that `#set(aVariableName)` should translate to 
> `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue like 
> `self.users` or `users` or `vc.viewControllers`..
> 
> I think this would be a good extension to Swift. (`users.set` does not work 
> BTW, because maybe the `users` object has a `set` property.. maybe I wanted 
> to refer to the `set` property which also happens to refer to a closure 
> value.)
> 
> `#set(aVariableName)` also feels consistent with the 
> `#keyPath(aVariableName)` property and falls into a similar category. Maybe 
> `#setter(aVariableName)` would be even more clear? Furthermore, I want to 
> additionally propose to introduce `#get(aVariableName)` (or 
> `#getter(aVariableName)`) too.
> 
> -Michael
> 
>> Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution 
>> :
>> 
>> Proposal:
>> 
>> I propose adding setter methods to vars, which could look something like 
>> this: `ApiClient().fetchUsers().then(#set(users))`
>> 
>> Initially I thought it should work like this: 
>> `ApiClient().fetchUsers().then(users.set)`
>> but to accomplish a line of code that flows grammatically, I believe putting 
>> "set" where it would naturally fall if the code was being read as a sentence 
>> is more Swifty.
>> 
>> Rationale:
>> 
>> The following code makes me smile:
>> 
>> ApiClient().fetchUsers().then(displayUsers)
>> 
>> It exemplifies the beauty of Swift. First-class functions make this line of 
>> code read very well. Consider some alternatives:
>> 
>> 1. ApiClient().fetchUsers().then { displayUsers($0) }
>> 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
>> 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }
>> 
>> Using the lessons learned from Swift API Design Guidelines (WWDC 2016 
>> Session 403) having an emphasis on clarity, my analysis of the alternatives 
>> is:
>> 
>> 1. $0 adds no additional information as to the type or explanation of what 
>> the argument is, thus adding nothing to the line of code for clarity, and 
>> therefore should be omitted
>> 2. adding "users" also adds nothing to the clarity of the code. The 
>> function, properly, contains the information necessary to reason about the 
>> argument it takes and what it does, and therefore adding "users" is redundant
>> 3. Not only is "users" redundant, but also is the explicit type label. The 
>> `displayUsers` method will only accept one type of argument, so we're 
>> duplicating information that the compiler (and autocomplete) already gives us
>> 
>> With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is 
>> the Swiftiest option.
>> I want to extend this same logic to when I find myself writing code like 
>> this:
>> 
>> ApiClient().fetchUsers().then { users in
>>  self.users = users
>> }
>> 
>> or alternatively, because "users" is likely redundant information again,
>> 
>> ApiClient().fetchUsers().then { self.users = $0 }
>> 
>> Personally I steer clear of `$0` as much as possible, because I very rarely 
>> feel that it provides the information necessary for code clarity. But beyond 
>> that, this code no longer reads as nicely as the code we had before. 
>> 
>> Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a 
>> sentence and reads grammatically, `ApiClient().fetchUsers().then { 
>> self.users = $0 }` no longer does.
>> 
>> I think this feature could have a simple implementation where the compiler 
>> replaces `#set(X)` with `{ X = $0 }`, and I believe it would go a long way 
>> with respect to code clarity, especially when X is something longer like 
>> `self.view.bounds.origin.x`
>> 
>> 
>> Looking forward to hearing thoughts from the community,
>> Austin Feight
>> ___
>> 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] Partial list of open Swift 3 design topics

[David Hart via swift-evolution]

> On 28 Jun 2016, at 20:00, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Well, *I* want to remove associated type inference because I feel that we 
> shouldn’t have global inference like this in Swift. I am, however, concerned 
> about the standard library’s ability to make conformances to the Collection 
> protocols provide meaningful defaults for, e.g., the SubSequence associated 
> type.
> 
>   - Doug

I am also for removing associated type inference, and I guess if it needs to be 
done, its now. Concerning SubSequence, isn’t that supposed to be away post 
Swift-3 once we have some of the more powerful generics?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

[Brent Royal-Gordon via swift-evolution]

> I was in the midst of writing a reply along the same lines, so I figured I'd 
> add to David's reply here. There are two characteristics I would expect from 
> a method named "prefix" or "suffix".
> 
> First, it should return a subsequence containing zero to count elements. (By 
> contrast, something named "first" should return nil or one element, but 
> certainly no more.)
> 
> Second, in the case of "prefix", the first element of the subsequence (if 
> any) should be the first element of the sequence; in the case of "suffix", 
> the last element of the subsequence (if any) should be the last element of 
> the sequence.

I would phrase these things slightly differently. In my thinking, a method with 
`prefix` or `suffix` in its name:

1. Operates on a subsequence at the beginning/end of the sequence,

2. Measured *relative* to the beginning/end.

An index-based operation doesn't fit this definition because an index is not 
*relative* to anything—it's an *absolute* position within the sequence.

Put another way, in my view, "prefix" and "suffix" don't merely mean "anchored 
at the beginning/end". A prefix or suffix is attached to a "middle". There is 
no middle in the index-based operations.

It is, of course, very possible to use methods to express what the index-based 
operations do:

friends.upTo(i)
friends.through(i)
friends.from(i)

But at this point, we've basically arrived at `friends[to: i]` etc.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Optionals and nil in Switch statement

[Nevin Brackett-Rozinsky via swift-evolution]

I just got home and tested. The answer is yes, `case "text"?` does work.

let optStr : String? = "text"
switch optStr {
case nil : print("Nil")
case "text"? : print("Success")
default  : print("Default")
}
// Prints `Success`

Nevin

On Tue, Jun 28, 2016 at 12:27 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> Does `case "text"?` work?
>
>
> On Tuesday, June 28, 2016, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Case .none:
>> Case .some("string"):
>>
>>
>> On Jun 28, 2016, at 06:40, Lucas Jordan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Forgive me if this was/is discussed already, I am new to the process
>> here
>>
>> (code is attached as a playground too)
>>
>>
>>
>> Sometimes when I am working with a String? nil can be a reasonable value,
>> and what I want to do is something like the following:
>>
>> import UIKit
>>
>>
>> var str:String? = "Hello, playground"
>>
>>
>> switch str{
>>
>> case nil:
>>
>> print("Nil!")
>>
>> case "Hello, playground":  //it would be super nice if this worked.
>>
>> print("Match")
>>
>> default:
>>
>> print("Some other non nil value?")
>>
>> }
>>
>>
>> But it does not work, the orange  text is a compile time error,
>> "Expression pattern of type 'String' cannot match value of type 'String?'.
>> I realize that this can be replaced with a let statement (case let s
>> where s == "Hello, playground":), but that is verbose.
>>
>> Seems like the compiler could be OK with the orange text, since it is
>> clearly not nil.
>>
>> Thoughts?
>>
>> -Lucas
>>
>>
>>
>>
>>
>> 
>>
>> ___
>> 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] Sealed classes by default

[John McCall via swift-evolution]

> On Jun 28, 2016, at 2:20 PM, Christopher Kornher  wrote:
>> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution 
>>> > wrote:
>>> Sealing classes by default is a terrible idea IMHO. Fortunately, my faith 
>>> in the Swift core team is strong enough so that I cannot believe that this 
>>> has a chance of ever being implemented at all :)
>>> 
>>> Why do I think it's terrible? I do subclass classes even when they say that 
>>> you shouldn't do it. I even monkey-patched a few classes in the past. Why? 
>>> Not because I prefer hacking over clean coding, but to get the job done. 
>>> Every few months or so I encounter a situation where such hacking attempts 
>>> are the only feasible way to make something work. Or I use them during 
>>> research activities or unofficial "feasibility studies". (If that's not the 
>>> case for you, then maybe you are working in a different job than I. Monkey 
>>> patching is rarely necessary if you make iPhone apps.) These are situations 
>>> where everyone else just says "that's not possible". Yes, you can make that 
>>> USB driver class stop spamming the console; yes, you can stop that library 
>>> from crashing randomly.
>>> 
>>> There is so much more to say on this topic. Sealing classes is also bad 
>>> because it prevents forms of experimental coding. It doesn't solve a real 
>>> problem. How often have I seen bugs where someone subclassed a class that 
>>> shouldn't be subclassed? That's so rare. But if all classes are sealed by 
>>> default this will lead to far worse problems. When a developer subclasses a 
>>> class, he usually has a reason. There already is a `final` keyword in 
>>> Swift, and a dev really thinks that a class shouldn't be subclass-able, he 
>>> can use it already. And if I subclass it from Objective-C anyways, then 
>>> maybe I know what I'm doing?
>>> 
>>> And I'm not buying this "performance" argument. If you want better 
>>> performance, write the hot functions in C or maybe even in assembler. The 
>>> dynamic dispatch overhead is not the feature that makes programs bad or 
>>> slow. It's quadratic algorithms (e.g. unnecessary nested loops), calling 
>>> functions multiple times (e.g. if(a.foo.bar(x[2]) == "joo" || 
>>> a.foo.bar(x[2]) == "fooo" || a.foo.bar(x[2]) == nil) { ... }), or just 
>>> overly complex code: all of them have more impact than dynamic dispatch. 
>>> Even worse for performance is unnecessary IO or using graphics APIs 
>>> inefficiently. A good profiler can help a lot with these issues.
>>> 
>>> Swift should be designed for the real world, not for an ideal world that 
>>> does not exist and that will never exist.
>> 
>> The design intent of much of Swift is to allow "free" coding within a 
>> module/file/type while encouraging programmers to think more carefully about 
>> their public interfaces.  Module interfaces are the most serious and 
>> permanent of these interfaces.  It's in keeping with that for declarations 
>> to make only minimal public guarantees and require the programmer to be more 
>> explicit about the things they want to allow.
>> 
>> Your arguments about patchability and performance could be applied to every 
>> feature in the language.  They are essentially arguments for a fully-dynamic 
>> environment.
> 
> see https://en.wikipedia.org/wiki/Straw_man 
> 
What's the limiting argument?  Why is it critical for practical programmers to 
be able to arbitrarily patch someone else's code, but only at the point where 
it calls public methods on public classes?  That's a very strange idea in 
Swift, given how we encourage the use of structs and non-public types.

> Most OO languages do not seal seal modules (or the equivalent) by default. 
> Forcing developers to add “final” does not seem onerous. If authors do not 
> have time to audit their frameworks, the language should not pretend do it 
> for them.

Again, this could be an argument for making everything public by default.  
(Many OO languages essentially do.)  What's the limiting argument?

Swift takes a consistent line here: the default rule across a module boundary 
is the rule that reserves the implementation the greatest flexibility in the 
future.  Making classes final outside of the module gives the module the right 
to make the class final everywhere and to change the class's internal 
implementation to call different methods or change delegation patterns without 
worrying about how it affects a use-case that most programmers won't have 
considered.  If they have considered it, of course, it is trivial for them to 
write that down, just as it is trivial for them to make the class public to 
begin with.

>> There's no reason to single out subclassing; for everything you can 

Re: [swift-evolution] [Proposal draft] NSError bridging

[Douglas Gregor via swift-evolution]

> On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> Obviously, I’m in favor of this one. +1!
> 
> I think I did prefer the older name of CustomUserInfoError for the 
> domain/code/userInfo protocol, rather than CustomNSError. This is just 
> because I’d like to be able to do a global search through my project for 
> “NSError” and have it turn up empty. Maybe a silly reason, I know. ;-)


I’m floating CustomNSError as the protocol name because I don’t feel that 
domain, core, or userInfo are fundamental to the Swift error model—they’re 
about exposing things specifically to NSError.

- Doug

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

[swift-evolution] Fix or remove Swift.min and Swift.max?

[Jens Persson via swift-evolution]

Hi all!

Swift.min (and Swift.max) propagates nan or not depending on the order of
its args:

Swift.min(1.0, .nan) // 1.0
Swift.min(.nan, 1.0) // nan (!)

Double.minimum(1.0, .nan) // 1.0
Double.minimum(.nan, 1.0) // 1.0

fmin(1.0, .nan) // 1.0
fmin(.nan, 1.0) // 1.0

The new static minimum and maximum funcs on FloatingPoint in Swift 3 shows
the expected behaviour (ie the same as fmin, fmax and IEEE-754), so what
should happen with Swift.min and Swift.max?

Fix, remove or perhaps something else?

https://bugs.swift.org/browse/SR-1011

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

Re: [swift-evolution] [Proposal] Sealed classes by default

[Christopher Kornher via swift-evolution]

> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution 
>>  wrote:
>> Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in 
>> the Swift core team is strong enough so that I cannot believe that this has 
>> a chance of ever being implemented at all :)
>> 
>> Why do I think it's terrible? I do subclass classes even when they say that 
>> you shouldn't do it. I even monkey-patched a few classes in the past. Why? 
>> Not because I prefer hacking over clean coding, but to get the job done. 
>> Every few months or so I encounter a situation where such hacking attempts 
>> are the only feasible way to make something work. Or I use them during 
>> research activities or unofficial "feasibility studies". (If that's not the 
>> case for you, then maybe you are working in a different job than I. Monkey 
>> patching is rarely necessary if you make iPhone apps.) These are situations 
>> where everyone else just says "that's not possible". Yes, you can make that 
>> USB driver class stop spamming the console; yes, you can stop that library 
>> from crashing randomly.
>> 
>> There is so much more to say on this topic. Sealing classes is also bad 
>> because it prevents forms of experimental coding. It doesn't solve a real 
>> problem. How often have I seen bugs where someone subclassed a class that 
>> shouldn't be subclassed? That's so rare. But if all classes are sealed by 
>> default this will lead to far worse problems. When a developer subclasses a 
>> class, he usually has a reason. There already is a `final` keyword in Swift, 
>> and a dev really thinks that a class shouldn't be subclass-able, he can use 
>> it already. And if I subclass it from Objective-C anyways, then maybe I know 
>> what I'm doing?
>> 
>> And I'm not buying this "performance" argument. If you want better 
>> performance, write the hot functions in C or maybe even in assembler. The 
>> dynamic dispatch overhead is not the feature that makes programs bad or 
>> slow. It's quadratic algorithms (e.g. unnecessary nested loops), calling 
>> functions multiple times (e.g. if(a.foo.bar(x[2]) == "joo" || 
>> a.foo.bar(x[2]) == "fooo" || a.foo.bar(x[2]) == nil) { ... }), or just 
>> overly complex code: all of them have more impact than dynamic dispatch. 
>> Even worse for performance is unnecessary IO or using graphics APIs 
>> inefficiently. A good profiler can help a lot with these issues.
>> 
>> Swift should be designed for the real world, not for an ideal world that 
>> does not exist and that will never exist.
> 
> The design intent of much of Swift is to allow "free" coding within a 
> module/file/type while encouraging programmers to think more carefully about 
> their public interfaces.  Module interfaces are the most serious and 
> permanent of these interfaces.  It's in keeping with that for declarations to 
> make only minimal public guarantees and require the programmer to be more 
> explicit about the things they want to allow.
> 
> Your arguments about patchability and performance could be applied to every 
> feature in the language.  They are essentially arguments for a fully-dynamic 
> environment.

see https://en.wikipedia.org/wiki/Straw_man

Most OO languages do not seal seal modules (or the equivalent) by default. 
Forcing developers to add “final” does not seem onerous. If authors do not have 
time to audit their frameworks, the language should not pretend do it for them.


> There's no reason to single out subclassing; for everything you can imagine, 
> one programmer's caution will be another's paternalism.  You're just making 
> the argument here because you're used to a particular way of patching 
> Objective-C code, one which will work regardless of this language decision;

That seems personal.


> but most of the old ObjC techniques (e.g. accessing ivars reflectively) 
> already won't work on Swift code without unsafe operations, and subclassing 
> is a very tiny part of that problem.
> 
> And no, we do not and will not accept that performance-sensitive code can 
> only possibly be written in C or assembly, or that algorithmic performance is 
> the only thing worth worrying about, even for the language implementation.

Could many of the performance advantages of sealing could be gained through 
“whole application” optimization?T he benefits could far exceed what is 
possible with whole module optimization. It would probably be extremely 
difficult and hard to scale, but for packaged, signed applications, it should 
be possible some day.

> 
> John.



> 
> 
> 
>> -Michael
>> 
>>> Am 28.06.2016 um 15:09 schrieb L. Mihalkovic via swift-evolution 
>>> :
>>> 
>>> 
>>> Regards
>>> LM
>>> (From mobile)
 On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution 
  wrote:
 
 Anton 

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Brandon Knope via swift-evolution]

Isn't dynamicType possibly changing soon to a method?

This could look much different

Brandon 

> On Jun 28, 2016, at 4:53 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> On Jun 28, 2016, at 12:11 PM, Dave Abrahams via swift-evolution 
>  wrote:
 I think it would.  It would *really* help if someone would prepare a
 patch that uses both APIs so we could see how the resulting code looks
 in practice. :-)
 
 -- 
 Dave
>>> 
>>> Here you go:
>>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>>> 
>> 
>> Thanks for the proposal, Erica.  It contains some errors that I pointed
>> out in a comment on the Gist.  Care to fix those?
>> 
> 
> public struct MemoryLayout {
> public static var size: Int { return sizeof(T) }
> public static var interval: Int { return strideof(T) }
> public static var alignment: Int { return alignof(T) }
> 
> init(_ : @autoclosure () -> T) {}
> }
> 
> print(MemoryLayout.size) // 8
> print(MemoryLayout.interval) // 8
> print(MemoryLayout.alignment) // 8
> 
> let x = 8
> 
> print(MemoryLayout(x).dynamicType.size) // 8
> print(MemoryLayout(x).dynamicType.interval) // 8
> print(MemoryLayout(x).dynamicType.alignment) // 8
> 
> -- E
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[Andrew Trick via swift-evolution]

> On Jun 28, 2016, at 1:53 PM, Dmitri Gribenko  wrote:
> 
> Hi Andy,
> 
> Everything is clear now, thank you!
> 
> On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick  wrote:
>> Initializing via a typed pointer, in addition to changing the temporal 
>> memory state, also imposes a type on the allocated memory for the entire 
>> lifetime of the memory itself, from allocation to deallocation.
> 
> I see.  Given that UnsafeMutablePoiner.initialize() has this very
> important difference in semantics, did you consider reflecting it in
> the name?  Something like '.bindTypeAndInitialize()' -- but I'm sure a
> better wording is possible.

Yes, I did consider that. I’m still open to it--maybe ‘.typedInitialize(with:). 
But...

(1) It’s awkward. The developer isn’t interested in binding the type at that 
point. It’s just a side effect of the way their unsafe pointer is being used.

(2) It would imply that the ‘.bindAndInitialize' entry point is the only way to 
bind the type of allocated memory. But once you have a typed pointer, it’s easy 
to initialize memory via a simple assignment:
ptrToA[0] = A() // where A is trivial
If ptrToA was in an uninitialized state, then that also binds the type.

Instead, I tried to focus on discouraging the unsafe pointer cast that leads to 
this situation. The important thing is that we have an alternate “safe” API so 
that most developers just don’t need to think about it. 

I think the best way to make this clear is through API comments and code 
examples. There are just a handful of UnsafePointer idioms that will be 
prevalent (Expected use cases) , and as long as people follow normal patterns 
with the proposed API, they’re unlikely to run afoul of the rules.

If the proposed API still isn’t safe enough, and developers are running into 
problems, then that calls for development of a pointer type safety sanitizer.

-Andy


> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-evolution] Collection index complexity and data structures

[Dave Abrahams via swift-evolution]

on Fri Jun 24 2016, David Waite  wrote:

> I noticed that the new Collection index(_:offsetBy:)
> 
> does not define that negative offsets require a
> BidirectionalCollection. 

Looks like a doc bug; it should require n >= 0 as a precondition.
Please file a bug report.

> It also declares that negative offsets must complete in O( | offset |
> ) time. This differs from other methods such as distance(from:to:)
> which
> indicates start <= end if not a BidirectionalCollection

That's also wrong.  Since indices are currently Comparable, we're able
to measure distance no matter which order you pass the indices in, as
long as one is reachable from the other.  However, I am leaning strongly
toward dropping the Comparable requirement.

> This would preclude some data structures from strictly implementing
> the Collection protocol, such as singly-linked lists.

It can work, sort of, if you store an offset in each node, but that is
admittedly not a great answer.  That's one reason we're thinking about
dropping the Comparable requirement.

> Would it be appropriate to indicate instead that
> BidirectionalCollection defines the negative offset behavior and
> negative offset performance constraint?
>
> -DW
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave

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

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

[Adrian Zubarev via swift-evolution]

Laziness of typing out fileprivate on all extension members.

group is exactly what access modifier do right now on extensions.

Current access control on extensions is a mix of the access control from 
classes (enums and struct) and the access control from protocols (which is like 
groups will work). But the result isn’t great when it comes to conformances or 
default implementations. I already showed a few examples where it gets weird.

My opinion the the exact opposite, because I think it won’t be complex that 
way. People were already asking for something similar for declarations to group 
variables by an access modifier and reduce the boiler plate. An extra group 
scope won’t hurt you and it signals in a nice design where all group members 
will have the exact same access modifier.



-- 
Adrian Zubarev
Sent with Airmail

Am 28. Juni 2016 um 22:55:23, Jose Cheyo Jimenez (ch...@masters3d.com) schrieb:

What does ‘lazy’ have to do with anything in this proposal? Im confused. 

I know that your desire is to make it consistent and thus clear but the reality 
is that 
this proposal ( and `group` ) would just make the language complex and really 
confusing. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

[Dave Abrahams via swift-evolution]

on Thu Jun 23 2016, Nate Cook  wrote:

> I like the namespace-based approach to group these protocols together
> and I'm very happy to see some clarification happening in this group
> of protocols. However, I don't think the proposed new names
> communicate what they need to. The names listed in the "Alternatives
> Considered" section do a better job of describing the use and behavior
> of these protocols.
>
> Primarily, the new names read like we're saying that a conforming type
> is a literal, compounding a common existing confusion between literals
> and types that can be initialized with a literal. 

No, it's exactly the opposite, as I keep saying.  Conformance to this
protocol does *not* mean you can initialize the type with a literal.
Proof:

  func f() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
  }

It means an instance of the type can be *written* as a literal:

  func f() -> T {
return 43   // OK
  }

Everybody's confused about the meaning of the protocol, and doesn't like
the proposed names because they imply exactly the actual meaning of the
protocol, which they misunderstand.

-- 
Dave

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

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

[Jose Cheyo Jimenez via swift-evolution]

> On Jun 28, 2016, at 12:40 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> How do private or fileprivate help extensions in general?
> 
https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
 


> Is really laziness a strong argument over consistency and clarity? 
> 
> 

What does ‘lazy’ have to do with anything in this proposal? Im confused. 

I know that your desire is to make it consistent and thus clear but the reality 
is that 
this proposal ( and `group` ) would just make the language complex and really 
confusing. 


> As for your example I’d have a pretty good solution (I can’t say this will be 
> accepted, but the idea is great, at least I think that way. I’d propose for 
> that feature after Swift 3 drops):
> 
> // Use correct consistent access control
> fileprivate extension Int {
>  
> // every member of a nameless group would be `fileprivate`
> fileprivate group {
>  
>func double() -> Int {
>return self*2
>}
> 
>func member1() {}
>func member2() {}
>func member3() {}
>func member4() {}
> }
> }
> A group could do way more than just in this example: 
> https://gist.github.com/DevAndArtist/c74f706febf93452999881335f6ca1f9 
> 
> We’d move the behavior out into its own more powerful feature.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 28. Juni 2016 um 03:14:08, Jose Cheyo Jimenez (ch...@masters3d.com 
> ) schrieb:
> 
>> I would be against removing access modifiers on extensions. I actually don't 
>> see anything wrong with the way extensions work with modifiers right now.  
>> Consistency for consistency's sake is never a good measurement if it is not 
>> addressing a pain point. 
>> 
>> When ever I extend a swift standard type, I always make it "fileprivate" 
>> because I don't want to pollute autocomplete for that type. 
>> 
>> fileprivate extension Int {
>>func double() -> Int {
>>return self*2
>>}
>> }
>> 
>> My understanding is that private / fileprivate was renamed/introduced to 
>> help with extensions. I don't think extensions need anymore complexities. I 
>> would hardly ever use private in swift 3 for example (when it gets 
>> implemented.)
> 
> 
> ___
> 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] [Draft] UnsafeRawPointer API

[Dmitri Gribenko via swift-evolution]

Hi Andy,

Everything is clear now, thank you!

On Tue, Jun 28, 2016 at 1:02 PM, Andrew Trick  wrote:
> Initializing via a typed pointer, in addition to changing the temporal memory 
> state, also imposes a type on the allocated memory for the entire lifetime of 
> the memory itself, from allocation to deallocation.

I see.  Given that UnsafeMutablePoiner.initialize() has this very
important difference in semantics, did you consider reflecting it in
the name?  Something like '.bindTypeAndInitialize()' -- but I'm sure a
better wording is possible.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Erica Sadun via swift-evolution]

On Jun 28, 2016, at 12:11 PM, Dave Abrahams via swift-evolution 
 wrote:
>>> I think it would.  It would *really* help if someone would prepare a
>>> patch that uses both APIs so we could see how the resulting code looks
>>> in practice. :-)
>>> 
>>> -- 
>>> Dave
>> 
>> Here you go:
>> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e
>> > >
> 
> Thanks for the proposal, Erica.  It contains some errors that I pointed
> out in a comment on the Gist.  Care to fix those?
> 

public struct MemoryLayout {
public static var size: Int { return sizeof(T) }
public static var interval: Int { return strideof(T) }
public static var alignment: Int { return alignof(T) }

init(_ : @autoclosure () -> T) {}
}

print(MemoryLayout.size) // 8
print(MemoryLayout.interval) // 8
print(MemoryLayout.alignment) // 8

let x = 8

print(MemoryLayout(x).dynamicType.size) // 8
print(MemoryLayout(x).dynamicType.interval) // 8
print(MemoryLayout(x).dynamicType.alignment) // 8

-- E


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

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

[Jordan Rose via swift-evolution]

Xcode plans are a little beyond the scope of the Swift project, so I can't 
promise that there would be any such autoupdating. If there were such a 
feature, I'd expect it to be in the form of a one-time migration, probably 
triggered along with the Swift 3 migrator…but the IB team might have other 
ideas, or decide they have more important things to finish for this release. So 
I guess the answer is "don't count on it".

Jordan


> On Jun 27, 2016, at 21:56, Charlie Monroe  wrote:
> 
> Do you know how would this affect e.g. XIB files or CoreData models where you 
> have the class name + module? If the class was previously marked @objc and 
> now it would be implicitely @objc(ClassName), would it require all XIB files 
> to be updated, or would the XIB compiler be able to deal with it? If the 
> former, than it's a big no for me.
> 
> I'm not a big fan of a change on any account either, though, since it's 
> absolutely not clear that @objc would have this side-effect.
> 
>> On Jun 27, 2016, at 10:26 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> Hey, all. An engineer at Apple noticed the following behavior:
>> 
>> 1. class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) 
>> runtime name
>> 2. @objc class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) 
>> runtime name
>> 3. @objc(Foo) class Foo: NSObject → exposed to Objective-C, unmangled 
>> runtime name
>> 
>> (and 4. @objc class Foo → illegal, classes must have ObjC heritage to be 
>> @objc.)
>> 
>> They specifically observed that (1) and (2) have the same behavior, and 
>> suggested that maybe (2) should be shorthand for (3).
>> 
>> Pros:
>> - There aren't two ways to spell (1).
>> - Removing the mangling (and module uniquing) from the runtime name is 
>> probably one of the most common uses of @objc on a class.
>> 
>> Cons:
>> - It's a source-breaking change, for all that the "@objc" in (2) is 
>> redundant.
>> - For protocols, (1) and (2) are not equivalent, because @objc isn't 
>> inherited there.
>> - Mangling is used to namespace class names at run time; if you drop that, 
>> the ObjC name should probably have a prefix. (This applies more to 
>> frameworks than apps, though.)
>> 
>> There are probably people who say that last con applies to the generated 
>> header as well: we shouldn't put (1) or (2) into the generated header 
>> because the ObjC name might conflict with another class at compile time. 
>> This is valid, but probably too drastic a change at this point.
>> 
>> So, what does everyone think? I'm leaning towards "no change" because it's a 
>> bit subtle and not a big enough win, but if there's widespread support for 
>> this I'll pull it into a proposal.
>> 
>> Jordan
>> 
>> P.S. This is rdar://problem/22296436  for anyone 
>> else at Apple.
>> ___
>> 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] Remove destructive consumption from Sequence

[Brent Royal-Gordon via swift-evolution]

> This use case seems interesting enough to at least deserve some consideration 
> before we decide to require iterators to have reference semantics.  IMO the 
> fact that `next` is a mutating requirement provides a pretty strong 
> indication of the destructive / consuming semantics of using an iterator.  
> Requiring reference semantics gives up flexibility and I’m not completely 
> convinced it adds clarity (but still keeping an open mind about this).

My feeling is that, except for the trivial case of IndexingIterator and other 
iterators over collections, all iterators *should* need reference semantics. If 
your iterator can offer value semantics, then you should convert it into a 
Collection to gain the benefits of indices. If it can't offer value semantics, 
then you should write it as a class so those reference semantics are obvious. 
This would get rid of the really ugly caveat that's always festered at the 
heart of Iterator:

>>> Obtain each separate iterator from separate calls to the sequence's 
>>> makeIterator() method rather than by copying. Copying an iterator is safe, 
>>> but advancing one copy of an iterator by calling its next() method may 
>>> invalidate other copies of that iterator. for-in loops are safe in this 
>>> regard.

The underlying cause of this requirement is that you can't know whether a given 
iterator is a value type or a reference type. Let's fix that.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] Sealed classes by default

[John McCall via swift-evolution]

> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution 
>  wrote:
> Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in 
> the Swift core team is strong enough so that I cannot believe that this has a 
> chance of ever being implemented at all :)
> 
> Why do I think it's terrible? I do subclass classes even when they say that 
> you shouldn't do it. I even monkey-patched a few classes in the past. Why? 
> Not because I prefer hacking over clean coding, but to get the job done. 
> Every few months or so I encounter a situation where such hacking attempts 
> are the only feasible way to make something work. Or I use them during 
> research activities or unofficial "feasibility studies". (If that's not the 
> case for you, then maybe you are working in a different job than I. Monkey 
> patching is rarely necessary if you make iPhone apps.) These are situations 
> where everyone else just says "that's not possible". Yes, you can make that 
> USB driver class stop spamming the console; yes, you can stop that library 
> from crashing randomly.
> 
> There is so much more to say on this topic. Sealing classes is also bad 
> because it prevents forms of experimental coding. It doesn't solve a real 
> problem. How often have I seen bugs where someone subclassed a class that 
> shouldn't be subclassed? That's so rare. But if all classes are sealed by 
> default this will lead to far worse problems. When a developer subclasses a 
> class, he usually has a reason. There already is a `final` keyword in Swift, 
> and a dev really thinks that a class shouldn't be subclass-able, he can use 
> it already. And if I subclass it from Objective-C anyways, then maybe I know 
> what I'm doing?
> 
> And I'm not buying this "performance" argument. If you want better 
> performance, write the hot functions in C or maybe even in assembler. The 
> dynamic dispatch overhead is not the feature that makes programs bad or slow. 
> It's quadratic algorithms (e.g. unnecessary nested loops), calling functions 
> multiple times (e.g. if(a.foo.bar(x[2]) == "joo" || a.foo.bar(x[2]) == "fooo" 
> || a.foo.bar(x[2]) == nil) { ... }), or just overly complex code: all of them 
> have more impact than dynamic dispatch. Even worse for performance is 
> unnecessary IO or using graphics APIs inefficiently. A good profiler can help 
> a lot with these issues.
> 
> Swift should be designed for the real world, not for an ideal world that does 
> not exist and that will never exist.

The design intent of much of Swift is to allow "free" coding within a 
module/file/type while encouraging programmers to think more carefully about 
their public interfaces.  Module interfaces are the most serious and permanent 
of these interfaces.  It's in keeping with that for declarations to make only 
minimal public guarantees and require the programmer to be more explicit about 
the things they want to allow.

Your arguments about patchability and performance could be applied to every 
feature in the language.  They are essentially arguments for a fully-dynamic 
environment.  There's no reason to single out subclassing; for everything you 
can imagine, one programmer's caution will be another's paternalism.  You're 
just making the argument here because you're used to a particular way of 
patching Objective-C code, one which will work regardless of this language 
decision; but most of the old ObjC techniques (e.g. accessing ivars 
reflectively) already won't work on Swift code without unsafe operations, and 
subclassing is a very tiny part of that problem.

And no, we do not and will not accept that performance-sensitive code can only 
possibly be written in C or assembly, or that algorithmic performance is the 
only thing worth worrying about, even for the language implementation.

John.



> -Michael
> 
>> Am 28.06.2016 um 15:09 schrieb L. Mihalkovic via swift-evolution 
>> :
>> 
>> 
>> Regards
>> LM
>> (From mobile)
>>> On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution 
>>>  wrote:
>>> 
>>> Anton Zhilin: That is one of the points if I’m not mistaken. Sealed
>>> means that with whole-module-optimization the compiler can optimise
>>> more things as it can treat it as final for other modules.
>>> 
>>> L. Mihalkovic: Could you give an example of what exactly do you mean?
>>> I know one of the reasons behind the proposal is to actually improve
>>> those situations by forcing us to think more on customisation when
>>> designing APIs.
>> 
>> In many situation it has been my experience that libraries can be extended 
>> DESPITE their authors, rather than only thanks to the skills the authors  
>> have shown in planning for the future. It is what happened to me with 
>> AlamoFire, where i was able to extend it because some cracks existed which 
>> let me do something the designers did not think about (to me it was a lack 
>> of imagination 

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Austin Zheng via swift-evolution]

Inline

On Mon, Jun 27, 2016 at 6:47 AM, Matthew Johnson 
wrote:

>
>
> Sent from my iPad
>
> On Jun 25, 2016, at 12:41 PM, Austin Zheng  wrote:
>
> I actually think that the delineation between `associatedtype` and
> `typealias` should make this legal, and will change the proposal as such.
> It should be legal to bind an associated type to a type alias, and it
> should be possible to define a type alias that shadows (but does not
> conflict with) an associated type definition. This would fix the issue with
> retroactive modeling.
>
>
> IIUC you're saying a type is allowed to have an `associatedtype` and
> `typealias` (or nested type) both bound to the same name as long as they
> resolve to the same type.  Is that correct?  That would at least preserve
> current expressiveness.
>

Yes, that is exactly correct :).

I actually have an alternative (see the last sub-entry in the alternative
section) that would relax even that restriction. This would actually make
the language slightly more expressive, since you would _theoretically_ be
able to get around the typealias or nested type aliasing issues that exist
today. I argued a bit against it but it's there in case the core team
disagrees.


>
>
>
> // Module A
> public struct S {
> public typealias Foo = Int
> }
>
> // Module B
> public protocol P {
> associatedtype Foo
> }
>
> // Module C
> import A
> import B
>
> // compiler error: `S` does not meet the `Foo` associatedtype requirement
> extension S : P {
> // compiler error: cannot define associatedtype `Foo` for `S` which
> already declares typealias `Foo`
> associatedtype Foo = String
> }
>
> I cannot support any proposal that breaks retroactive modeling in this way.
>
>
> Addendum aside, retroactive modeling is already suboptimal or broken in
> multiple ways today - try conforming a protocol with associated type
> 'Element' to a different protocol whose 'Element' means something
> completely different.
>
>
> Did you mean conforming a type to two protocols with an 'Element'
> associatedtype?
>
> I consider that issue to be in the realm of multiple conformances rather
> than retroactive modeling.  I can still
>

Yeah, I completely mangled that sentence.

I think it does fall into the realm of retroactive modeling, since an
existing type may be prevented from being retroactively conformed to a new
protocol by an existing conformance that it has.


>
>
> Thank you for adding the clarifications.  I feel a little better knowing
> we wouldn't lose expressive power, but still prefer the directed inference
> suggested by Dmitri.
>
>
And thank you for your honest feedback!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Xiaodi Wu via swift-evolution]

Yes. See earlier in the discussion about the Unicode confusables list. The
security issues that arise from confusable URLs aren't the same as those
for identifiers in Swift, and I think the short version of the previous
discussion is that prohibiting the use of Greek nu and mathematical bold
italic v, for instance, isn't necessary for security.

Thus, we're working off of a different Unicode recommendation specifically
drawn up for identifier normalization, which does not involve forbidding
confusables.

On Tue, Jun 28, 2016 at 14:43 Russ Bishop via swift-evolution <
swift-evolution@swift.org> wrote:

> Doesn't Unicode have a standard for this that specified which characters
> are look-alikes?
>
> Russ
>
> > On Jun 21, 2016, at 7:48 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote:
> >>
> >>> On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution
> >>>  wrote:
> >>>
>  Perhaps stupid but: why was Swift designed to accept most Unicode
>  characters in identifier names? Wouldn’t it be simpler to go back to
>  a model where only standard ascii characters are accepted in
>  identifier names?
> >>>
> >>> I assume it has something to do with the fact that 94.6% of the
> >>> world's population speak a first language which is not English. That
> >>> outweighs the inconvenience for Anglo developers, IMHO.
> >>
> >> Yes, but the SDKs (frameworks, system libraries) are all in English,
> >> including Swift standard library. I remember a few languages attempting
> >> localized versions for kids to study better, failing terribly because
> >> you learned something that had a very very limited use.
> >
> > Support Charlie's opinion. For me (as non-native English speaker)
> non-ASCII characters in identifiers had no sense, even when I start to tech
> the programming when I was a child. Expressions composed from identifiers
> written in my native language is not near correct sentences.
> >
> > Even more, we still have all other parts of language in English -
> for-while-guard-let-var-func etc..
> >
> >>
> >> When it comes to maintaining code, using localized identifier names is a
> >> bad practice since anyone outside that country coming to the code can't
> >> really use it. I personally can't imagine coming to maintain Swift code
> >> with identifiers in Chinese, Japanese, Arabic, ...
> >>
> >> While the feature of non-ASCII characters being allowed as identifiers
> >> (which was held up high with Apple giving emoji examples) may seem cool,
> >> I can only see this helpful in the future, given a different keyboard
> >> layout (as someone has pointed out some time ago here), to introduce
> >> one-character operators that would be otherwise impossible. But if
> >> someone came to me with a code where a variable would be an emoji of a
> >> dog, he'd get fired on the spot.
> >
> > Yes, but I don't believe Apple will accept limiting of character set for
> identifiers to ASCII *after* these presentations with emoji of a dog ;-)
> >
> >>
> >> I'd personally vote to keep the zero-width-joiner characters forbidden
> >> within the code outside of string literals (where they may make sense).
> >> I agree that this can be easily solved by linters, but: I think this
> >> particular set of characters should be restricted by the language
> >> itself, since it's something easily omittable during code review and
> >> given the upcoming package manager, this can lead to a hard-to-find
> >> malware being distributed among developers who include these packages
> >> within their projects - since you usually do not run a linter on a 3rd
> >> party code.
> >
> > I also think the main problem that could be caused by such tricks with
> zero-width-joiner or right-to-left-markers is injecting some malware code
> into sources in github, in package manager *or* even just in  code snippet
> on web page(so you copy-pasted it to your source). Right now I don't know
> exact method to implement such malware code, but I believe this
> vulnerability could be used some day.
> >
> > Btw, regarding the package manager. Will we have any protection from
> Typosquatting ?
> http://incolumitas.com/2016/06/08/typosquatting-package-managers/#typosquatting-package-managers
> >
> >>
> >> As for the confusables - this depends a lot on the rendering and what
> >> font you have set. I've tried  훎 → v with current Xcode and it looks
> >> really different, mostly when you use a fixed-space font which usually
> >> doesn't have non-ASCII characters which are then rendered using a
> >> different font, making the distinction easy to spot.
> >
> > In Russian we have these chars :
> > у к е г х а р о с ь
> > which are similar to english:
> > y k e r x a p o c b
> >
> > So you most likely can't differ `рос` and `poc` , `хае` and `xae` etc
> >
> > I don't think compiler should somehow decide if one non-English letter
> is looks 

Re: [swift-evolution] Setter methods for vars

[Michael Peternell via swift-evolution]

So you're proposing that `#set(aVariableName)` should translate to 
`{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue like 
`self.users` or `users` or `vc.viewControllers`..

I think this would be a good extension to Swift. (`users.set` does not work 
BTW, because maybe the `users` object has a `set` property.. maybe I wanted to 
refer to the `set` property which also happens to refer to a closure value.)

`#set(aVariableName)` also feels consistent with the `#keyPath(aVariableName)` 
property and falls into a similar category. Maybe `#setter(aVariableName)` 
would be even more clear? Furthermore, I want to additionally propose to 
introduce `#get(aVariableName)` (or `#getter(aVariableName)`) too.

-Michael

> Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution 
> :
> 
> Proposal:
> 
> I propose adding setter methods to vars, which could look something like 
> this: `ApiClient().fetchUsers().then(#set(users))`
> 
> Initially I thought it should work like this: 
> `ApiClient().fetchUsers().then(users.set)`
> but to accomplish a line of code that flows grammatically, I believe putting 
> "set" where it would naturally fall if the code was being read as a sentence 
> is more Swifty.
> 
> Rationale:
> 
> The following code makes me smile:
> 
> ApiClient().fetchUsers().then(displayUsers)
> 
> It exemplifies the beauty of Swift. First-class functions make this line of 
> code read very well. Consider some alternatives:
> 
> 1. ApiClient().fetchUsers().then { displayUsers($0) }
> 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
> 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }
> 
> Using the lessons learned from Swift API Design Guidelines (WWDC 2016 Session 
> 403) having an emphasis on clarity, my analysis of the alternatives is:
> 
> 1. $0 adds no additional information as to the type or explanation of what 
> the argument is, thus adding nothing to the line of code for clarity, and 
> therefore should be omitted
> 2. adding "users" also adds nothing to the clarity of the code. The function, 
> properly, contains the information necessary to reason about the argument it 
> takes and what it does, and therefore adding "users" is redundant
> 3. Not only is "users" redundant, but also is the explicit type label. The 
> `displayUsers` method will only accept one type of argument, so we're 
> duplicating information that the compiler (and autocomplete) already gives us
> 
> With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is 
> the Swiftiest option.
> I want to extend this same logic to when I find myself writing code like this:
> 
> ApiClient().fetchUsers().then { users in
>   self.users = users
> }
> 
> or alternatively, because "users" is likely redundant information again,
> 
> ApiClient().fetchUsers().then { self.users = $0 }
> 
> Personally I steer clear of `$0` as much as possible, because I very rarely 
> feel that it provides the information necessary for code clarity. But beyond 
> that, this code no longer reads as nicely as the code we had before. 
> 
> Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a 
> sentence and reads grammatically, `ApiClient().fetchUsers().then { self.users 
> = $0 }` no longer does.
> 
> I think this feature could have a simple implementation where the compiler 
> replaces `#set(X)` with `{ X = $0 }`, and I believe it would go a long way 
> with respect to code clarity, especially when X is something longer like 
> `self.view.bounds.origin.x`
> 
> 
> Looking forward to hearing thoughts from the community,
> Austin Feight
> ___
> 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] [Draft] UnsafeRawPointer API

[Andrew Trick via swift-evolution]

> On Jun 27, 2016, at 10:18 PM, Dmitri Gribenko  wrote:
> 
> Hi Andy,
> 
> Thank you for the proposal!  A few comments from me.

Thanks for the feedback (again)! I updated the language in the proposal (again).

> - In the "Custom memory allocation section" you write:
> 
>> Note: The same allocated raw memory cannot be used both for this custom 
>> memory allocation case and for the C buffer case above because the C buffer 
>> requries that the allocated raw memory is always initialized to the same 
>> type.
> 
> Could you provide more explanation?  I'm not quite getting it.  Is
> this because of binding -- are you saying that there is no way to
> un-bind the type?

It now reads:

Note: The same allocated raw memory cannot be used both for this
custom memory allocation case and for the C buffer case above because
the C buffer binds the allocated memory to an element type. Binding
the type applies to the allocation lifetime and requries that the
allocated raw memory is always initialized to the same type.

This should make sense after reading the earlier section on initializing memory 
that I’ve updated as explained below...

> - In the "Accessing uninitialized memory with a typed pointer (binding
> the type)" section you write
> 
>> This cast explicitly signals the intention to bind the raw memory to the 
>> destination type.
> 
> I think that "signals the intention" is not a strong enough wording,
> it is open to interpretations.  Either it is a no-op "intention" (that
> can be retracted) or it is the actual binding.  From other discussions
> in this thread, I think you are proposing that the .toType() method
> actually binds the memory to a type.  Is this right?  Here's what made
> me think this way:
> 
>> The following code is undefined:
>> ```
>> ptrA = rawPtr.cast(to: UnsafePointer.self)
>> ptrA.initialize(with: A())
>> ptrA.deinitialize()
>> ptrB = rawPtr.cast(to: UnsafePointer.self)
>> ptrB.initialize(with: B())
>> ```
>> It is hard to spot the difference between the two styles without drawing 
>> attention to the unsafe cast.
> 
> - In the same section, in the table, it is not clear whether the
> "tptr.deinitialize" operation un-binds the memory type, or does not
> have effect on it.  Which way is it?  Can I replace
> "tptr.initialize(t2: T)" with "tptr.initialize(u1: U)”?

I reworded this section:

https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#initializing-memory-with-a-typed-pointer-binding-the-type

The simple rule is: if you use a typed pointer to initialize memory, that 
memory is bound for the duration of its lifetime. The semantics are not 
temporal.

I think that's very clear in the proposal now.

To fully answer your question “can memory be unbound", technically if you 
reinitialize the memory using a raw pointer, then accesses on either side of 
that initialization point are protected from strict aliasing guarantees. But 
that's just a confusing and mostly useless artifact of the implementation. 
That's not the memory model as it as specified in the proposal. So forget I 
said that.

> - Is it valid to access an ARC reference to a class MyClass that
> conforms to MyProtocol with aliasing pointers,
> UnsafeMutablePointer, UnsafeMutablePointer, and
> 'UnsafeMutablePointer' ?  What about
> 'UnsafeMutablePointer’ ?

That's discussed in the "Type Safe Memory Access" documentation. I wrote this 
doc for the sake of discussion, but it’s a little out of date and needs to be 
updated before putting it up for review again:

https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst

There are two aspects of the type to consider: whether they are related for the 
purpose of strict aliasing, and whether they are mutually layout compatible.

MyClass and MyProtocol are related, so there's no problem with aliasing. If 
MyProtocol is an AnyObject existential, then they also have the same 
representation (layout), so it's safe. If MyProtocol is not class constrained, 
then they are not layout compatible.

Regarding AnyObject and AnyObject?:

They are related because "one type may be a tuple, enum, or struct that 
contains the other type as part of its own storage"

They are mutually layout compatible because we know per the ABI that Optional 
class types have the same representation as class types. It's a bit of a 
special case. In general, fragile enums with single payloads have some layout 
guarantees. You can read the payload from the enum type, but can't read the 
enum from the payload type.

Layout compatible also pertains to the location of references within the type 
(they need to be ARC-compatible). I have not adequately explained that in the 
doc but have it on my TODO list.

> - There's no API to convert from UnsafeMutableRawPointer to
> UnsafeMutablePointer without either doing an initialization, or
> binding the type.  Is this on purpose?  The reason why I'm asking is
> that initialization 

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Russ Bishop via swift-evolution]

Doesn't Unicode have a standard for this that specified which characters are 
look-alikes?

Russ

> On Jun 21, 2016, at 7:48 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> 
>> On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote:
>> 
>>> On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution
>>>  wrote:
>>> 
 Perhaps stupid but: why was Swift designed to accept most Unicode
 characters in identifier names? Wouldn’t it be simpler to go back to
 a model where only standard ascii characters are accepted in
 identifier names?
>>> 
>>> I assume it has something to do with the fact that 94.6% of the
>>> world's population speak a first language which is not English. That
>>> outweighs the inconvenience for Anglo developers, IMHO.
>> 
>> Yes, but the SDKs (frameworks, system libraries) are all in English,
>> including Swift standard library. I remember a few languages attempting
>> localized versions for kids to study better, failing terribly because
>> you learned something that had a very very limited use.
> 
> Support Charlie's opinion. For me (as non-native English speaker) non-ASCII 
> characters in identifiers had no sense, even when I start to tech the 
> programming when I was a child. Expressions composed from identifiers written 
> in my native language is not near correct sentences.
> 
> Even more, we still have all other parts of language in English - 
> for-while-guard-let-var-func etc..
> 
>> 
>> When it comes to maintaining code, using localized identifier names is a
>> bad practice since anyone outside that country coming to the code can't
>> really use it. I personally can't imagine coming to maintain Swift code
>> with identifiers in Chinese, Japanese, Arabic, ...
>> 
>> While the feature of non-ASCII characters being allowed as identifiers
>> (which was held up high with Apple giving emoji examples) may seem cool,
>> I can only see this helpful in the future, given a different keyboard
>> layout (as someone has pointed out some time ago here), to introduce
>> one-character operators that would be otherwise impossible. But if
>> someone came to me with a code where a variable would be an emoji of a
>> dog, he'd get fired on the spot.
> 
> Yes, but I don't believe Apple will accept limiting of character set for 
> identifiers to ASCII *after* these presentations with emoji of a dog ;-)
> 
>> 
>> I'd personally vote to keep the zero-width-joiner characters forbidden
>> within the code outside of string literals (where they may make sense).
>> I agree that this can be easily solved by linters, but: I think this
>> particular set of characters should be restricted by the language
>> itself, since it's something easily omittable during code review and
>> given the upcoming package manager, this can lead to a hard-to-find
>> malware being distributed among developers who include these packages
>> within their projects - since you usually do not run a linter on a 3rd
>> party code.
> 
> I also think the main problem that could be caused by such tricks with 
> zero-width-joiner or right-to-left-markers is injecting some malware code 
> into sources in github, in package manager *or* even just in  code snippet on 
> web page(so you copy-pasted it to your source). Right now I don't know exact 
> method to implement such malware code, but I believe this vulnerability could 
> be used some day.
> 
> Btw, regarding the package manager. Will we have any protection from 
> Typosquatting ? 
> http://incolumitas.com/2016/06/08/typosquatting-package-managers/#typosquatting-package-managers
> 
>> 
>> As for the confusables - this depends a lot on the rendering and what
>> font you have set. I've tried  훎 → v with current Xcode and it looks
>> really different, mostly when you use a fixed-space font which usually
>> doesn't have non-ASCII characters which are then rendered using a
>> different font, making the distinction easy to spot.
> 
> In Russian we have these chars :
> у к е г х а р о с ь
> which are similar to english:
> y k e r x a p o c b
> 
> So you most likely can't differ `рос` and `poc` , `хае` and `xae` etc
> 
> I don't think compiler should somehow decide if one non-English letter is 
> looks like another English letter. But don't see any other method to protect 
> myself other than using lints/checking tools for 3rd party code also.
> 
>> 
>>> 
>>> Honestly, this seems to me like a concern for linters and security
>>> auditing tools, not for the compiler. Swift identifiers are
>>> case-sensitive; I see no reason they shouldn't be script-sensitive or
>>> zero-width-joiner-sensitive. (Though basic Unicode normalization seems
>>> like a good idea, since differently-normalized strings are `==`
>>> anyway.)
>>> 
>>> -- Brent Royal-Gordon Architechies
>>> 
>>> ___ swift-evolution
>>> mailing list swift-evolution@swift.org
>>> 

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

[Matthew Johnson via swift-evolution]

> On Jun 28, 2016, at 2:18 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> One more question on this.
> 
> How would we handle the opt-out safety for people who are intentionally 
> trying to create an infinite loop?
> 
> I don’t think we can make .until() safely lazy for iterators which have 
> reference semantics and are destructive single-pass, so it has to be eager.  
> If .until() is eager, then .until(false) will fall into an infinite loop 
> before the for-in loop is even run.  

This is an argument against a library solution if iterators have reference 
semantics.  Any solution that requires eager behavior is not a good solution.

> 
> Maybe there just a way to plug an iterator/sequence directly in, and then 
> silence the warning?  or we could do for-in-until…
 
I don’t think this should be a warning that can be silenced.  I think you are 
uncovering good reasons to go with a language supported solution.

This wouldn’t need to happen in Swift 3.  There have been other cases where we 
have adopted a “break it now in anticipation of making it better in the future” 
policy.  If we conclude that a language solution is warranted and can’t get it 
into Swift 3 that is ok IMO.  It is still possible to manually iterate infinite 
sequences.  This wouldn’t be that big a deal given that it is relatively 
infrequent.

> 
> Thanks,
> Jon
> 
>> On Jun 28, 2016, at 10:51 AM, Dave Abrahams > > wrote:
>> 
 
 This is a reasonable structure, but there are important details missing.
 
 1. Presumably these are all for-in-able.  What makes something
  for-in-able?
>>> 
>>> I would think the potentially infinite should require for-in-until
>>> (even if you explicitly set until to false to create an infinite
>>> loop), but collection would allow for-in (with optional until).  That
>>> way you have to acknowledge the possibility of an infinite
>>> sequence/iterator.
>> 
>> Are you proposing a new language feature?  We could also do this with
>> 
>>for i in allIntegers.until(isPrime)
> 
> ___
> 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] Revising access modifiers on extensions

[Adrian Zubarev via swift-evolution]

How do private or fileprivate help extensions in general? Is really laziness a 
strong argument over consistency and clarity?

As for your example I’d have a pretty good solution (I can’t say this will be 
accepted, but the idea is great, at least I think that way. I’d propose for 
that feature after Swift 3 drops):

// Use correct consistent access control
fileprivate extension Int {
 
// every member of a nameless group would be `fileprivate`
fileprivate group {
 
   func double() -> Int {
   return self*2
   }

   func member1() {}
   func member2() {}
   func member3() {}
   func member4() {}
}
}
A group could do way more than just in this example: 
https://gist.github.com/DevAndArtist/c74f706febf93452999881335f6ca1f9

We’d move the behavior out into its own more powerful feature.



-- 
Adrian Zubarev
Sent with Airmail

Am 28. Juni 2016 um 03:14:08, Jose Cheyo Jimenez (ch...@masters3d.com) schrieb:

I would be against removing access modifiers on extensions. I actually don't 
see anything wrong with the way extensions work with modifiers right now.  
Consistency for consistency's sake is never a good measurement if it is not 
addressing a pain point. 

When ever I extend a swift standard type, I always make it "fileprivate" 
because I don't want to pollute autocomplete for that type. 

fileprivate extension Int {
   func double() -> Int {
       return self*2
   }
}

My understanding is that private / fileprivate was renamed/introduced to help 
with extensions. I don't think extensions need anymore complexities. I would 
hardly ever use private in swift 3 for example (when it gets implemented.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Sealed classes by default

[Michael Peternell via swift-evolution]

Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in 
the Swift core team is strong enough so that I cannot believe that this has a 
chance of ever being implemented at all :)

Why do I think it's terrible? I do subclass classes even when they say that you 
shouldn't do it. I even monkey-patched a few classes in the past. Why? Not 
because I prefer hacking over clean coding, but to get the job done. Every few 
months or so I encounter a situation where such hacking attempts are the only 
feasible way to make something work. Or I use them during research activities 
or unofficial "feasibility studies". (If that's not the case for you, then 
maybe you are working in a different job than I. Monkey patching is rarely 
necessary if you make iPhone apps.) These are situations where everyone else 
just says "that's not possible". Yes, you can make that USB driver class stop 
spamming the console; yes, you can stop that library from crashing randomly.

There is so much more to say on this topic. Sealing classes is also bad because 
it prevents forms of experimental coding. It doesn't solve a real problem. How 
often have I seen bugs where someone subclassed a class that shouldn't be 
subclassed? That's so rare. But if all classes are sealed by default this will 
lead to far worse problems. When a developer subclasses a class, he usually has 
a reason. There already is a `final` keyword in Swift, and a dev really thinks 
that a class shouldn't be subclass-able, he can use it already. And if I 
subclass it from Objective-C anyways, then maybe I know what I'm doing?

And I'm not buying this "performance" argument. If you want better performance, 
write the hot functions in C or maybe even in assembler. The dynamic dispatch 
overhead is not the feature that makes programs bad or slow. It's quadratic 
algorithms (e.g. unnecessary nested loops), calling functions multiple times 
(e.g. if(a.foo.bar(x[2]) == "joo" || a.foo.bar(x[2]) == "fooo" || 
a.foo.bar(x[2]) == nil) { ... }), or just overly complex code: all of them have 
more impact than dynamic dispatch. Even worse for performance is unnecessary IO 
or using graphics APIs inefficiently. A good profiler can help a lot with these 
issues.

Swift should be designed for the real world, not for an ideal world that does 
not exist and that will never exist.

-Michael

> Am 28.06.2016 um 15:09 schrieb L. Mihalkovic via swift-evolution 
> :
> 
> 
> Regards
> LM
> (From mobile)
>> On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution 
>>  wrote:
>> 
>> Anton Zhilin: That is one of the points if I’m not mistaken. Sealed
>> means that with whole-module-optimization the compiler can optimise
>> more things as it can treat it as final for other modules.
>> 
>> L. Mihalkovic: Could you give an example of what exactly do you mean?
>> I know one of the reasons behind the proposal is to actually improve
>> those situations by forcing us to think more on customisation when
>> designing APIs.
> 
> In many situation it has been my experience that libraries can be extended 
> DESPITE their authors, rather than only thanks to the skills the authors  
> have shown in planning for the future. It is what happened to me with 
> AlamoFire, where i was able to extend it because some cracks existed which 
> let me do something the designers did not think about (to me it was a lack of 
> imagination to not have anticipated what i wanted to do).
> 
> So if this can happen with a lib made by very experienced/talented 
> developers, then imagine what happens with far less skilled developers.. it 
> will mean having to copy code in order extend. It may sound pessimistic, but 
> if u had seen as much bad code as i have seen, you might understand the view 
> i am sharing.
> 
> What's worse is that objc is not particularly conducive to good software 
> architecture (it is a bit like perl and javascript where anything can be 
> touched from anywhere, and has a limited set of constructs compared to c++, 
> scala, java, c#, swift). So i do not believe that it has prepared objc devs 
> to suddenly become great code designers with a language that has multiples 
> levels of scoping/nesting (i would not use most of the swift libs i have seen 
> on github to teach software design).
> 
> Hence my conclusion that defaulting to sealed may be giving too much credit 
> to the code that is currently available for reuse.
> 
> 
>> 
>> On Tue, Jun 28, 2016 at 12:44 PM, Anton Zhilin via swift-evolution
>>  wrote:
>>> Does `sealed` allow for any optimizations? Maybe somehow devirtualizing
>>> method calls?
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> -- 
>> Alejandro Martinez
>> http://alejandromp.com
>> ___
>> 

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Anton Zhilin via swift-evolution]

I did not change 'precedencegroup', but still strongly vote for 
'precedence', despite counter-arguments.

But there is a problem besides bikeshedding that we need to solve. We have 
the following groups:

Assignment
Ternary
Default
LogicalOr
LogicalAnd
Comparative
NilCoalescing
Cast
Range
Additive
Multiplicative
BitwiseShift

How should we rename them to avoid conflicts?
Simply add -Precedence to everything?
Drop -Precedence for Additive, Multiplicative and Comparative?

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

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

[Jonathan Hull via swift-evolution]

One more question on this.

How would we handle the opt-out safety for people who are intentionally trying 
to create an infinite loop?

I don’t think we can make .until() safely lazy for iterators which have 
reference semantics and are destructive single-pass, so it has to be eager.  If 
.until() is eager, then .until(false) will fall into an infinite loop before 
the for-in loop is even run.  

Maybe there just a way to plug an iterator/sequence directly in, and then 
silence the warning?  or we could do for-in-until...

Thanks,
Jon

> On Jun 28, 2016, at 10:51 AM, Dave Abrahams  wrote:
> 
>>> 
>>> This is a reasonable structure, but there are important details missing.
>>> 
>>> 1. Presumably these are all for-in-able.  What makes something
>>>  for-in-able?
>> 
>> I would think the potentially infinite should require for-in-until
>> (even if you explicitly set until to false to create an infinite
>> loop), but collection would allow for-in (with optional until).  That
>> way you have to acknowledge the possibility of an infinite
>> sequence/iterator.
> 
> Are you proposing a new language feature?  We could also do this with
> 
>for i in allIntegers.until(isPrime)

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

Re: [swift-evolution] [Pitch] Changing the behavior of Subsequences of String Views

[Loïc Lecrenier via swift-evolution]

Hi Dmitri,

Thanks for the quick answer,  I filed a bug here: 
https://bugs.swift.org/browse/SR-1927

(Unfortunately, I don’t think I could write a patch myself)

Loïc

> On Jun 28, 2016, at 7:25 PM, Dmitri Gribenko  wrote:
> 
> On Tue, Jun 28, 2016 at 9:46 AM, Loïc Lecrenier
>  wrote:
>> I think String’s Views should
>> 1. Follow Collection’s documentation by using the same indices for their 
>> subsequences
>> 2. Provide safe, consistent behavior when using a subscript operation with a 
>> past-the-end index
> 
> Hi Loïc,
> 
> These are bugs.  Fixes for these bugs don't need to be approved by
> swift-evolution.  We would appreciate patches for these issues.
> 
> I believe though that the fixes might be non-trivial.  I'd be happy to
> discuss ideas how to fix this and will help review the patches.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

[Jonathan Hull via swift-evolution]

 1. Presumably these are all for-in-able.  What makes something
 for-in-able?
>>> 
>>> I would think the potentially infinite should require for-in-until
>>> (even if you explicitly set until to false to create an infinite
>>> loop), but collection would allow for-in (with optional until).  That
>>> way you have to acknowledge the possibility of an infinite
>>> sequence/iterator.
>> 
>> Are you proposing a new language feature?  
> 
> That was my impression.  It’s an interesting idea.  It wouldn’t guarantee 
> termination but would require developers to consider termination and 
> therefore prevent accidents, which are the concerns I am raising.

Yes, exactly.

>> We could also do this with
>> 
>>   for i in allIntegers.until(isPrime)
> 
> Is `until` lazy or eager here?  I imagine you’re thinking it would be lazy 
> because making it eager would introduce unnecessary allocation.  However, if 
> it’s lazy it is an exception to the explicit laziness Swift has adopted.  
> 
> Wouldn’t it be better to require explicit laziness `allIntegers.lazy.until` 
> if for..in is going to be require finite sequences and we’re going to use a 
> library solution to support infinite sequences?  It’s more verbose but more 
> consistent with how laziness is currently handled.  It also doesn’t privilege 
> any specific operator (which isn’t necessary if we do this in the library).  

Everything with Iterators / Sequences should be lazy (because that is the only 
safe thing).  Collections would most likely still be eager.

In this case, ‘until' is creating a collection (most likely an array), so it 
would be eager.  For an iterator, it would immediately drain and buffer it.  
For a sequence, I guess it is whatever is most efficient.

> If we went with a language solution I imagine it would look something like 
> this:
> 
> for i in allIntegers until i.isPrime && i > 1000 where i.isEven {
>// all even integers < the first prime > 1000
> }
> 
> IIRC the `until` clause has already been discussed as syntactic sugar for 
> early termination.  Its utility wouldn’t be limited to looping over infinite 
> sequences, however it would be *required* when you loop over an infinite 
> sequence.  

Yeah, that is my thought as well.  I would also be ok with Dave’s suggestion as 
long as the path (compiler complain -> Suggest Fix) is the same, so you still 
consider and deal with the infinite case.

I do like the look of the language feature better, of course...

> This sugar wouldn’t have to be introduced in Swift 3.  We could make for..in 
> require finite sequences in Swift 3 and add it later if there is sufficient 
> demand.  In the meantime people could iterate infinite sequences manually and 
> / or we could add library support via lazy operators that select a prefix (if 
> we are willing to live with the fact that in practice termination may depend 
> on arguments to the operator).

Ah, I just saw your point above.  allIntegers.until(isPrime) most likely needs 
to be eager, but that is the opposite of what we want for a for-in loop (it 
could have an early break), so the language feature might be quite a bit more 
efficient, and might actually be worthwhile (especially considering that people 
were already asking for it anyway).  I was indifferent to it, but I like it for 
this case…

Anyway, I am interested to see what they are cooking up for us (It may be much 
better than this)...

Thanks,
Jon

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

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[Douglas Gregor via swift-evolution]

> On Jun 25, 2016, at 12:51 AM, Dmitri Gribenko via swift-evolution 
>  wrote:
> 
> On Fri, Jun 24, 2016 at 10:50 PM, Austin Zheng via swift-evolution
>  wrote:
>> Hello all,
>> 
>> Per Chris Lattner's list of open Swift 3 design topics
>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put
>> together a proposal for removing type inference for associated types.
> 
> Hi Austin,
> 
> Thank you for starting this discussion!  There's one other alternative
> that I mentioned in one of the previous threads on this subject.  The
> idea is to limit the inference so that the sizes and the complexity of
> the problems that the type checker has to solve become tractable with
> a simple algorithm, not a full constrain solver.
> 
> Currently, as far as I understand, the type checker solves for all
> associated types for a protocol conformance in a single giant step,
> during which every decision can affect every other decision.  

That’s correct. It’s limiting that inference to a single conformance, but 
solving for all of the associated type witnesses simultaneously, using educated 
guesses as to which value witnesses will eventually be used (this is unchecked 
and seriously buggy). The fact that it’s only solving for a single 
conformance—e.g., “X : Collection” helps restrict the inference, but it’s also 
somewhat incorrect: why shouldn’t implementing a requirement from 
MutableCollection allow one to infer some associated type witness—say, the 
Index type—for a Collection? IIRC, we have some requirements duplicated in the 
standard library’s protocols simply to push the associated type inference into 
handling these cases.


> My
> suggestion is that we keep associated type inference for the simple
> cases where it is obvious what the user meant.  The author of the
> protocol would be able to identify these simple cases and define how
> exactly the inference should happen.  For example:
> 
> protocol Collection {
>  associatedtype Index
> 
>  @infers(Index)
>  var startIndex: Index
> 
>  // Does not affect associated type inference, types have to match
> with decisions made by other declarations.
>  var endIndex: Index
> 
>  // Does not affect associated type inference.
>  subscript(i: Index) -> Iterator.Element
> 
>  associatedtype Iterator
> 
>  @infers(Iterator)
>  func iterator() -> Iterator
> }
> 
> Under the current system, every declaration in a conforming type that
> matches a requirement that mentions 'Index' can affect the inference.
> That is, 'Index' is inferred from all declarations in the conforming
> type.   But there is no reason to make it that general -- the protocol
> author knows that 'var startIndex' in the conforming type has be of
> the right type, and there is no reason for other declaration to affect
> the decision about what 'Index' is resolved to.  Under the proposed
> rule, there is at most one declaration that the protocol author is
> allowed to designate with @infers, that is allowed to affect the
> inference.  If there is no @infers for a certain associated type, then
> it is never inferred and should always be specified explicitly.

Pragmatically, this approach can reduce associated type inference and its 
associated problems. It might even provide a way for us to stage in the removal 
of type inference for associated types from the language, by removing it from 
the “user-facing” language but leaving it enabled in key standard library 
protocols so we don’t regress too badly, giving us more time to sort out how 
defaulted associated types and type aliases in protocol extensions can fill the 
gap.

However, this doesn’t actually achieve the simplification in the type checker 
that is intended. We would still need to maintain the existing global inference 
algorithm, and while it would (overall) reduce the number of requirements we 
need to consider when inferring associated type witnesses, it’s still a global 
problem because you can still have several possible “startIndex” or 
“iterator()” potential witnesses to consider (e.g., in the type, protocol 
extensions, constrained protocol extensions, and so on; and it gets more 
interesting with conditional conformances). And as soon as you mark that 
subscript with @infers(Index), all of the complexity becomes apparent again.

That brings me to the other point about this: it’s changing the default, but 
nothing would prevent a user from simply marking every requirement with 
@infers(each-associated-type-listed), in which case we’ve not actually fixed 
the problem. 

> 
> This is the basic idea, I'm sure there are corner cases I haven't
> thought about (e.g., how does this interact with constrained
> extension, can we still solve everything with a simple algorithm?)
> But the reason why I'm suggesting this alternative is that I'm
> concerned that in simple cases like inferring the 'Index' and
> 'Iterator' typealiases having to specify them manually is just
> 

Re: [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

[Xiaodi Wu via swift-evolution]

On Tue, Jun 28, 2016 at 12:10 PM, Logan Sease via swift-evolution <
swift-evolution@swift.org> wrote:

> So this particular construct is one that comes from the ruby language.
> In Ruby, you don’t explicitly have to return at all, but rather your last
> statement will always return by default.
> I am NOT advocating this exactly for swift… I get that it could lead to
> errors and confusion.
>
> But here is my logic:
> If the function returns an optional, this basically means that it may not
> return something.


() and nil are not the same.

So then, why require the function to call a return explicitly at the end of
> the function?
> Instead, I believe if we reach the end of the function and a return has
> not been called, we should implicitly return nil… because logically, we are
> not returning anything, so requiring the function to explicitly return
> seems redundant.
>

You are returning nil, which isn't "not returning anything." Notice also
that you must write `return nil` and not just `return`.


>
>
>
> > On Jun 22, 2016, at 5:31 PM, Gwynne Raskind 
> wrote:
> >
> > I thought of this myself at one point, but I looked at a list of other
> languages to see if they did it and, if so, how much it actually improved
> anything.
> >
> > The only language I could find that I have experience in which does this
> outside of closures was Bash shell scripting, and there wasn’t much to
> judge there because return doesn’t even mean the same thing in a shell
> script that it does in most programming languages. Nonetheless, it felt
> weird to me; lack of a return statement has always been for void functions
> ("there’s nothing *to* return").
> >
> > Adding this to Swift would create a lot of confusing cases - if the
> return type is already Optional, can I then write "return" instead of
> "return nil" for places in the control flow that need to return without
> falling off the closing brace? If it isn’t, do I have to make it Optional,
> or will the compiler do that for me? If it does it for me, will it add a
> second level of Optional to the first one? ('cause while "Int??" (for
> example) might have uses, there are almost certainly better ways to express
> it.) Which of these options for behavior will be the least confusing? How
> do I tell the compiler "Don’t do that, warn me/error instead", especially
> when returning Optionals already? If I have to annotate functions I want
> explicit errors for, do I have to effectively put back a different form of
> the very @warn_unused_result attribute we just finally got rid of needing
> for the common case? How does this interact with error handling, especially
> in the presence of closures and "rethrows"? How does this interact with the
> implicit return from closures, and do closures now get the same semantics?
> Does "{}" in function type context now implicitly mean "{ ()->Void? in
> return nil }"? And if so, how can that change be justified given that it
> will change the semantics of many closures (workitems for
> DispatchQueue.async() come to mind) to be effectively wrong? If that isn’t
> the effect, how do you resolve the confusion developers will experience
> when they try to mix the enclosing function’s implicit return with a
> closure’s? What defines a function’s exit point for the purposes of the
> implicit return? The "end" of a function isn’t always where it seems to be.
> Can this be expressed reasonably by SIL in its current form without adding
> considerable extra logic to the compiler? Would this save enough code (a
> single, fairly short line per function) to justify so massive a semantic
> change, especially given that it violates the expectations of almost every
> language Swift typically replaces (C, C++, Objective-C, C#, Java, Perl,
> PHP, Python, Ruby, just to name a few)?
> >
> > Ultimately I don’t feel like this would add anything but confusion to
> the language; couldn’t your example be rewritten as "func toInt(string:
> String?) -> Int? { return string?.intValue }"? Optional chaining would
> usually solve such cases more cleanly in my experience.
> >
> > -- Gwynne Raskind
> >
> >
> >
> >> On Jun 22, 2016, at 14:44, Logan Sease via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I believe Swift should no longer require an explicit return on all
> functions and instead do an implicit nil return if the function reaches the
> end of its control flow and has an optional return type.
> >>
> >> This could be useful to keep code clean and compact, by only having to
> write code for cases that our function handles and just returning nil
> otherwise automatically.
> >>
> >>
> >> Consider:
> >>
> >> func toInt(string : String?) -> Int?
> >> {
> >>  if let s = string
> >>  {
> >>  return s.intValue
> >>  }
> >>
> >>  //Make this return implicitly happen instead of requiring it.
> >>  //return nil
> >> }
> >>
> >>
> >>
> >> This also very much goes along with the implicit return within 

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

[Xiaodi Wu via swift-evolution]

On Tue, Jun 28, 2016 at 1:25 PM, David Hart  wrote:

>
>
> > On 28 Jun 2016, at 13:46, Brent Royal-Gordon 
> wrote:
> >
> > Unlike the other methods, adding additional elements changed the length
> of `suffix(from:)`'s return value. That indicates to me that it is *not* a
> suffix operation at all.
>
> I don't agree with your reasoning here. It *is* an operation that returns
> the suffix (the end of the sequence) but starting from an index. The fact
> that indices index from the start of the array and that the function will
> return an array of a different length depending on the argument does not
> make the result of the operation less of a suffix. It is still returning
> the end of the array.
>

I was in the midst of writing a reply along the same lines, so I figured
I'd add to David's reply here. There are two characteristics I would expect
from a method named "prefix" or "suffix".

First, it should return a subsequence containing zero to count elements.
(By contrast, something named "first" should return nil or one element, but
certainly no more.)

Second, in the case of "prefix", the first element of the subsequence (if
any) should be the first element of the sequence; in the case of "suffix",
the last element of the subsequence (if any) should be the last element of
the sequence.

Now, `suffix(from:)` fulfills both of those expectations. Like David, I do
not understand how you arrive at the interpretation that a "suffix
operation" should be one that returns a fixed number of elements.

Replacing the word "suffix" with square brackets is inferior, IMO, because
at the call site the reader cannot immediately tell that the two
characteristics I named above would hold. First, depending on what is
inside the square brackets, a subscript could return a subsequence or it
could return a single element. Second, depending on what is inside the
square brackets, a subsequence could start or end anywhere. By contrast,
the words "prefix" and "suffix" clearly communicate what sort of
subsequence you'll get back without inspection of the argument.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Setter methods for vars

[Kenny Leung via swift-evolution]

I don’t understand how 

ApiClient().fetchUsers().then(#set(users))

leads to 

ApiClient().fetchUsers().then(displayUsers)

Could you clarify with a more extensive example?
What does the function then() do?

-Kenny


> On Jun 28, 2016, at 11:18 AM, Austin Feight via swift-evolution 
>  wrote:
> 
> Proposal:
> 
> I propose adding setter methods to vars, which could look something like 
> this: `ApiClient().fetchUsers().then(#set(users))`
> 
> Initially I thought it should work like this: 
> `ApiClient().fetchUsers().then(users.set)`
> but to accomplish a line of code that flows grammatically, I believe putting 
> "set" where it would naturally fall if the code was being read as a sentence 
> is more Swifty.
> 
> Rationale:
> 
> The following code makes me smile:
> 
> ApiClient().fetchUsers().then(displayUsers)
> 
> It exemplifies the beauty of Swift. First-class functions make this line of 
> code read very well. Consider some alternatives:
> 
> 1. ApiClient().fetchUsers().then { displayUsers($0) }
> 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
> 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }
> 
> Using the lessons learned from Swift API Design Guidelines (WWDC 2016 Session 
> 403) having an emphasis on clarity, my analysis of the alternatives is:
> 
> 1. $0 adds no additional information as to the type or explanation of what 
> the argument is, thus adding nothing to the line of code for clarity, and 
> therefore should be omitted
> 2. adding "users" also adds nothing to the clarity of the code. The function, 
> properly, contains the information necessary to reason about the argument it 
> takes and what it does, and therefore adding "users" is redundant
> 3. Not only is "users" redundant, but also is the explicit type label. The 
> `displayUsers` method will only accept one type of argument, so we're 
> duplicating information that the compiler (and autocomplete) already gives us
> 
> With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is 
> the Swiftiest option.
> I want to extend this same logic to when I find myself writing code like this:
> 
> ApiClient().fetchUsers().then { users in
>   self.users = users
> }
> 
> or alternatively, because "users" is likely redundant information again,
> 
> ApiClient().fetchUsers().then { self.users = $0 }
> 
> Personally I steer clear of `$0` as much as possible, because I very rarely 
> feel that it provides the information necessary for code clarity. But beyond 
> that, this code no longer reads as nicely as the code we had before. 
> 
> Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a 
> sentence and reads grammatically, `ApiClient().fetchUsers().then { self.users 
> = $0 }` no longer does.
> 
> I think this feature could have a simple implementation where the compiler 
> replaces `#set(X)` with `{ X = $0 }`, and I believe it would go a long way 
> with respect to code clarity, especially when X is something longer like 
> `self.view.bounds.origin.x`
> 
> 
> Looking forward to hearing thoughts from the community,
> Austin Feight
> ___
> 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] Remove type inference for associated types

[Matthew Johnson via swift-evolution]

> On Jun 28, 2016, at 1:25 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Jun 27, 2016, at 12:56 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> on Sat Jun 25 2016, Austin Zheng > > wrote:
>> 
 On Jun 25, 2016, at 6:23 AM, Matthew Johnson > wrote:
 
 Hi Austin,
 
 I’m sorry to say, but this proposal makes me really sad.  I consider
 associated type inference one of the more elegant aspects of Swift.
 It would be very unfortunate to lose it.
>>> 
>>> There are lots of "elegant" things that Swift could do, but has chosen
>>> not to do for pragmatic reasons (e.g. generalized implicit
>>> conversions, type inference that crosses statement boundaries). Given
>>> how terrible the development experience can be right now in the worst
>>> case, I would happily trade off some measure of convenience for better
>>> tooling.
>> 
>> Well, the type checker's inference engine has *always* been kinda
>> unreliable,
> 
> Dave is dramatically understating the pain that this inference has caused. 
> Because this is the only place we do global type inference, it’s put 
> tremendous pressure on the type checker that caused a huge number of bugs, 
> crashes, and outright incomprehensible behavior. I reimplemented the 
> inference of associated type witnesses in April of 2015 
> (https://github.com/apple/swift/commit/126e404fe5bf0be81206f22c83a61f6689d18854
>  
> ,
>  for reference), when the existing implementation unbearable. It got *far* 
> better, but it’s still not global *enough* to actually be predictable, and 
> the legacy of this mis-feature manifests in a number of weird ways (e.g., 
> typealiases in protocol extensions cannot be used to satisfy associated type 
> requirements, weird rules for when a defaulted associated type gets used).
> 
>> and the experience is made much worse by the lack of
>> recursive protocol requirements and the inability to express other
>> constraints that would better guide inference, and by the “underscored
>> protocols” such as _Indexable that are required to work around those
>> limitations.  IMO it's premature to remove this feature before the
>> inference engine is made sane, the generics features are added, and the
>> library is correspondingly cleaned up, because we don't really know what
>> the user experience would be.
> 
> Well, there’s a chicken-and-egg problem. The complexity of this inference is 
> getting in the way of other improvements. For example, inference of 
> associated types for conditional conformances requires that associated type 
> witness deduction consider additional requirements, which is a complexity we 
> would entirely avoid
> 
>> Finally, I am very concerned that there are protocols such as Collection,
>> with many inferrable associated types, and that conforming to these
>> protocols could become *much* uglier.
> 
> That’s the general concern I have as well: how much boilerplate does this 
> add? In many cases, we get some of the associated type witnesses for 
> Collection types for free, and I don’t know to what extent we can emulate 
> that with defaulted associated type requirements and typealiases in protocol 
> extensions.
> 
> That said, I’ll take some minor regressions in this area for the massive 
> simplification that this proposal brings.

Do you have any comments on Dmitri’s suggested alternative?  I would like to 
see that discussed before any proposals are reviewed.  That discussion is 
likely to influence my opinion quite a bit.

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