date:20160713


> On 13 Jul 2016, at 21:04, Pierre Habouzit  wrote:
> 
>> On Jul 13, 2016, at 11:42 AM, Karl via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On 13 Jul 2016, at 19:59, Daniel A. Steffen >> > wrote:
>>> 
>>> I’m confused, that is what we have in the current version (the argument 
>>> label is part of the overall method name): asyncAfter(deadline:) vs 
>>> asyncAfter(wallDeadline:), which is consistent with all the other labels of 
>>> deadline arguments in the API (this isn’t the only method dealing with time)
>>> 
>> 
>> I think this argument labels are superfluous and actually make the meaning 
>> less coherent. “after(when:…)” is not grammatically fluent, which the Swift 
>> API guidelines encourage, and which the standard library has made big steps 
>> towards recently (see especially 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md
>>  
>> ).
>>  By dropping the labels and renaming the function base-names, we make them 
>> more “swifty”, more concise, clear and readable, and can improve safety by 
>> making sure people know which clock they’re using and what semantic meaning 
>> that has. 
> 
> after(when:) is the current state of the overlay but we told you we’re 
> proposing something new, so your argument is not in complete good faith here 
> is it? ;)

Yeah, I know - you’re proposing to rename it, I’m proposing that it should have 
a different type (which would be enabled by a different renaming to the one 
you’re proposing). So I think it’s a fair debate. I gave my opinion on 
“deadline" - the time you specify isn’t actually a deadline, is it? It isn’t 
the latest possible the time the block is allowed to execute; it’s the earliest 
possible time.

Maybe there is a language gap in there, maybe people use “deadline” more 
loosely to mean a general point in time in California, but the dictionary 
agrees that deadline means "the latest time or date by which something should 
be completed”, which is not what I think you mean (maybe I’m wrong, but that’s 
my understanding of what you’ve been saying so far).

> 
>>> we did discuss naming these asyncAt() instead of asyncAfter(), which would 
>>> make it more clear that they take a deadline, but the name felt 
>>> uncomfortably close to async(), and may also lead to the mistaken 
>>> impression that the execution with occur exactly _at_ the deadline (as 
>>> opposed to just the async() to a queue that may be full of other items 
>>> already and take a while to drain, or be suspended and never execute at all)
>>> 
>> 
>> I’m not sure it’s really necessary to include the word “async” in there — 
>> it’s pretty clear from the fact that they take a time that they’re not going 
>> to block.
>> 
>> The problem with “deadline” is that it’s just not a deadline. It’s an 
>> aspirational fire time, and Dispatch should execute the block as soon as 
>> possible after that time. I can’t really think of a concise word for it, but 
>> “deadline” does not express what you’re talking about. Deadline implies that 
>> the block can execute any time _before_ the specified time.
>> 
>> So that’s where I get “at” from; if your app is asleep, it isn’t possible to 
>> execute exactly at the specified time for reasons outside of your control. 
>> If it executes as soon as possible after waking, I would still consider it 
>> to be firing “at” the correct time (in a loose sort of way). If we were 
>> talking about the dispatch queue as a person, and I asked him/her to do 
>> something at a particular time, but they were delayed due to circumstances 
>> outside of anybody's control (like a natural disaster or a traffic 
>> accident), I’d still consider that they did it “at” the correct time, again 
>> in a loose sense - to the best that they can control it, in other words.
> 
> I strongly disagree that the two forms should be named differently, it’s even 
> more confusing that if you use after() you get one clock and at() the other. 
> Also when we will add a 3rd clock to dispatch, it just stops working 
> completely (look at clock_gettime() that was finally added to macOS, it has 3 
> interesting clocks: MONOTONIC, UPTIME, and WALLTIME that posix calls REALTIME 
> for some weird reason).
> 
> the functions should exactly differ with the argument tag to show that they 
> basically perform the same task with a slight difference that is the clock 
> you’re using. It’s concise, unambiguous, and regular with the other functions 
> in the Dispatch module that handle time. Which in my opinion goes exactly in 
> the direction of SE-0118.
> 

Didn’t we agree earlier that the clock type is not a minor distinction? And 
that there are rather large differences about when the block might fire 
depending on

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

An even better explanation of my suggestion: instead of *sealing* T.Type, I
suggest to *rename* it to Type, formally turning it into a struct, and
then add size and align properties to it.
And regardless of how you interpret it, I suggest to remove .Type notation.

> In Swift, only class instances and metatypes have unique identities.
There is no notion of identity for structs, enums, functions, or tuples.
So Type will lose identity. That's fine. They will contain unique
integer identifiers (assigned to types during compilation) to do its work.

> There is no special compiler magic needed
Maybe. At least, this behaviour will be needed in construction from type
literals:

func foo(_ x: Type)
foo(DerivedClass)  // ok
foo(Int)   // compilation error

With Type, I can see reflection coming! For example, Type can have
the following property (although we shouldn't right now):

var fields: [String: (Type, (T) -> Any)] { get }

I suggest you to prepare a formal proposal, or I will try tomorrow. I would
take the direction on removal of T.Type notation.

2016-07-13 22:48 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:

> Okay I get it now. You meant the size for a metatype sizeof(T.Type.self).
> This is indeed 8 bytes, at least not for optimized Bool (as you showed).
>
> Internally, Type contains an Int, i.e. identifier of a type. For every
> type, compiler must choose a different identifier
>
> We can already implement this with Hashable protocol.
>
> ObjectIdentifier: A unique identifier for a class instance or metatype.
>
> In Swift, only class instances and metatypes have unique identities. There
> is no notion of identity for structs, enums, functions, or tuples.
>
> // version 1:
> public let hashValue: Int = ObjectIdentifier(T.self).hashValue
>
> // version 2 (uses ObjectIdentifier calculation without
> // constructing an instance of ObjectIdentifier):
>
> init() {
> // calculate the hashValue only once
> // I'd rename `.self` to `.metatype`
>
> let rawPointerMetatype = unsafeBitCast(T.self, to: 
> Builtin.RawPointer.self)
> self.hashValue = Int(Builtin.ptrtoint_Word(rawPointerMetatype))
> }
>
> public let hashValue: Int
>
> API of Type is defined so that it can only contain identifiers of
> subtypes of T
>
> For example, when you get a variable of Type, it can correspond to
> BaseClass or DerivedClass
>
> I did a quick test and I feel like this falls under the part of tweaking
> dynamic casts to work with Type. There is no special compiler magic
> needed, unsafeBitCast should do the trick. Or we should teach dynamic
> casts to work with the inner type T instead of the whole Type.
>
> public struct Type : Hashable {
>
> public let metatype: T.Type = T.self
>
> public let hashValue: Int = ObjectIdentifier(T.self).hashValue
> }
>
> public func ==(lhs: Type, rhs: Type) -> Bool {
>
> return lhs.hashValue == rhs.hashValue
> }
>
> public func asOptionalCast(type: Type) -> Type? {
>
> guard (type.metatype as? U.Type) != nil else {
> return nil
> }
> return unsafeBitCast(type, to: Type.self)
> }
>
> class A {}
> class B: A {}
>
> let typeB = Type()
>
> // downcast Type to Type
> let downcast: Type? = asOptionalCast(type: typeB)
>
> (downcast! == typeB) == true
>
> // cast Type (which here is Type) back to Type
> let upcast: Type? = asOptionalCast(type: downcast!)
>
> (upcast! == Type()) == true
>
> The good part here that the hash value of the casted type won’t change and
> testing against a new instance of the same dynamic type will be always true.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 13. Juli 2016 um 20:31:22, Anton Zhilin (antonyzhi...@gmail.com)
> schrieb:
>
> 2016-07-13 20:19 GMT+03:00 Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>:
>>
>> Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@gmail.com)
>> schrieb:
>>
>> I see model of Type as follows:
>>
>>1. Values of Type are identifiers of types (8 bytes, I guess)
>>2. All used identifiers are contained in Type
>>3. Type contains a subset of those identifiers
>>
>> I can’t follow your though here. Is this a totally new behavior?
>>
> That's how it works right now:
>
> sizeofValue(Bool.self)  //=> 0 (optimized away)
> sizeofValue(Bool.self as Any.self)  //=> 8
>
> I'll put my thoughts another way:
>
>- Internally, Type contains an Int, i.e. identifer of a type. For
>every type, compiler must choose a different identifier
>- API of Type is defined so that it can only contain identifiers of
>subtypes of T
>- For example, when you get a variable of Type, it can
>correspond to BaseClass or DerivedClass
>
>
>>1. Upcasting uses constructor init(upcasting: Type)
>>
>> It does look neat but I can’t implement it. At least I have no clue how
>> to solve the problem that `T` is not a protocol or a class type.
>>
> We should add implicit convertion of Type to Type, dulicating
> current

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 Thread Adrian Zubarev via swift-evolution

Okay I get it now. You meant the size for a metatype sizeof(T.Type.self). This 
is indeed 8 bytes, at least not for optimized Bool (as you showed).

Internally, Type contains an Int, i.e. identifier of a type. For every type, 
compiler must choose a different identifier
We can already implement this with Hashable protocol.

ObjectIdentifier: A unique identifier for a class instance or metatype.

In Swift, only class instances and metatypes have unique identities. There is 
no notion of identity for structs, enums, functions, or tuples.
// version 1:
public let hashValue: Int = ObjectIdentifier(T.self).hashValue

// version 2 (uses ObjectIdentifier calculation without  
// constructing an instance of ObjectIdentifier):

init() {
// calculate the hashValue only once
// I'd rename `.self` to `.metatype`
 
let rawPointerMetatype = unsafeBitCast(T.self, to: Builtin.RawPointer.self)
self.hashValue = Int(Builtin.ptrtoint_Word(rawPointerMetatype))
}

public let hashValue: Int
API of Type is defined so that it can only contain identifiers of subtypes of T

For example, when you get a variable of Type, it can correspond to BaseClass or 
DerivedClass
I did a quick test and I feel like this falls under the part of tweaking 
dynamic casts to work with Type. There is no special compiler magic needed, 
unsafeBitCast should do the trick. Or we should teach dynamic casts to work 
with the inner type T instead of the whole Type.

public struct Type : Hashable {
 
public let metatype: T.Type = T.self

public let hashValue: Int = ObjectIdentifier(T.self).hashValue
}

public func ==(lhs: Type, rhs: Type) -> Bool {
 
return lhs.hashValue == rhs.hashValue
}

public func asOptionalCast(type: Type) -> Type? {
 
guard (type.metatype as? U.Type) != nil else {
return nil
}
return unsafeBitCast(type, to: Type.self)
}

class A {}
class B: A {}

let typeB = Type()

// downcast Type to Type
let downcast: Type? = asOptionalCast(type: typeB)

(downcast! == typeB) == true

// cast Type (which here is Type) back to Type
let upcast: Type? = asOptionalCast(type: downcast!)

(upcast! == Type()) == true
The good part here that the hash value of the casted type won’t change and 
testing against a new instance of the same dynamic type will be always true.



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 20:31:22, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

2016-07-13 20:19 GMT+03:00 Adrian Zubarev via swift-evolution 
:
Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

I see model of Type as follows:
Values of Type are identifiers of types (8 bytes, I guess)
All used identifiers are contained in Type
Type contains a subset of those identifiers
I can’t follow your though here. Is this a totally new behavior?

That's how it works right now:

sizeofValue(Bool.self)              //=> 0 (optimized away)
sizeofValue(Bool.self as Any.self)  //=> 8

I'll put my thoughts another way:
Internally, Type contains an Int, i.e. identifer of a type. For every type, 
compiler must choose a different identifier
API of Type is defined so that it can only contain identifiers of subtypes 
of T
For example, when you get a variable of Type, it can correspond to 
BaseClass or DerivedClass
Upcasting uses constructor init(upcasting: Type)
It does look neat but I can’t implement it. At least I have no clue how to 
solve the problem that `T` is not a protocol or a class type.

We should add implicit convertion of Type to Type, dulicating current 
behaviour of `as T.Type`.
That constructor still can be useful, but it will be failable and not that 
significant in practise.
I don't like adding compiler magic, but I guess we really should in this case, 
because otherwise Type can't replace T.Type.
Size of Type is 8, static size of Type is 0
I feel like you mean something different here than this:

```swift

protocol SomeProtocol {}

sizeof(SomeProtocol.self) == 40
```

That was a mistake. Static size of Type will be 40, and size 
property of its values can be less or greater than 40, depending on internal 
type identifier.

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

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

2016-07-13 Thread Pierre Habouzit via swift-evolution

> On Jul 13, 2016, at 11:42 AM, Karl via swift-evolution 
>  wrote:
> 
>> 
>> On 13 Jul 2016, at 19:59, Daniel A. Steffen > > wrote:
>> 
>> I’m confused, that is what we have in the current version (the argument 
>> label is part of the overall method name): asyncAfter(deadline:) vs 
>> asyncAfter(wallDeadline:), which is consistent with all the other labels of 
>> deadline arguments in the API (this isn’t the only method dealing with time)
>> 
> 
> I think this argument labels are superfluous and actually make the meaning 
> less coherent. “after(when:…)” is not grammatically fluent, which the Swift 
> API guidelines encourage, and which the standard library has made big steps 
> towards recently (see especially 
> https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md
>  
> ).
>  By dropping the labels and renaming the function base-names, we make them 
> more “swifty”, more concise, clear and readable, and can improve safety by 
> making sure people know which clock they’re using and what semantic meaning 
> that has. 

after(when:) is the current state of the overlay but we told you we’re 
proposing something new, so your argument is not in complete good faith here is 
it? ;)

>> we did discuss naming these asyncAt() instead of asyncAfter(), which would 
>> make it more clear that they take a deadline, but the name felt 
>> uncomfortably close to async(), and may also lead to the mistaken impression 
>> that the execution with occur exactly _at_ the deadline (as opposed to just 
>> the async() to a queue that may be full of other items already and take a 
>> while to drain, or be suspended and never execute at all)
>> 
> 
> I’m not sure it’s really necessary to include the word “async” in there — 
> it’s pretty clear from the fact that they take a time that they’re not going 
> to block.
> 
> The problem with “deadline” is that it’s just not a deadline. It’s an 
> aspirational fire time, and Dispatch should execute the block as soon as 
> possible after that time. I can’t really think of a concise word for it, but 
> “deadline” does not express what you’re talking about. Deadline implies that 
> the block can execute any time _before_ the specified time.
> 
> So that’s where I get “at” from; if your app is asleep, it isn’t possible to 
> execute exactly at the specified time for reasons outside of your control. If 
> it executes as soon as possible after waking, I would still consider it to be 
> firing “at” the correct time (in a loose sort of way). If we were talking 
> about the dispatch queue as a person, and I asked him/her to do something at 
> a particular time, but they were delayed due to circumstances outside of 
> anybody's control (like a natural disaster or a traffic accident), I’d still 
> consider that they did it “at” the correct time, again in a loose sense - to 
> the best that they can control it, in other words.

I strongly disagree that the two forms should be named differently, it’s even 
more confusing that if you use after() you get one clock and at() the other. 
Also when we will add a 3rd clock to dispatch, it just stops working completely 
(look at clock_gettime() that was finally added to macOS, it has 3 interesting 
clocks: MONOTONIC, UPTIME, and WALLTIME that posix calls REALTIME for some 
weird reason).

the functions should exactly differ with the argument tag to show that they 
basically perform the same task with a slight difference that is the clock 
you’re using. It’s concise, unambiguous, and regular with the other functions 
in the Dispatch module that handle time. Which in my opinion goes exactly in 
the direction of SE-0118.

 So, what’s the sensible default you had in mind that won’t fail for a 
 large portion of use cases?  Safety is an important design point in an API 
 surface and making these distinctions clear to developers is absolutely 
 critical to achieving that goal.
>>> 
>>> The default clock depends on the context of what you’re doing. If I’m using 
>>> DispatchQueue.after, I would say the monotonic clock is a reasonable 
>>> default. Typically you’re going to be scheduling short fire-once things 
>>> like performing an animation after a second or two (at the most). In that 
>>> case, system sleep isn’t an issue - even on iOS where the user can lock the 
>>> screen at any moment; your long-running alarm that crosses sleep events 
>>> will still fire, it just won’t fire *immediately* upon wake. 
>> 
>> Nothing in the API says it must be used only for "short fire-once things"
>> 
>> The problem with the monotonic clock isn’t about firing at wake, but about 
>> pushing the fire time out by the amount of time asleep.
>> If you are using this to implement e.g. a calendaring meeting reminder 
>> alarms, you are not

Re: [swift-evolution] [Pitch] Giving functions default return values

On Wed, Jul 13, 2016 at 1:14 PM, Tim Vermeulen via swift-evolution <
swift-evolution@swift.org> wrote:

> I thought that was mainly about former proposals in the Github repo, but
> I’ll gladly bring this up again at a more appropriate time.
>
> To address your message: I wouldn’t really want guard  else { }
> to be valid code. The default return value is simply returned if the end of
> the function body is reached and nothing has been returned yet. guard
>  else { return } could possibly be allowed in case of a default
> return value, but definitely not an empty guard body. This wouldn’t cause
> any problems, would it?
>

This specific idea you're proposing has been brought up on the list
previously, I think maybe twice. Visual Basic was mentioned previously, in
case that would help you search through list archives. It has not been
previously received well, but if after looking through the archives you
feel it's still relevant to discuss, I'd also mention that post-Swift 3
would be more appropriate.


> On 13 Jul 2016, at 17:47, Charlie Monroe 
> wrote:
>
> Hi Tim,
>
> the core team asked us to defer any discussion on post-Swift-3 related
> proposals.
>
> That said, there have been several discussion around this topic (in the
> past few months) and I believe the general attitude towards them was
> negative, due to it leading to statements such as
>
> guard  else { }
>
> which
>
> a) doesn't express what will happen when the condition is not met, making
> the code hard to read
>
> b) can lead to bugs in code since the compiler makes sure that the flow
> doesn't continue beyond the guard statement and with default returns, this
> would compiler without a warning or an error:
>
> for obj in array {
> guard obj.meetsConditions() else {
> // Implicit return - most likely not intentional,
> // you most likely want "continue" in here
> }
>
> // ...
> }
>
>
> On Jul 13, 2016, at 4:57 PM, Tim Vermeulen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This idea is purely additive and isn’t to be considered for Swift 3.
>
> Oftentimes a function has a very obvious default argument to fall back on.
> If the return value is optional, this is generally nil. If the return value
> is Bool, it’s probably `false`. Often this fallback value is returned at
> the end of the function, just to return something if nothing has been
> returned yet. For instance, consider this TreeNode class:
>
> class TreeNode {
>
> var value: Element
> var children: [TreeNode]
>
> init(value: Element) {
> self.value = value
> children = []
> }
>
> func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool
> {
> if try predicate(value) {
> return true
> }
>
> for child in children {
> if try child.contains(predicate) {
> return true
> }
> }
>
> return false // 1
> }
>
> func first(where predicate: (Element) throws -> Bool) rethrows ->
> Element? {
> if try predicate(value) {
> return value
> }
>
> for child in children {
> if let result = try child.first(where: predicate) {
> return result
> }
> }
>
> return nil // 2
> }
>
> var leftMostDescendant: TreeNode? {
> if let child = children.first {
> return child.leftMostDescendant ?? child
> }
>
> return nil // 3
> }
>
> }
>
> These code patterns are quite usual. If we could give default return
> values to functions, we could get rid of the final `return` statements:
>
> func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool =
> false {
> if try predicate(value) {
> return true
> }
>
> for child in children {
> if try child.contains(predicate) {
> return true
> }
> }
> }
>
> func first(where predicate: (Element) throws -> Bool) rethrows -> Element?
> = nil {
> if try predicate(value) {
> return value
> }
>
> for child in children {
> if let result = try child.first(where: predicate) {
> return result
> }
> }
> }
>
> var leftMostDescendant: TreeNode? = nil {
> if let child = children.first {
> return child.leftMostDescendant ?? child
> }
> }
>
> The default return value shouldn’t be part of the function signature (i.e.
> it shouldn’t appear in interface files) because it’s an implementation
> detail, but right after the return type is probably the most natural place
> to put it (similar to default function parameters).
>
> Let me know what you think.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
>

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

On Wed, Jul 13, 2016 at 1:14 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jul 12, 2016, at 10:35 AM, Jordan Rose  wrote:
>
> [Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
> ]
>
> I definitely think this is an improvement over the last version! Nice
> work, Tony and Doug.
>
> I *am* a little confused about the implementation, though. The proposal
> says this:
>
> Instead, Swift should always perform operator lookup universally such that
> it sees all operators defined at either module scope or within a
> type/extension of a type. This gives us the syntactic
> improvements immediately and the natural Swift thing of defining your
> functionality within the type or an extension thereof just works.
>
>
> and then later says
>
> Therefore, we can achieve the performance improvements by making that
> insight part of the semantic model: when we find all operators, we also
> find the operators in the protocols themselves. The operators in the
> protocols are naturally generic.
>
>
> Then, we say that we do not consider an operator function if it implements
> a protocol requirement, because the requirement is a generalization of all
> of the operator functions that satisfy that requirement. With this rule,
> we’re effectively getting the same effects as if users had
> declared trampoline operators, but it's automatic.
>
>
> How do we know if an operator function implements a protocol requirement?
>
>
> Well, we can track it explicitly in the modules that define the protocol
> and that define conformances of specific types to the protocol.
> Alternatively, we try the protocol requirements *first*. Once we’ve
> inferred the ‘Self’ type of the protocol (which is part of trying the
> protocol requirement), we can look up a conformance and the witness to see
> which witnesses should no longer be considered.
>
> What happens when an operator function implements a protocol requirement,
> but is also more general than that?
>
>
> *Right now*, it’s only really possible when you’re using a global generic
> operator, because we require exact type matches between requirements and
> witnesses. If/when we allow the witness to be a supertype of the
> requirement, you’ll start to see more of the semantic effects of this
> model, because shadowing the witness with the requirement can reject code
> that is well-formed now.
>
> That’s why the shadowing behavior needs to be part of the semantic model.
> Implementation will let us settle the exact details so we can state those
> semantics more precisely.
>
> And if we do find the implementation in the protocol, what conformance do
> we use to invoke the function when the types involved aren’t all 'Self’?
>
>
> If there isn’t a reference to ‘Self’, type inference for the use of the
> protocol requirement will fail.
>
>
> I still prefer the rule that says we perform lookup into the left type and
> the right type, then fall back to top-level scope for backwards
> compatibility.
>
>
> We thought about it a lot, and it’s not implementable in a way that’s
> consistent with type inference, because one of the left or right types
> might not be known yet, and you also need to consider the context type for
> something like, e.g.,
>
> let x: UInt = 1 + 2
>
>
>
>
> Separately from the lookup rules, I’m still unhappy with the class
> problem. The proposal states this:
>
> We expect classes to implement the static operators in the protocol using
> `class` methods instead of `static` methods, which allows subclases to
> override them.
>
>
> However, if lookup only finds the method in the protocol, it’s unclear
> whether this will call a conforming class's method, a static type’s method,
> or a dynamic type’s method; if it’s not the last, it’s hardly an
> “override”. I maintain that this is the wrong behavior for any class
> hierarchy that *does* include heterogeneous operations, including
> "assignment operators, operators for chaining tasks, DSLs for constraint
> systems, etc” (me, from last time).
>
> More from last time:
>
> - for class types, regardless of whether one is a base of the other or
> both share a common third base type, neither static nor instance methods
> completely solve the problem and won't until/unless Swift supports multiple
> dispatch, and the proposed behavior is not a regression in those cases
>
> I guess I’m not convinced of the chain of reasoning here. “Multi-method
> dispatch is the most correct way to solve the problem” is fine; “therefore,
> anything short of that isn’t worth doing” is where I get stuck. Instance
> methods partially solve the problem, and it’s possible (again, no data on
> hand) that they solve the problem in the majority of cases.
>
> (It’s also possible that the prevalence of OO has made people prefer
> operators that can be dispatched based on the left-hand side, so I guess
> I’d want to go look at, e.g. Haskell and Perl

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On 13 Jul 2016, at 19:59, Daniel A. Steffen  wrote:
> 
> I’m confused, that is what we have in the current version (the argument label 
> is part of the overall method name): asyncAfter(deadline:) vs 
> asyncAfter(wallDeadline:), which is consistent with all the other labels of 
> deadline arguments in the API (this isn’t the only method dealing with time)
> 

I think this argument labels are superfluous and actually make the meaning less 
coherent. “after(when:…)” is not grammatically fluent, which the Swift API 
guidelines encourage, and which the standard library has made big steps towards 
recently (see especially 
https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md).
 By dropping the labels and renaming the function base-names, we make them more 
“swifty”, more concise, clear and readable, and can improve safety by making 
sure people know which clock they’re using and what semantic meaning that has. 

> we did discuss naming these asyncAt() instead of asyncAfter(), which would 
> make it more clear that they take a deadline, but the name felt uncomfortably 
> close to async(), and may also lead to the mistaken impression that the 
> execution with occur exactly _at_ the deadline (as opposed to just the 
> async() to a queue that may be full of other items already and take a while 
> to drain, or be suspended and never execute at all)
> 

I’m not sure it’s really necessary to include the word “async” in there — it’s 
pretty clear from the fact that they take a time that they’re not going to 
block.

The problem with “deadline” is that it’s just not a deadline. It’s an 
aspirational fire time, and Dispatch should execute the block as soon as 
possible after that time. I can’t really think of a concise word for it, but 
“deadline” does not express what you’re talking about. Deadline implies that 
the block can execute any time _before_ the specified time.

So that’s where I get “at” from; if your app is asleep, it isn’t possible to 
execute exactly at the specified time for reasons outside of your control. If 
it executes as soon as possible after waking, I would still consider it to be 
firing “at” the correct time (in a loose sort of way). If we were talking about 
the dispatch queue as a person, and I asked him/her to do something at a 
particular time, but they were delayed due to circumstances outside of 
anybody's control (like a natural disaster or a traffic accident), I’d still 
consider that they did it “at” the correct time, again in a loose sense - to 
the best that they can control it, in other words.

>> 
>>> So, what’s the sensible default you had in mind that won’t fail for a large 
>>> portion of use cases?  Safety is an important design point in an API 
>>> surface and making these distinctions clear to developers is absolutely 
>>> critical to achieving that goal.
>> 
>> The default clock depends on the context of what you’re doing. If I’m using 
>> DispatchQueue.after, I would say the monotonic clock is a reasonable 
>> default. Typically you’re going to be scheduling short fire-once things like 
>> performing an animation after a second or two (at the most). In that case, 
>> system sleep isn’t an issue - even on iOS where the user can lock the screen 
>> at any moment; your long-running alarm that crosses sleep events will still 
>> fire, it just won’t fire *immediately* upon wake. 
> 
> Nothing in the API says it must be used only for "short fire-once things"
> 
> The problem with the monotonic clock isn’t about firing at wake, but about 
> pushing the fire time out by the amount of time asleep.
> If you are using this to implement e.g. a calendaring meeting reminder 
> alarms, you are not going to be happy if your reminder is late by the amount 
> of time that your device happened to put its cpu to sleep for many short 
> intervals for power management reasons…

No, nothing in the API does say that, but in this context I believe it’s the 
most commonly wanted thing and would be a reasonable default.

If you are implementing calendar reminders using dispatch_after in an 
application which can be suspended at any moment, you’re using the wrong API 
pure and simple. On Linux, you might be able to guarantee your app won’t be 
suspended so this strategy could work for you, but the API you use must be 
appropriate to the platform. If you can’t make that guarantee (e.g. On iOS), 
you should look for an alternative, such as the local notifications API, which 
is designed for exactly this.

> 
>> iOS in general makes a point not to offer guarantees about what will happen 
>> to your app if it ever goes in to the background, and offers alternative 
>> backgrounding and local notification APIs instead.
> 
> this API isn’t just designed for iOS Apps but for system programming in 
> general, on any platform.
> 

No, but as above, the API you use must be appropriate for the platform. We 
shouldn’t worry about people on

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 Thread Nevin Brackett-Rozinsky via swift-evolution

2016-07-13 20:19 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:
>
> Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@gmail.com)
> schrieb:
>
> I see model of Type as follows:
>
>1. Values of Type are identifiers of types (8 bytes, I guess)
>2. All used identifiers are contained in Type
>3. Type contains a subset of those identifiers
>
> I can’t follow your though here. Is this a totally new behavior?
>
That's how it works right now:

sizeofValue(Bool.self)  //=> 0 (optimized away)
sizeofValue(Bool.self as Any.self)  //=> 8

I'll put my thoughts another way:

   - Internally, Type contains an Int, i.e. identifer of a type. For
   every type, compiler must choose a different identifier
   - API of Type is defined so that it can only contain identifiers of
   subtypes of T
   - For example, when you get a variable of Type, it can
   correspond to BaseClass or DerivedClass


>1. Upcasting uses constructor init(upcasting: Type)
>
> It does look neat but I can’t implement it. At least I have no clue how to
> solve the problem that `T` is not a protocol or a class type.
>
We should add implicit convertion of Type to Type, dulicating current
behaviour of `as T.Type`.
That constructor still can be useful, but it will be failable and not that
significant in practise.
I don't like adding compiler magic, but I guess we really should in this
case, because otherwise Type can't replace T.Type.

>
>1. Size of Type is 8, static size of Type is 0
>
> I feel like you mean something different here than this:
>
> ```swift
>
> protocol SomeProtocol {}
>
>
> sizeof(SomeProtocol.self) == 40
>
> ```
>

That was a mistake. Static size of Type will be 40, and size
property of its values can be less or greater than 40, depending on
internal type identifier.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Giving functions default return values

2016-07-13 Thread Tim Vermeulen via swift-evolution

I thought that was mainly about former proposals in the Github repo, but I’ll 
gladly bring this up again at a more appropriate time.

To address your message: I wouldn’t really want guard  else { } to 
be valid code. The default return value is simply returned if the end of the 
function body is reached and nothing has been returned yet. guard  
else { return } could possibly be allowed in case of a default return value, 
but definitely not an empty guard body. This wouldn’t cause any problems, would 
it?

> On 13 Jul 2016, at 17:47, Charlie Monroe  wrote:
> 
> Hi Tim,
> 
> the core team asked us to defer any discussion on post-Swift-3 related 
> proposals.
> 
> That said, there have been several discussion around this topic (in the past 
> few months) and I believe the general attitude towards them was negative, due 
> to it leading to statements such as 
> 
> guard  else { }
> 
> which
> 
> a) doesn't express what will happen when the condition is not met, making the 
> code hard to read
> 
> b) can lead to bugs in code since the compiler makes sure that the flow 
> doesn't continue beyond the guard statement and with default returns, this 
> would compiler without a warning or an error:
> 
> for obj in array {
>   guard obj.meetsConditions() else {
>   // Implicit return - most likely not intentional,
>   // you most likely want "continue" in here
>   }
> 
>   // ...
> }
> 
> 
>> On Jul 13, 2016, at 4:57 PM, Tim Vermeulen via swift-evolution 
>> > wrote:
>> 
>> This idea is purely additive and isn’t to be considered for Swift 3.
>> 
>> Oftentimes a function has a very obvious default argument to fall back on. 
>> If the return value is optional, this is generally nil. If the return value 
>> is Bool, it’s probably `false`. Often this fallback value is returned at the 
>> end of the function, just to return something if nothing has been returned 
>> yet. For instance, consider this TreeNode class:
>> 
>> class TreeNode {
>> 
>> var value: Element
>> var children: [TreeNode]
>> 
>> init(value: Element) {
>> self.value = value
>> children = []
>> }
>> 
>> func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool {
>> if try predicate(value) {
>> return true
>> }
>> 
>> for child in children {
>> if try child.contains(predicate) {
>> return true
>> }
>> }
>> 
>> return false // 1
>> }
>> 
>> func first(where predicate: (Element) throws -> Bool) rethrows -> 
>> Element? {
>> if try predicate(value) {
>> return value
>> }
>> 
>> for child in children {
>> if let result = try child.first(where: predicate) {
>> return result
>> }
>> }
>> 
>> return nil // 2
>> }
>> 
>> var leftMostDescendant: TreeNode? {
>> if let child = children.first {
>> return child.leftMostDescendant ?? child
>> }
>> 
>> return nil // 3
>> }
>> 
>> }
>> 
>> These code patterns are quite usual. If we could give default return values 
>> to functions, we could get rid of the final `return` statements:
>> 
>> func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool = 
>> false {
>> if try predicate(value) {
>> return true
>> }
>> 
>> for child in children {
>> if try child.contains(predicate) {
>> return true
>> }
>> }
>> }
>> 
>> func first(where predicate: (Element) throws -> Bool) rethrows -> Element? = 
>> nil {
>> if try predicate(value) {
>> return value
>> }
>> 
>> for child in children {
>> if let result = try child.first(where: predicate) {
>> return result
>> }
>> }
>> }
>> 
>> var leftMostDescendant: TreeNode? = nil {
>> if let child = children.first {
>> return child.leftMostDescendant ?? child
>> }
>> }
>> 
>> The default return value shouldn’t be part of the function signature (i.e. 
>> it shouldn’t appear in interface files) because it’s an implementation 
>> detail, but right after the return type is probably the most natural place 
>> to put it (similar to default function parameters).
>> 
>> Let me know what you think.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

2016-07-13 Thread Douglas Gregor via swift-evolution


> On Jul 12, 2016, at 10:35 AM, Jordan Rose  wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
>  
> 
>  ]
> 
> I definitely think this is an improvement over the last version! Nice work, 
> Tony and Doug.
> 
> I am a little confused about the implementation, though. The proposal says 
> this:
> 
>> Instead, Swift should always perform operator lookup universally such that 
>> it sees all operators defined at either module scope or within a 
>> type/extension of a type. This gives us the syntactic improvements 
>> immediately and the natural Swift thing of defining your functionality 
>> within the type or an extension thereof just works.
> 
> and then later says
> 
>> Therefore, we can achieve the performance improvements by making that 
>> insight part of the semantic model: when we find all operators, we also find 
>> the operators in the protocols themselves. The operators in the protocols 
>> are naturally generic.
> 
>> Then, we say that we do not consider an operator function if it implements a 
>> protocol requirement, because the requirement is a generalization of all of 
>> the operator functions that satisfy that requirement. With this rule, we’re 
>> effectively getting the same effects as if users had declared trampoline 
>> operators, but it's automatic.
> 
> How do we know if an operator function implements a protocol requirement?

Well, we can track it explicitly in the modules that define the protocol and 
that define conformances of specific types to the protocol. Alternatively, we 
try the protocol requirements *first*. Once we’ve inferred the ‘Self’ type of 
the protocol (which is part of trying the protocol requirement), we can look up 
a conformance and the witness to see which witnesses should no longer be 
considered.

> What happens when an operator function implements a protocol requirement, but 
> is also more general than that?

*Right now*, it’s only really possible when you’re using a global generic 
operator, because we require exact type matches between requirements and 
witnesses. If/when we allow the witness to be a supertype of the requirement, 
you’ll start to see more of the semantic effects of this model, because 
shadowing the witness with the requirement can reject code that is well-formed 
now.

That’s why the shadowing behavior needs to be part of the semantic model. 
Implementation will let us settle the exact details so we can state those 
semantics more precisely.

> And if we do find the implementation in the protocol, what conformance do we 
> use to invoke the function when the types involved aren’t all 'Self’?

If there isn’t a reference to ‘Self’, type inference for the use of the 
protocol requirement will fail.

> 
> I still prefer the rule that says we perform lookup into the left type and 
> the right type, then fall back to top-level scope for backwards compatibility.

We thought about it a lot, and it’s not implementable in a way that’s 
consistent with type inference, because one of the left or right types might 
not be known yet, and you also need to consider the context type for something 
like, e.g.,

let x: UInt = 1 + 2


> 
> 
> Separately from the lookup rules, I’m still unhappy with the class problem. 
> The proposal states this:
> 
>> We expect classes to implement the static operators in the protocol using 
>> `class` methods instead of `static` methods, which allows subclases to 
>> override them.
> 
> However, if lookup only finds the method in the protocol, it’s unclear 
> whether this will call a conforming class's method, a static type’s method, 
> or a dynamic type’s method; if it’s not the last, it’s hardly an “override”. 
> I maintain that this is the wrong behavior for any class hierarchy that does 
> include heterogeneous operations, including "assignment operators, operators 
> for chaining tasks, DSLs for constraint systems, etc” (me, from last time).
> 
> More from last time:
> 
>>> - for class types, regardless of whether one is a base of the other or both 
>>> share a common third base type, neither static nor instance methods 
>>> completely solve the problem and won't until/unless Swift supports multiple 
>>> dispatch, and the proposed behavior is not a regression in those cases
>>> 
>> I guess I’m not convinced of the chain of reasoning here. “Multi-method 
>> dispatch is the most correct way to solve the problem” is fine; “therefore, 
>> anything short of that isn’t worth doing” is where I get stuck. Instance 
>> methods partially solve the problem, and it’s possible (again, no data on 
>> hand) that they solve the problem in the majority of cases.
>> 
>> (It’s also possible that the prevalence of OO has made people prefer 
>> operators that can be dispatched based on the left-hand side, so I guess I’d 
>>

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

I concur with Joe Groff and John McCall, this proposal does not seem to be
the right approach.

What I would really like is the complete elimination of implicit coercion
to Optional (implicit type conversions are not Swifty!) and the
simultaneous introduction of a simple notation for doing so explicitly.

If we can make it play nice with optional chaining, then a postfix `?`
operator is the natural choice: `(42?, "babel fish"?, mattressSwamp?)`
would be a tuple of optionals, and `(1, 2, 3)?` an optional tuple.

Nevin


On Wed, Jul 13, 2016 at 1:16 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Jul 13, 2016, at 10:06 AM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> > -1. This feels like a band-aid rather than a well-considered fix to the
> issues raised in the proposal. I don't see what makes operators as a class
> of functions more or less susceptible to these surprising optional upcasts.
> Removing the comparison operators for optionals will resolve the issue with
> '<', and if we're concerned about '??', an unavailable overload for ??(T,
> T) could address that specific issue. Optional promotion in operators is
> clearly useful in many cases, as the proposal itself concedes by
> special-case exempting the assignment operator from the restriction and
> proposing the addition of more than a dozen overloads to restore the
> equivalent of explicit promotion behavior for specific operators, and that
> doing so accepts other undesirable formulations like 'nonOptional == nil'.
> This proposal doesn't make a compelling case that being an operator is the
> correct criterion to disable optional promotion.
>
> Agreed.  To me, the right solution is some attribute to suppress promotion
> for specific arguments.
>
> When we get to decl-based overload resolution, this will become
> straightforward to implement.
>
> John.
>
> >
> > -Joe
> >
> >> On Jul 12, 2016, at 10:25 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Hello Swift community,
> >>
> >> The review of "SE-0123: Disallow coercion to optionals in operator
> arguments" begins now and runs through July 19. The proposal is available
> here:
> >>
> >>
> https://github.com/apple/swift-evolution/blob/master/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.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 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] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

2016-07-13 Thread Daniel A. Steffen via swift-evolution


> On Jul 13, 2016, at 10:08, Karl via swift-evolution 
>  wrote:
> 
>> 
>> On 13 Jul 2016, at 18:47, Anthony Chivetta via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jul 13, 2016, at 9:18 , Karl via swift-evolution 
>>> > wrote:
>>> 
>>> nuances about the clock (basically, whether or not it pauses during system 
>>> sleep) are edge-cases which can be handled for the majority of users with a 
>>> sensible default value
>> 
>> I’m going to stay out of the naming part of the conversation for the moment 
>> and just address this point…
>> 
>> I disagree strenuously: it’s a super important distinction that is 
>> frequently the cause of subtle but bad bugs!
>> 
>> Lets start with the fact that you (presumably not the novice user you 
>> describe below) actually got the difference between the two clocks wrong.  
>> Here’s the current behavior (on Darwin, not sure what Linux currently 
>> implements):
>> 
>>   - DispatchTime is a clock that only advances forward and tracks the amount 
>> of time the computer is awake.
>> 
>>   - DispatchWillTime is a clock that tracks as a UTC clock would, generally 
>> moving ahead during sleep, but is *not* monotonic.  It can move forward, 
>> backward, upside down, whatever it wants.  And frequently it will.
>> 
> 
> Yeah I know, I don’t think I got the clocks wrong. I forgot that the UTC 
> clock can move around, but yeah, of course it can; fair enough.
> 
>> And this stuff is hard: if you are writing a tea timer app and you pick 
>> either of these, you have a bug.  DispatchTime, the bug is that if the user 
>> locks their device and it falls asleep the alarm won’t fire upon wake.  
>> DispatchWallTime, if the device realizes its clock is ahead or behind the 
>> “real” time the elapsed duration won’t be what you expect.  (Should we have 
>> a third that works for the tea timer? Absolutely…)
>> 
> 
> Do you think that is adequately expressed in the API? 
> 
> I don’t, and I believe the current system of type-based overloads is not a 
> good way to ensure people don’t accidentally use the wrong one. Maybe we 
> should rename the methods which take each type to make it more of a conscious 
> decision (I’m happy with that, because in that case we definitely have 
> reasonable default values )

I’m confused, that is what we have in the current version (the argument label 
is part of the overall method name): asyncAfter(deadline:) vs 
asyncAfter(wallDeadline:), which is consistent with all the other labels of 
deadline arguments in the API (this isn’t the only method dealing with time)

we did discuss naming these asyncAt() instead of asyncAfter(), which would make 
it more clear that they take a deadline, but the name felt uncomfortably close 
to async(), and may also lead to the mistaken impression that the execution 
with occur exactly _at_ the deadline (as opposed to just the async() to a queue 
that may be full of other items already and take a while to drain, or be 
suspended and never execute at all)

> 
>> So, what’s the sensible default you had in mind that won’t fail for a large 
>> portion of use cases?  Safety is an important design point in an API surface 
>> and making these distinctions clear to developers is absolutely critical to 
>> achieving that goal.
> 
> The default clock depends on the context of what you’re doing. If I’m using 
> DispatchQueue.after, I would say the monotonic clock is a reasonable default. 
> Typically you’re going to be scheduling short fire-once things like 
> performing an animation after a second or two (at the most). In that case, 
> system sleep isn’t an issue - even on iOS where the user can lock the screen 
> at any moment; your long-running alarm that crosses sleep events will still 
> fire, it just won’t fire *immediately* upon wake.

Nothing in the API says it must be used only for "short fire-once things"

The problem with the monotonic clock isn’t about firing at wake, but about 
pushing the fire time out by the amount of time asleep.
If you are using this to implement e.g. a calendaring meeting reminder alarms, 
you are not going to be happy if your reminder is late by the amount of time 
that your device happened to put its cpu to sleep for many short intervals for 
power management reasons...

> iOS in general makes a point not to offer guarantees about what will happen 
> to your app if it ever goes in to the background, and offers alternative 
> backgrounding and local notification APIs instead.

this API isn’t just designed for iOS Apps but for system programming in 
general, on any platform.

> 
> And again, if you considered it and really need that timer to fire 
> immediately if the system dozed off for a little bit in-between, that’s 
> available as an explicit consideration.
> 
> I could see how there’s an argument for a third type of timer; it’s obviously 
> a

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

2016-07-13 Thread John McCall via swift-evolution

> On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> As Jordan mentioned, I don't (and I think other people don't) think of 
> extensions as their own entities, as they can't be referred to and have no 
> runtime representation. In that mental model, there isn't such a thing as "an 
> extension being public." Instead, the access modifier is just a shorthand 
> default for the properties and methods it contains, which is teachable but 
> unique to extensions. It is a matter of opinion whether that uniqueness is a 
> feature or a bug.

I would say that it's interesting but ultimately not worth the confusion about 
the nature of extensions.

John.

> 
> On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez  > wrote:
> 
> 
> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> 
>> 
>> On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution 
>> > wrote:
>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
>>  
>> 
>> 
>>> * What is your evaluation of the proposal?
>> 
>> -1. Extensions appear to me to follow the access control of the rest of 
>> Swift: Implicit to the type you are extending, and you can either / both 
>> declare as part of the extension declaration or on the method. I don’t see 
>> how this is confusing, and I expect people will be more confused that 
>> extensions don’t follow the convention of the rest of Swift for Access 
>> Control.
>> 
>> So, actually, the proposal is correct that extensions (at least once 
>> fileprivate/private is implemented) don't follow the access control rules 
>> for the rest of Swift. There is a problem to be addressed. However, I agree 
>> that this proposal hasn't identified the issue or adequately explained how 
>> the solution solves it. Here's the problem I'm thinking of:
>> 
>> ```
>> public struct foo {
>>   func frobnicate() { } // implicitly internal
>> }
>> 
>> public struct bar { }
>> public extension bar {
>>   func frobnicate() { } // implicitly public
>>   // at least, according to the revised rules explained in SE-0025
>> }
>> ```
> 
> There is definitely a difference, I think that is a good thing. They look 
> similar but they are completely different. 
> 
> public Type // the type is public
> public extension Type //  the extension is public 
> 
> For extensions, public is just a modifier on extension, not the type. The 
> default scope inside the extension is that of the "modifier" keyword on the 
> extension. 
> 
> This is easy to explain to someone new. 
> 
> 
>> 
>> This is an inconsistency that may (and IMO, really is) worth addressing. If 
>> there's adequate interest, I can circulate a draft with a proposed solution 
>> I have in mind.
>>  
>> 
>>> * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> I don’t think this warrants a change.
>> 
>>> * Does this proposal fit well with the feel and direction of Swift?
>> No. This seems to go against the 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?
>> 
>> No.
>> 
>>> * How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> A reading of the proposal.
>> 
>> 
>> ___
>> 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

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

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?


> On 13 Jul 2016, at 18:56, Pierre Habouzit  wrote:
> 
>> On Jul 13, 2016, at 9:18 AM, Karl via swift-evolution 
>> > wrote:
>> 
>> #1 - 
>> 
>> Currently, DispatchQueue.after() takes an absolute time as the “after” 
>> parameter. This makes it hard to understand how to use it; you need to go 
>> digging through generated interfaces to find out what a ‘DispatchTime’ is 
>> and how you construct it (by getting the .now() and adding a 
>> DispatchTimeInterval using one of the easily-missable operator overloads, if 
>> you were wondering).
>> 
>> Here is what DispatchQueue.after looks like now:
>> 
>> public func after(when: DispatchTime, qos: DispatchQoS = .unspecified, 
>> flags: DispatchWorkItemFlags = [], execute work: @convention(block) () -> 
>> Void)
>> 
>> So to use it, you have to type:
>> 
>> DispatchQueue.main.after(when: DispatchTime.now() + .milliseconds(250))   { 
>> /* do stuff */ }
>> 
>> I don’t believe this is a great fit with the Swift API Guidelines. I believe 
>> the name “after” already implies that the time is relative, the argument 
>> label should be dropped, and that nuances about the clock (basically, 
>> whether or not it pauses during system sleep) are edge-cases which can be 
>> handled for the majority of users with a sensible default value (or better 
>> yet, modelling via an enum or boolean switch — see #2). Additionally, There 
>> are overloads with “wallTime” parameter labels which seem only to duplicate 
>> type information (the monotonic and walltime clocks are actually split at 
>> the type level) and could be more concise and readable. The principle is 
>> that, ultimately, you should just be able to write the above code like this:
>> 
>> DispatchQueue.main.after(.milliseconds(250)) { /* do stuff */ }
>> 
>> Or
>> 
>> DispatchQueue.main.at (DispatchTime.now() + 
>> .seconds(3)) { /* do stuff */ }
>> 
>> It’s not something you use all the time (like .sync/.async), but I find that 
>> whenever I do need it I’m frustrated by how needlessly complex it is to 
>> decipher and use. I would find these methods much more obvious, I could 
>> figure out how to use them much more quickly, and I think I’d remember how 
>> to use them more quickly.
> 
> As mentioned by Matt in the pull request you created, we’re working on a 
> proposal that would look like this:
> 
> func asyncAfter(deadline:qos:flags:work:)
> func asyncAfter(wallDeadline:qos:flags:work:)
> As we discussed on the pull request, 
> 
> DispatchQueue.main.after(.milliseconds(250)) { /* do stuff */ }
> 
> Is ambiguous as you don’t know which clock was meant, and despite your claim, 
> there’s in general no good default for the clock. If you are writing a 
> calendar app, you want wallClock, but if you’re doing anything network 
> related, you will want the monotonic one. Depending on which software you’re 
> writing, you will have a bias for one or the other.

Yeah I think we should split after(DispatchTime) and after(DispatchWallTime) to 
reflect their different ways of working.

after(DispatchTime) stays as it is, because it reflects an elapsed number of 
ticks
after(DispatchWallTime) should be renamed. I suggested it should be 
at(DispatchWallTime), and should only take an absolute value.

“after(deadline:)” isn’t better, I’m afraid. The definition is: "the latest 
time or date by which something should be completed.” We don’t really talk 
about “after” deadlines - deadlines are points in time you need to do something 
*before*. If something happens after a deadline, we say it “missed” the 
deadline. Like I said in the PR, that kind of timing guarantee is most clearly 
expressed by saying “by(deadline:)”.

> 
> Also it may be a native speaker thing (which I’m not) but this reads “please 
> async this closure on `q` after this deadline has expired” to me, which 
> sounds like proper english:
> 
> q.asyncAfter(deadline: .now() + 1.0) { /* do stuff */ }
> 
> 
> I thought that you would say “please meet me in 10 minutes” or “please meet 
> me after 2PM”. The `asyncBy` that you suggested to the pull request reads 
> *before* that deadline to me which is not good either.
> `asyncAt` would probably work too however, but asyncAfter is easier for 
> people coming from C who are used to dispatch_after().
> 
> 
>> #2 - 
>> 
>> Actually, while writing this down it’s becoming clearer and clearer that the 
>> idea to split DispatchTime (the monotonic clock) and DispatchWallTime (the 
>> wall clock) at the type level is probably a bad idea.
>> 
>> Novice users are not going to understand what’s going on here - I expect 
>> most of them to default to the more generic-sounding “DispatchTime” without 
>> any idea of the implications of this. Perhaps we should look at replacing 
>> these clock variations with a more descriptive enum or boolean, rather than 
>> a separate type. For example:
>> 
>> struct DispatchTime {

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

2016-07-13 Thread Jose Cheyo Jimenez via swift-evolution

As Jordan mentioned, I don't (and I think other people don't) think of
extensions as their own entities, as they can't be referred to and have no
runtime representation. In that mental model, there isn't such a thing as
"an extension being public." Instead, the access modifier is just a
shorthand default for the properties and methods it contains, which is
teachable but unique to extensions. It is a matter of opinion whether that
uniqueness is a feature or a bug.

On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez 
wrote:

>
>
> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Proposal link:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
>>
>> * What is your evaluation of the proposal?
>>
>> -1. Extensions appear to me to follow the access control of the rest of
>> Swift: Implicit to the type you are extending, and you can either / both
>> declare as part of the extension declaration or on the method. I don’t see
>> how this is confusing, and I expect people will be more confused that
>> extensions don’t follow the convention of the rest of Swift for Access
>> Control.
>>
>
> So, actually, the proposal is correct that extensions (at least once
> fileprivate/private is implemented) don't follow the access control rules
> for the rest of Swift. There is a problem to be addressed. However, I agree
> that this proposal hasn't identified the issue or adequately explained how
> the solution solves it. Here's the problem I'm thinking of:
>
> ```
> public struct foo {
>   func frobnicate() { } // implicitly internal
> }
>
> public struct bar { }
> public extension bar {
>   func frobnicate() { } // implicitly public
>   // at least, according to the revised rules explained in SE-0025
> }
> ```
>
>
> There is definitely a difference, I think that is a good thing. They look
> similar but they are completely different.
>
> public Type // the type is public
> public extension Type //  the extension is public
>
> For extensions, public is just a modifier on extension, not the type. The
> default scope inside the extension is that of the "modifier" keyword on the
> extension.
>
> This is easy to explain to someone new.
>
>
>
> This is an inconsistency that may (and IMO, really is) worth addressing.
> If there's adequate interest, I can circulate a draft with a proposed
> solution I have in mind.
>
>
>>
>> * Is the problem being addressed significant enough to warrant a change
>> to Swift?
>>
>> I don’t think this warrants a change.
>>
>> * Does this proposal fit well with the feel and direction of Swift?
>>
>> No. This seems to go against the 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?
>>
>> No.
>>
>> * How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>> A reading of the proposal.
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions



> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> 
>> On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution 
>>  wrote:
>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
>> 
>>> * What is your evaluation of the proposal?
>> 
>> -1. Extensions appear to me to follow the access control of the rest of 
>> Swift: Implicit to the type you are extending, and you can either / both 
>> declare as part of the extension declaration or on the method. I don’t see 
>> how this is confusing, and I expect people will be more confused that 
>> extensions don’t follow the convention of the rest of Swift for Access 
>> Control.
> 
> So, actually, the proposal is correct that extensions (at least once 
> fileprivate/private is implemented) don't follow the access control rules for 
> the rest of Swift. There is a problem to be addressed. However, I agree that 
> this proposal hasn't identified the issue or adequately explained how the 
> solution solves it. Here's the problem I'm thinking of:
> 
> ```
> public struct foo {
>   func frobnicate() { } // implicitly internal
> }
> 
> public struct bar { }
> public extension bar {
>   func frobnicate() { } // implicitly public
>   // at least, according to the revised rules explained in SE-0025
> }
> ```

There is definitely a difference, I think that is a good thing. They look 
similar but they are completely different. 

public Type // the type is public
public extension Type //  the extension is public 

For extensions, public is just a modifier on extension, not the type. The 
default scope inside the extension is that of the "modifier" keyword on the 
extension. 

This is easy to explain to someone new. 


> 
> This is an inconsistency that may (and IMO, really is) worth addressing. If 
> there's adequate interest, I can circulate a draft with a proposed solution I 
> have in mind.
>  
>> 
>>> * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> I don’t think this warrants a change.
>> 
>>> * Does this proposal fit well with the feel and direction of Swift?
>> No. This seems to go against the 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?
>> 
>> No.
>> 
>>> * How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> A reading of the proposal.
>> 
>> 
>> ___
>> 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] Seal `T.Type` into `Type`

2016-07-13 Thread Adrian Zubarev via swift-evolution


Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

I see model of Type as follows:
Values of Type are identifiers of types (8 bytes, I guess)
All used identifiers are contained in Type
Type contains a subset of those identifiers
I can’t follow your though here. Is this a totally new behavior?

Type are usually created with default constructor Type()
That one is easy and already there.

Upcasting uses constructor init(upcasting: Type)
It does look neat but I can’t implement it. At least I have no clue how to 
solve the problem that `T` is not a protocol or a class type.

Checking for conformance uses method isSubtype(of:)
Interesting suggestion.

Size of Type is 8, static size of Type is 0
I feel like you mean something different here than this:

```swift

protocol SomeProtocol {}

sizeof(SomeProtocol.self) == 40
```

2016-07-13 18:25 GMT+03:00 Adrian Zubarev via swift-evolution 
:
a = SomeClass.self

expectTrue(a as? Any.Type == SomeClass.self)
expectTrue(a as? AnyClass == SomeClass.self)
expectTrue(a as? SomeClass.Type == SomeClass.self)
That example just demonstrates syntax of metatypes and does not count.
What about dynamicType?

It should have the following signature:

func dynamicType(_ var: T) -> Type

To return Type means to return an identifier of U: T
Was this a typo?

func dynamicType(_ var: T) -> Type

PS: If you’d like to join on this idea, I could move the draft to a repo to be 
able to write the proposal together. You had some good catchy ideas there.

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

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

2016-07-13 Thread John McCall via swift-evolution

> On Jul 13, 2016, at 10:06 AM, Joe Groff via swift-evolution 
>  wrote:
> -1. This feels like a band-aid rather than a well-considered fix to the 
> issues raised in the proposal. I don't see what makes operators as a class of 
> functions more or less susceptible to these surprising optional upcasts. 
> Removing the comparison operators for optionals will resolve the issue with 
> '<', and if we're concerned about '??', an unavailable overload for ??(T, T) 
> could address that specific issue. Optional promotion in operators is clearly 
> useful in many cases, as the proposal itself concedes by special-case 
> exempting the assignment operator from the restriction and proposing the 
> addition of more than a dozen overloads to restore the equivalent of explicit 
> promotion behavior for specific operators, and that doing so accepts other 
> undesirable formulations like 'nonOptional == nil'. This proposal doesn't 
> make a compelling case that being an operator is the correct criterion to 
> disable optional promotion.

Agreed.  To me, the right solution is some attribute to suppress promotion for 
specific arguments.

When we get to decl-based overload resolution, this will become straightforward 
to implement.

John.

> 
> -Joe
> 
>> On Jul 12, 2016, at 10:25 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0123: Disallow coercion to optionals in operator 
>> arguments" begins now and runs through July 19. The proposal is available 
>> here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.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 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] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On 13 Jul 2016, at 18:47, Anthony Chivetta via swift-evolution 
>  wrote:
> 
> 
>> On Jul 13, 2016, at 9:18 , Karl via swift-evolution 
>> > wrote:
>> 
>> nuances about the clock (basically, whether or not it pauses during system 
>> sleep) are edge-cases which can be handled for the majority of users with a 
>> sensible default value
> 
> I’m going to stay out of the naming part of the conversation for the moment 
> and just address this point…
> 
> I disagree strenuously: it’s a super important distinction that is frequently 
> the cause of subtle but bad bugs!
> 
> Lets start with the fact that you (presumably not the novice user you 
> describe below) actually got the difference between the two clocks wrong.  
> Here’s the current behavior (on Darwin, not sure what Linux currently 
> implements):
> 
>   - DispatchTime is a clock that only advances forward and tracks the amount 
> of time the computer is awake.
> 
>   - DispatchWillTime is a clock that tracks as a UTC clock would, generally 
> moving ahead during sleep, but is *not* monotonic.  It can move forward, 
> backward, upside down, whatever it wants.  And frequently it will.
> 

Yeah I know, I don’t think I got the clocks wrong. I forgot that the UTC clock 
can move around, but yeah, of course it can; fair enough.

> And this stuff is hard: if you are writing a tea timer app and you pick 
> either of these, you have a bug.  DispatchTime, the bug is that if the user 
> locks their device and it falls asleep the alarm won’t fire upon wake.  
> DispatchWallTime, if the device realizes its clock is ahead or behind the 
> “real” time the elapsed duration won’t be what you expect.  (Should we have a 
> third that works for the tea timer? Absolutely…)
> 

Do you think that is adequately expressed in the API? 

I don’t, and I believe the current system of type-based overloads is not a good 
way to ensure people don’t accidentally use the wrong one. Maybe we should 
rename the methods which take each type to make it more of a conscious decision 
(I’m happy with that, because in that case we definitely have reasonable 
default values )

> So, what’s the sensible default you had in mind that won’t fail for a large 
> portion of use cases?  Safety is an important design point in an API surface 
> and making these distinctions clear to developers is absolutely critical to 
> achieving that goal.

The default clock depends on the context of what you’re doing. If I’m using 
DispatchQueue.after, I would say the monotonic clock is a reasonable default. 
Typically you’re going to be scheduling short fire-once things like performing 
an animation after a second or two (at the most). In that case, system sleep 
isn’t an issue - even on iOS where the user can lock the screen at any moment; 
your long-running alarm that crosses sleep events will still fire, it just 
won’t fire *immediately* upon wake. iOS in general makes a point not to offer 
guarantees about what will happen to your app if it ever goes in to the 
background, and offers alternative backgrounding and local notification APIs 
instead.

And again, if you considered it and really need that timer to fire immediately 
if the system dozed off for a little bit in-between, that’s available as an 
explicit consideration.

I could see how there’s an argument for a third type of timer; it’s obviously a 
complex topic, and we should provide a reasonable default if possible; even if 
that’s a platform-specific alias.

> 
> (Of course, Foundation.Timer gets all of the above horribly wrong, IMHO.  We 
> should fix that too…)
> 
>>  (the monotonic and walltime clocks are actually split at the type level)
> 
> DispatchTime is not a monotonic clock.  At least, not in the POSIX sense.  So 
> let’s not call it that.  (Linux’s failure to implement POSIX correctly 
> notwithstanding.)
> 
>> Novice users are not going to understand what’s going on here - I expect 
>> most of them to default to the more generic-sounding “DispatchTime” without 
>> any idea of the implications of this.
> 
> If that’s the case, that’s a good argument for forcing users to make the 
> choice in an even more obvious and explicit way.  Not making it easier to use 
> one or the other when they’ll likely get it wrong.
> 

Yes, that was the motivation behind saying we should merge them - while writing 
it, it feels like you’re on a bit of a tightrope - one slip and this code could 
mean something very different.

Karl

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0119: Remove access modifiers from extensions

2016-07-13 Thread Adrian Zubarev via swift-evolution


Am 13. Juli 2016 um 18:49:11, Jordan Rose (jordan_r...@apple.com) schrieb:

Hi, Adrian. I have to agree with everyone else that the proposal is unclear. 
“Remove access modifiers from extensions” sounds like you just aren’t allowed 
to write them at all, but your proposal seems to be more “access modifiers on 
extensions set a maximum level of access for members, like they do for types, 
and do not change the default”. (Plus a bit about conformances.) 
I probably misunderstood you in the original proposal thread here: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022341.html

I renamed the proposal by thinking that would be the correct technical issue I 
was addressing. I apologize for any confusion the title have caused.

I am against the latter proposal because I don’t think people should think of 
extensions as first-class entities. There is really no such thing as a “public 
extension” or a “private extension” because extensions cannot be referred to in 
the language and do not have any run-time representation. The access control 
that really matters is that of the original type, and I wouldn’t want to force 
people to repeat it here. 
Just for the record:

- What happens under the hood if I extend a specific type?

- Do you create only one single `extension bag` and sort members by the access 
modifiers from all different extensions?

- How do these members reference to other extensions members which are visible 
only inside a specific extension?

I am personally all right with the idea of removing access modifiers from 
extensions altogether, but I know several people like that feature a lot, and I 
don’t think it passes the criterion of being “a significant enough problem to 
warrant a change in Swift”. 
I don’t mind if the proposal gets rejected now, at least I’ve seen a bit more 
feedback now.

PS: One think I might still would want to solve with this proposal is the 
default access modifier on extensions with protocols.

If you’d think about the rules in the proposed solution, aren’t they exactly 
how a default access modifier still can be present when there is conformance 
involved? 

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

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

2016-07-13 Thread Joe Groff via swift-evolution

-1. This feels like a band-aid rather than a well-considered fix to the issues 
raised in the proposal. I don't see what makes operators as a class of 
functions more or less susceptible to these surprising optional upcasts. 
Removing the comparison operators for optionals will resolve the issue with 
'<', and if we're concerned about '??', an unavailable overload for ??(T, T) 
could address that specific issue. Optional promotion in operators is clearly 
useful in many cases, as the proposal itself concedes by special-case exempting 
the assignment operator from the restriction and proposing the addition of more 
than a dozen overloads to restore the equivalent of explicit promotion behavior 
for specific operators, and that doing so accepts other undesirable 
formulations like 'nonOptional == nil'. This proposal doesn't make a compelling 
case that being an operator is the correct criterion to disable optional 
promotion.

-Joe

> On Jul 12, 2016, at 10:25 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0123: Disallow coercion to optionals in operator arguments" 
> begins now and runs through July 19. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

2016-07-13 Thread Pierre Habouzit via swift-evolution

> On Jul 13, 2016, at 9:18 AM, Karl via swift-evolution 
>  wrote:
> 
> #1 - 
> 
> Currently, DispatchQueue.after() takes an absolute time as the “after” 
> parameter. This makes it hard to understand how to use it; you need to go 
> digging through generated interfaces to find out what a ‘DispatchTime’ is and 
> how you construct it (by getting the .now() and adding a DispatchTimeInterval 
> using one of the easily-missable operator overloads, if you were wondering).
> 
> Here is what DispatchQueue.after looks like now:
> 
> public func after(when: DispatchTime, qos: DispatchQoS = .unspecified, flags: 
> DispatchWorkItemFlags = [], execute work: @convention(block) () -> Void)
> 
> So to use it, you have to type:
> 
> DispatchQueue.main.after(when: DispatchTime.now() + .milliseconds(250))   { 
> /* do stuff */ }
> 
> I don’t believe this is a great fit with the Swift API Guidelines. I believe 
> the name “after” already implies that the time is relative, the argument 
> label should be dropped, and that nuances about the clock (basically, whether 
> or not it pauses during system sleep) are edge-cases which can be handled for 
> the majority of users with a sensible default value (or better yet, modelling 
> via an enum or boolean switch — see #2). Additionally, There are overloads 
> with “wallTime” parameter labels which seem only to duplicate type 
> information (the monotonic and walltime clocks are actually split at the type 
> level) and could be more concise and readable. The principle is that, 
> ultimately, you should just be able to write the above code like this:
> 
> DispatchQueue.main.after(.milliseconds(250)) { /* do stuff */ }
> 
> Or
> 
> DispatchQueue.main.at(DispatchTime.now() + .seconds(3)) { /* do stuff */ }
> 
> It’s not something you use all the time (like .sync/.async), but I find that 
> whenever I do need it I’m frustrated by how needlessly complex it is to 
> decipher and use. I would find these methods much more obvious, I could 
> figure out how to use them much more quickly, and I think I’d remember how to 
> use them more quickly.

As mentioned by Matt in the pull request you created, we’re working on a 
proposal that would look like this:

func asyncAfter(deadline:qos:flags:work:)
func asyncAfter(wallDeadline:qos:flags:work:)
As we discussed on the pull request, 

DispatchQueue.main.after(.milliseconds(250)) { /* do stuff */ }

Is ambiguous as you don’t know which clock was meant, and despite your claim, 
there’s in general no good default for the clock. If you are writing a calendar 
app, you want wallClock, but if you’re doing anything network related, you will 
want the monotonic one. Depending on which software you’re writing, you will 
have a bias for one or the other.

Also it may be a native speaker thing (which I’m not) but this reads “please 
async this closure on `q` after this deadline has expired” to me, which sounds 
like proper english:

q.asyncAfter(deadline: .now() + 1.0) { /* do stuff */ }


I thought that you would say “please meet me in 10 minutes” or “please meet me 
after 2PM”. The `asyncBy` that you suggested to the pull request reads *before* 
that deadline to me which is not good either.
`asyncAt` would probably work too however, but asyncAfter is easier for people 
coming from C who are used to dispatch_after().


> #2 - 
> 
> Actually, while writing this down it’s becoming clearer and clearer that the 
> idea to split DispatchTime (the monotonic clock) and DispatchWallTime (the 
> wall clock) at the type level is probably a bad idea.
> 
> Novice users are not going to understand what’s going on here - I expect most 
> of them to default to the more generic-sounding “DispatchTime” without any 
> idea of the implications of this. Perhaps we should look at replacing these 
> clock variations with a more descriptive enum or boolean, rather than a 
> separate type. For example:
> 
> struct DispatchTime {   // replaces DispatchTime and 
> DispatchWallTime
>let rawValue : dispatch_time_t
>let clock : Clock
> 
>enum Clock { case monotonicClock; case wallClock }
> }
> 
> This would not obsolete the discussion at the start about “after”. The name 
> “after” still implies that I want something done at some duration relative to 
> an absolute point in time (usually now).

This is what dispatch_time_t does in C and my team at Apple widely considers 
this having been a design mistake: it means that the time is not generally 
Comparable, that you can’t perform any kind of arithmetic with it, etc.

In C it’s more convenient to have a single type, but in Swift where type is 
inferred, given that most of the uses will construct the time as the argument 
to the function itself, we feel that the current proposal allows for the most 
concise use.



-Pierre___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0119: Remove access modifiers from extensions

2016-07-13 Thread Jordan Rose via swift-evolution

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
 ]

Hi, Adrian. I have to agree with everyone else that the proposal is unclear. 
“Remove access modifiers from extensions” sounds like you just aren’t allowed 
to write them at all, but your proposal seems to be more “access modifiers on 
extensions set a maximum level of access for members, like they do for types, 
and do not change the default”. (Plus a bit about conformances.)

I am against the latter proposal because I don’t think people should think of 
extensions as first-class entities. There is really no such thing as a “public 
extension” or a “private extension” because extensions cannot be referred to in 
the language and do not have any run-time representation. The access control 
that really matters is that of the original type, and I wouldn’t want to force 
people to repeat it here.

I am personally all right with the idea of removing access modifiers from 
extensions altogether, but I know several people like that feature a lot, and I 
don’t think it passes the criterion of being “a significant enough problem to 
warrant a change in Swift”.

Jordan

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

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

2016-07-13 Thread Anthony Chivetta via swift-evolution

> On Jul 13, 2016, at 9:18 , Karl via swift-evolution 
>  wrote:
> 
> nuances about the clock (basically, whether or not it pauses during system 
> sleep) are edge-cases which can be handled for the majority of users with a 
> sensible default value

I’m going to stay out of the naming part of the conversation for the moment and 
just address this point…

I disagree strenuously: it’s a super important distinction that is frequently 
the cause of subtle but bad bugs!

Lets start with the fact that you (presumably not the novice user you describe 
below) actually got the difference between the two clocks wrong.  Here’s the 
current behavior (on Darwin, not sure what Linux currently implements):

  - DispatchTime is a clock that only advances forward and tracks the amount of 
time the computer is awake.

  - DispatchWillTime is a clock that tracks as a UTC clock would, generally 
moving ahead during sleep, but is *not* monotonic.  It can move forward, 
backward, upside down, whatever it wants.  And frequently it will.

And this stuff is hard: if you are writing a tea timer app and you pick either 
of these, you have a bug.  DispatchTime, the bug is that if the user locks 
their device and it falls asleep the alarm won’t fire upon wake.  
DispatchWallTime, if the device realizes its clock is ahead or behind the 
“real” time the elapsed duration won’t be what you expect.  (Should we have a 
third that works for the tea timer? Absolutely…)

So, what’s the sensible default you had in mind that won’t fail for a large 
portion of use cases?  Safety is an important design point in an API surface 
and making these distinctions clear to developers is absolutely critical to 
achieving that goal.

(Of course, Foundation.Timer gets all of the above horribly wrong, IMHO.  We 
should fix that too…)

>  (the monotonic and walltime clocks are actually split at the type level)

DispatchTime is not a monotonic clock.  At least, not in the POSIX sense.  So 
let’s not call it that.  (Linux’s failure to implement POSIX correctly 
notwithstanding.)

> Novice users are not going to understand what’s going on here - I expect most 
> of them to default to the more generic-sounding “DispatchTime” without any 
> idea of the implications of this.

If that’s the case, that’s a good argument for forcing users to make the choice 
in an even more obvious and explicit way.  Not making it easier to use one or 
the other when they’ll likely get it wrong.

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

2016-07-13 Thread Erica Sadun via swift-evolution

We removed "of" from the final version:

https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md
 


And moved it to "If for some reason, the core team decides that there's a 
compelling reason to include value calls, an implementation might look 
something like this" instead.

Dave expressed that this should be something that operates on types not values.

-- E


> On Jul 12, 2016, at 2:43 PM, Jordan Rose  wrote:
> 
> Sorry to only come across this now. The proposed implementation does not work.
> 
> public static func of(_ candidate : @autoclosure () -> T) -> 
> MemoryLayout.Type {
>   return MemoryLayout.init(candidate).dynamicType
> }
> 
> let value: Any = 2 // dynamicType is Int
> let layout = MemoryLayout(value).dynamicType // inlined from above
> let arrayType = [value].dynamicType
> 
> ‘layout’ here is still 'MemoryLayout', not 'MemoryLayout', for the 
> same reason that ‘arrayType’ is ‘Array’ rather than ‘Array’.
> 
> If we want to support sizeofValue et al, we’d need to make these instance 
> properties rather than static properties, and may then want to give up on the 
> struct being generic.
> 
> Jordan

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

[swift-evolution] [Accepted] SE-0086 "Drop NS Prefix in Swift Foundation"

2016-07-13 Thread Douglas Gregor via swift-evolution

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md

The review of SE-0086 "Drop NS Prefix in Swift Foundation” ran from May 9…16, 
2016. The proposal is *accepted*.

This proposal has evolved greatly from a single bullet item in the original 
proposal for improving the translation of Objective-C APIs (SE-0005: Better 
Translation of Objective-C APIs Into Swift 
).
 Discussion spawned the transformative work on Foundation value types (SE-0069: 
Mutability and Foundation Value Types 
),
 and other improvements to the mapping of Objective-C APIs into Swift (e.g., 
SE-0033: Import Objective-C Constants as Swift Types 
,
 SE-0044: Import as Member 
,
 SE-0112: Improved NSError Bridging 
)
 have informed and improved this proposal.

Big thanks to Tony Parker and Philippe Hausler for driving this proposal (and 
Foundation in Swift) forward!

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

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I see model of Type as follows:

   1. Values of Type are identifiers of types (8 bytes, I guess)
   2. All used identifiers are contained in Type
   3. Type contains a subset of those identifiers
   4. Type are usually created with default constructor Type()
   5. Upcasting uses constructor init(upcasting: Type)
   6. Checking for conformance uses method isSubtype(of:)
   7. Size of Type is 8, static size of Type is 0

2016-07-13 18:25 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:
>
> a = SomeClass.self
>
> expectTrue(a as? Any.Type == SomeClass.self)
> expectTrue(a as? AnyClass == SomeClass.self)
> expectTrue(a as? SomeClass.Type == SomeClass.self)
>
> That example just demonstrates syntax of metatypes and does not count.

>
>-
>
>What about dynamicType?
>
> It should have the following signature:

func dynamicType(_ var: T) -> Type

To return Type means to return an identifier of U: T
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

#1 - 

Currently, DispatchQueue.after() takes an absolute time as the “after” 
parameter. This makes it hard to understand how to use it; you need to go 
digging through generated interfaces to find out what a ‘DispatchTime’ is and 
how you construct it (by getting the .now() and adding a DispatchTimeInterval 
using one of the easily-missable operator overloads, if you were wondering).

Here is what DispatchQueue.after looks like now:

public func after(when: DispatchTime, qos: DispatchQoS = .unspecified, flags: 
DispatchWorkItemFlags = [], execute work: @convention(block) () -> Void)

So to use it, you have to type:

DispatchQueue.main.after(when: DispatchTime.now() + .milliseconds(250))   { /* 
do stuff */ }

I don’t believe this is a great fit with the Swift API Guidelines. I believe 
the name “after” already implies that the time is relative, the argument label 
should be dropped, and that nuances about the clock (basically, whether or not 
it pauses during system sleep) are edge-cases which can be handled for the 
majority of users with a sensible default value (or better yet, modelling via 
an enum or boolean switch — see #2). Additionally, There are overloads with 
“wallTime” parameter labels which seem only to duplicate type information (the 
monotonic and walltime clocks are actually split at the type level) and could 
be more concise and readable. The principle is that, ultimately, you should 
just be able to write the above code like this:

DispatchQueue.main.after(.milliseconds(250)) { /* do stuff */ }

Or

DispatchQueue.main.at(DispatchTime.now() + .seconds(3)) { /* do stuff */ }

It’s not something you use all the time (like .sync/.async), but I find that 
whenever I do need it I’m frustrated by how needlessly complex it is to 
decipher and use. I would find these methods much more obvious, I could figure 
out how to use them much more quickly, and I think I’d remember how to use them 
more quickly.

—

#2 - 

Actually, while writing this down it’s becoming clearer and clearer that the 
idea to split DispatchTime (the monotonic clock) and DispatchWallTime (the wall 
clock) at the type level is probably a bad idea.

Novice users are not going to understand what’s going on here - I expect most 
of them to default to the more generic-sounding “DispatchTime” without any idea 
of the implications of this. Perhaps we should look at replacing these clock 
variations with a more descriptive enum or boolean, rather than a separate 
type. For example:

struct DispatchTime {   // replaces DispatchTime and 
DispatchWallTime
let rawValue : dispatch_time_t
let clock : Clock

enum Clock { case monotonicClock; case wallClock }
}

This would not obsolete the discussion at the start about “after”. The name 
“after” still implies that I want something done at some duration relative to 
an absolute point in time (usually now).

Thoughts? 
There have been some really in-depth naming discussions on here recently, so 
I’m interested to hear what you make of it.

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

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

2016-07-13 Thread Ankit Agarwal via swift-evolution

On Wed, Jul 13, 2016 at 9:27 PM, Anders Bertelrud  wrote:

> Thanks for taking the initiative for this, Ankit.  It's a very welcome
> improvement.
>
> Comments inline.
>
> On 2016-07-12, at 11.15, Ankit Agarwal via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
> To mark a target as exported/public I propose PackageDescription's Target 
> gains
> a flags property which would be a Set of the following Flag enum declared
> inside Target class:
>
> public enum Flag {
> /// Makes the target public or "exported" for other packages to use.
> case public}
>
> The Flag enum will be flexible in case we need to add more attributes in
> future as opposed to a boolean property to mark the public nature of the
> target.
>
> I would prefer that this be a boolean parameter rather than a generic
> `flags` parameter, since it makes the manifest read more naturally, and,
> importantly, is no less extensible than an enum.  Additional parameters
> with default values can as easily be added as more enum cases can, and in
> either case, a manifest written to assume the existence of `public` will be
> equally incompatible with older versions of the package manager.
>
> So, for example:
>
> let package = Package(
>name: "FooLibrary",
>targets: [
>Target(name: "FooLibrary", public: true),
>Target(name: "SampleCLI", dependencies: ["FooLibrary"]),
>])
>
> We can keep some obvious defaults for targets which can be implicitly
> public for e.g.
>
>1. Package has only one target.
>2. Target with same name as package.
>
> I'm a bit wary of magic here.  I think it would be clearer to have the
> manifest declare what is public and what is not.  With magic naming
> conventions it's too easy to accidentally change semantics just by renaming
> a target.
>

I agree that we should avoid too much magic, I think you missed the
sentence below those examples in the proposal where I mentioned that we
should avoid those instead. However as Daniel mentioned we don't want to
overcomplicate the manifest for simple packages and for beginners, keeping
that in mind we updated the proposed solution which you can find on the
proposal link (
https://github.com/aciidb0mb3r/swift-evolution/blob/swiftpm-module-access-control/proposals/-swiftpm-target-access-control.md
)


> I propose that enum Target.Dependency gains a new case External(package:
> String, target: String) to declare dependency on an external package's
> target.
>
> Since it's the same fundamental kind of dependency in either case, would
> it be better to have `package` be an optional parameter to Target?
>
> So that `Target(name: "Foo")` is local but `Target(name: "Foo", package:
> "Bar")` external?  That would seem more logical.
>
>
I like `Target(name: "Foo", package: "Bar")` but I prefer package name is
stated before the target name `Target(package: "Foo", name: "Bar")` but
then this gets weird and `Target(package:target)` is also weird so I chose
`External(package:target)` instead. However if people prefer
`Target(name:package)` more then I am fine with it.

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

Re: [swift-evolution] [swift-dev] Bugs not reproducible on master

2016-07-13 Thread Robert Widmann via swift-evolution

Can't speak for everybody else, but I leave them a comment letting them know, 
try to find a pull request or commit that would have fixed it and close it if I 
can find one.  Otherwise, a lot of times IBM's exhaustive catalogue of Swift 
releases on bluemix can usually reproduce tricky SRs.

~Robert Widmann

2016/07/13 6:16、Alex Hoppen via swift-dev  のメッセージ:

> I’m currently crawling bugs.swift.org for bugs to fix and regularly encounter 
> bugs which I cannot reproduce on master anymore. What’s the standard protocol 
> for them? Close them with resolution "Can’t Reproduce" or "Done" or just add 
> a comment and let the reporter close it?
> 
> – Alex
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

2016-07-13 Thread Anders Bertelrud via swift-evolution

Thanks for taking the initiative for this, Ankit.  It's a very welcome 
improvement.

Comments inline.

On 2016-07-12, at 11.15, Ankit Agarwal via swift-build-dev 
 wrote:
> To mark a target as exported/public I propose PackageDescription's Target 
> gains a flags property which would be a Set of the following Flag enum 
> declared inside Target class:
> 
> public enum Flag {
> /// Makes the target public or "exported" for other packages to use.
> case public
> }
> The Flag enum will be flexible in case we need to add more attributes in 
> future as opposed to a boolean property to mark the public nature of the 
> target.
> 
I would prefer that this be a boolean parameter rather than a generic `flags` 
parameter, since it makes the manifest read more naturally, and, importantly, 
is no less extensible than an enum.  Additional parameters with default values 
can as easily be added as more enum cases can, and in either case, a manifest 
written to assume the existence of `public` will be equally incompatible with 
older versions of the package manager.

So, for example:

let package = Package(
   name: "FooLibrary",
   targets: [
   Target(name: "FooLibrary", public: true),
   Target(name: "SampleCLI", dependencies: ["FooLibrary"]),
   ])
> We can keep some obvious defaults for targets which can be implicitly public 
> for e.g. 
> 
> Package has only one target.
> Target with same name as package.
I'm a bit wary of magic here.  I think it would be clearer to have the manifest 
declare what is public and what is not.  With magic naming conventions it's too 
easy to accidentally change semantics just by renaming a target.
> I propose that enum Target.Dependency gains a new case External(package: 
> String, target: String) to declare dependency on an external package's target.
> 
Since it's the same fundamental kind of dependency in either case, would it be 
better to have `package` be an optional parameter to Target?

So that `Target(name: "Foo")` is local but `Target(name: "Foo", package: 
"Bar")` external?  That would seem more logical.

Anders


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

Re: [swift-evolution] [Pitch] Giving functions default return values

2016-07-13 Thread Charlie Monroe via swift-evolution

Hi Tim,

the core team asked us to defer any discussion on post-Swift-3 related 
proposals.

That said, there have been several discussion around this topic (in the past 
few months) and I believe the general attitude towards them was negative, due 
to it leading to statements such as 

guard  else { }

which

a) doesn't express what will happen when the condition is not met, making the 
code hard to read

b) can lead to bugs in code since the compiler makes sure that the flow doesn't 
continue beyond the guard statement and with default returns, this would 
compiler without a warning or an error:

for obj in array {
guard obj.meetsConditions() else {
// Implicit return - most likely not intentional,
// you most likely want "continue" in here
}

// ...
}


> On Jul 13, 2016, at 4:57 PM, Tim Vermeulen via swift-evolution 
>  wrote:
> 
> This idea is purely additive and isn’t to be considered for Swift 3.
> 
> Oftentimes a function has a very obvious default argument to fall back on. If 
> the return value is optional, this is generally nil. If the return value is 
> Bool, it’s probably `false`. Often this fallback value is returned at the end 
> of the function, just to return something if nothing has been returned yet. 
> For instance, consider this TreeNode class:
> 
> class TreeNode {
> 
> var value: Element
> var children: [TreeNode]
> 
> init(value: Element) {
> self.value = value
> children = []
> }
> 
> func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool {
> if try predicate(value) {
> return true
> }
> 
> for child in children {
> if try child.contains(predicate) {
> return true
> }
> }
> 
> return false // 1
> }
> 
> func first(where predicate: (Element) throws -> Bool) rethrows -> 
> Element? {
> if try predicate(value) {
> return value
> }
> 
> for child in children {
> if let result = try child.first(where: predicate) {
> return result
> }
> }
> 
> return nil // 2
> }
> 
> var leftMostDescendant: TreeNode? {
> if let child = children.first {
> return child.leftMostDescendant ?? child
> }
> 
> return nil // 3
> }
> 
> }
> 
> These code patterns are quite usual. If we could give default return values 
> to functions, we could get rid of the final `return` statements:
> 
> func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool = false 
> {
> if try predicate(value) {
> return true
> }
> 
> for child in children {
> if try child.contains(predicate) {
> return true
> }
> }
> }
> 
> func first(where predicate: (Element) throws -> Bool) rethrows -> Element? = 
> nil {
> if try predicate(value) {
> return value
> }
> 
> for child in children {
> if let result = try child.first(where: predicate) {
> return result
> }
> }
> }
> 
> var leftMostDescendant: TreeNode? = nil {
> if let child = children.first {
> return child.leftMostDescendant ?? child
> }
> }
> 
> The default return value shouldn’t be part of the function signature (i.e. it 
> shouldn’t appear in interface files) because it’s an implementation detail, 
> but right after the return type is probably the most natural place to put it 
> (similar to default function parameters).
> 
> Let me know what you think.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
>
> * What is your evaluation of the proposal?
>
> -1. Extensions appear to me to follow the access control of the rest of
> Swift: Implicit to the type you are extending, and you can either / both
> declare as part of the extension declaration or on the method. I don’t see
> how this is confusing, and I expect people will be more confused that
> extensions don’t follow the convention of the rest of Swift for Access
> Control.
>

So, actually, the proposal is correct that extensions (at least once
fileprivate/private is implemented) don't follow the access control rules
for the rest of Swift. There is a problem to be addressed. However, I agree
that this proposal hasn't identified the issue or adequately explained how
the solution solves it. Here's the problem I'm thinking of:

```
public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}
```

This is an inconsistency that may (and IMO, really is) worth addressing. If
there's adequate interest, I can circulate a draft with a proposed solution
I have in mind.


>
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
>
> I don’t think this warrants a change.
>
> * Does this proposal fit well with the feel and direction of Swift?
>
> No. This seems to go against the 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?
>
> No.
>
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> A reading of the proposal.
>
>
> ___
> 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] Fixing the confusion between non-mutating algorithms and single-pass sequences

I also thought on the problem, and I agree with your solution. It keeps
things simple.
I agree with this specific name -- IterableOnce (not IterableAtLeastOnce).
IterableOnce contains Iterable -- and that plays very nicely with
IteratorProtocol name.
IterableOnce is not a single word, but it's not too long, compared to some
other options.
Functions working with IterableOnce will always imply single-pass, and with
Collections -- multi-pass. It might seem odd that Collection conforms to
IterableOnce, but I consider that a minor drawback.

2016-07-13 1:55 GMT+03:00 Dmitri Gribenko via swift-evolution <
swift-evolution@swift.org>:

> Hi,
>
> I'd like to continue the discussion of the issue raised by David Waite
> inhttp://thread.gmane.org/gmane.comp.lang.swift.evolution/21295/:
>
> > My main motivation for proposing this is the potential for developer
> confusion. As stated during one of the previous threads on the naming of
> map, flatMap, filter, etc. methods on Sequence, Sequence has a naming
> requirement not typical of the rest of the Swift standard library in that
> many methods on Sequence may or may not be destructive. As such, naming
> methods for any extensions on Sequence is challenging as the names need to
> not imply immutability.
>
> I'd like to focus on a particular point: methods on Sequence can
> consume elements, but the APIs are not markedmutating.
>
> Dave Abrahams, Max Moiseev, and I have discussed this issue and we
> agree this problem is severe and worth solving, we also think that the
> likely solutions would be source-breaking, so it is important that we
> discuss it now.
>
> We have discussed a few options.
>
> - Rejected option: remove Sequence, let IteratorProtocol model
> single-pass data streams
>
> - Rejected option: use a syntactic marker, like sequence.consumedIn.map {}
>
> - Rejected option: mutating APIs on Sequence, non-mutating APIs on
> Collection
>
> Proposed: rename Sequence to IterableOnce or TraversableOnce. We think
> that Sequence does not convey the single-pass restriction clearly. The
> term "sequence" has been used in math (as in "integer sequence"), and
> since the math domain does not have mutation, "sequence" can be
> understood to mean "multi-pass", since you can traverse a sequence of
> integers an arbitrary number of times.
>
> We think that only the last option is viable in the Swift language as
> it exists now, without creating an undue burden for API vendors and
> users.
>
> For more details about rejection options, please see the full writeup:
> https://gist.github.com/gribozavr/47f4717f3afc762549383e94da7f748b
>
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

>
> * What is your evaluation of the proposal?
>

-1. I think the proposal has great technical merit; if implemented, it
would improve the developer experience and pave the way for other
improvements in expressivity in the future. However, the proposal doesn't
do what it says on the tin (aka in the title), and it fails to explain the
motivation behind it or the rationale for the specific solution proposed.
My first reaction on reading it was exactly the same as that of Jose Cheyo
Jimenez, because it seemed not to do what it advertised at all. Since input
from the community is important, a proposal that doesn't explain the
problem or solution adequately can't be subjected to the scrutiny it needs
before implementation, and unfortunately I'll have to give it a thumbs-down.

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

There is a problem to be addressed, and I think that problem is
significant. However, it's not really explained in the proposal.


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

Potentially.


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

I have not.


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

I thought about this in-depth and participated in the original discussion
about revisions to SE-0025 that revised how access levels are treated for
classes, structs, and enums.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

2016-07-13 Thread Daniel Dunbar via swift-evolution


> On Jul 13, 2016, at 1:56 AM, Honza Dvorsky  wrote:
> 
> Very happy to see this proposal, thanks Ankit for pushing it forward! I can't 
> wait to be able to hide many example executables in my packages, as I've been 
> getting a steady stream of complaints from people being annoyed about the 
> polluted compilation log and slower compilation times.
> 
> However I'm leaning towards keeping the default module visibility to public, 
> not private. I appreciate all the arguments that compare targets with code in 
> Swift, where the default is internal - and it makes sense. But the more 
> pragmatic side of me feels that it might become a piece of boilerplate we'll 
> have to write in our manifests for a long time, without much benefit (but 
> with regret). And adding magic to sometimes export by default (single module 
> packages or modules matching the packages name) IMO just complicates the 
> conceptual model of how SwiftPM treats package manifests. I think we should 
> be very careful with adding such nonlinear behaviors (where e.g. adding 
> another module suddenly breaks the package's visible targets), and in this 
> case I don't believe it's justified. (That's while completely ignoring the 
> fact that such a change would break 100% of packages out there, which could 
> be a toll on the good will the project seems to have right now. Not that we 
> should never make breaking changes, I just feel we should give a good reason 
> we're making them, potentially to allow a new feature. Which is not the case 
> here.) 

I agree, this is a big concern of mine as well.

Ankit and I discussed this at length last night and he has updated the proposal 
here:
  
https://github.com/aciidb0mb3r/swift-evolution/blob/swiftpm-module-access-control/proposals/-swiftpm-target-access-control.md
 


> That's my two cents. :)
> 
> Overall I'm enthusiastic about this proposal, it will solve a few real issues 
> I'm having with my projects! 
> 
> While I don't think we should add this to the proposal - it might be very 
> useful to add a mode to SwiftPM that dumps the module visibility information. 
> I think that should be added regardless of what the default visibility ends 
> up being.

I agree. I would like a `swift package describe` which shows how the convention 
system and manifest are causing the package to be interpreted. It would show 
things like the targets, dependencies, etc.

 - Daniel

> Something like:
> $ swift package show-target-visibility
> Found 3 modules
> 
> Public:
> Foo
> 
> Private:
> PrivateBar
> ExampleFoo
> 
> - Honza
> 
> On Tue, Jul 12, 2016 at 8:16 PM Ankit Agarwal via swift-build-dev 
> > wrote:
> I have updated the proposal accommodating recent discussion
> 
> Link: 
> https://github.com/aciidb0mb3r/swift-evolution/blob/swiftpm-module-access-control/proposals/-swiftpm-target-access-control.md
>  
> 
> 
> SwiftPM Target Access Control
> Proposal: SE- 
> 
> Author: Ankit Aggarwal 
> Status: In Discussion
> Review manager: TBD
> Introduction
> This proposal aims to address two issues:
> 
> Control over the targets exposed (and built) when a SwiftPM package is used 
> as a dependency i.e. the targets which are exported and can be used in other 
> packages.
> 
> Specify external target dependencies of a target.
> 
> swift-evolution thread 
> 
> Motivation
> 1. Control over exposed targets:
> 
> SwiftPM allows multiple targets (or modules) inside a package. Most of the 
> time package author will want to provide one (or more) stable public/exported 
> target which should be utilised by other packages. We should actively 
> discourage use of targets which are not meant to be imported by other 
> packages.
> 
> Additionally packages usually contain sample usage or example targets which 
> are useful during development or testing of the package but are redundant 
> when the package is used as a dependency. This increases compilation time for 
> the user of the package which can be avoided.
> 
> As a concrete example: Vapor has a target called Development 
> .
> 
> 2. Specify external target dependencies of a target:
> 
> Currently all the targets of an external dependency are implicitly built and 
> exposed to the user package. This works well for one target package but 
> becomes unclear which targets are using which target of an external 
> dependency.
> 
> Moreover user

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 Thread Adrian Zubarev via swift-evolution

Okay I’m convinced on that one, but do we really want to give up being able to 
construct an instance from an metatype instance? (Personally I’d keep it as an 
optional feature.)

There are more than 7000 search results inside swift repository for .Type.

I looked up a few of them and I found an interesting example:

a = SomeClass.self
expectTrue(a as? Any.Type == SomeClass.self)
expectTrue(a as? AnyClass == SomeClass.self)
expectTrue(a as? SomeClass.Type == SomeClass.self)
After this proposal we had this:

a: Type = SomeClass

// How can we cast from `Type` to `Type`?
// Comparing two Type is done with `hashValue` at least in my
// implementation.
expectTrue(a as? Type == SomeClass) // `SomeClass` equals 
`Type()`

// How can we cast `Type` to `AnyClass`?
expectTrue(a as? AnyClass == SomeClass)

// this is fine
expectTrue(a as? Type == SomeClass)
Dynamic casts do not work with other instances of metatypes (I feel like there 
was a proposal for this, but I can’t find it). If we had this, we could fix the 
infix == function to compare metatypes instead the hash value.

What about dynamicType?

Any ideas?



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 16:17:43, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

2016-07-13 15:02 GMT+03:00 Adrian Zubarev via swift-evolution 
:
To answer your question, we still need the metatype to access initializer and 
static member of that type. If we’d drop T.Type completely, we’d lose 
functionality to do so.

protocol A {
init()
}

func foo(metatype: T.Type) -> T {
return metatype.init()
}
In such cases, we can always refer to the type directly:
func foo(metatype: Type) -> T {
return T()
}
I would prefer to remove metatypes T.Type completely and replace them with your 
somewhat transparent Type.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Giving functions default return values

2016-07-13 Thread Tim Vermeulen via swift-evolution

This idea is purely additive and isn’t to be considered for Swift 3.

Oftentimes a function has a very obvious default argument to fall back on. If 
the return value is optional, this is generally nil. If the return value is 
Bool, it’s probably `false`. Often this fallback value is returned at the end 
of the function, just to return something if nothing has been returned yet. For 
instance, consider this TreeNode class:

class TreeNode {

var value: Element
var children: [TreeNode]

init(value: Element) {
self.value = value
children = []
}

func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool {
if try predicate(value) {
return true
}

for child in children {
if try child.contains(predicate) {
return true
}
}

return false // 1
}

func first(where predicate: (Element) throws -> Bool) rethrows -> Element? {
if try predicate(value) {
return value
}

for child in children {
if let result = try child.first(where: predicate) {
return result
}
}

return nil // 2
}

var leftMostDescendant: TreeNode? {
if let child = children.first {
return child.leftMostDescendant ?? child
}

return nil // 3
}

}

These code patterns are quite usual. If we could give default return values to 
functions, we could get rid of the final `return` statements:

func contains(_ predicate: (Element) throws -> Bool) rethrows -> Bool = false {
if try predicate(value) {
return true
}

for child in children {
if try child.contains(predicate) {
return true
}
}
}

func first(where predicate: (Element) throws -> Bool) rethrows -> Element? = 
nil {
if try predicate(value) {
return value
}

for child in children {
if let result = try child.first(where: predicate) {
return result
}
}
}

var leftMostDescendant: TreeNode? = nil {
if let child = children.first {
return child.leftMostDescendant ?? child
}
}

The default return value shouldn’t be part of the function signature (i.e. it 
shouldn’t appear in interface files) because it’s an implementation detail, but 
right after the return type is probably the most natural place to put it 
(similar to default function parameters).

Let me know what you think.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 Thread Brent Royal-Gordon via swift-evolution

2016-07-13 15:02 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:
>
> To answer your question, we still need the metatype to access initializer
> and static member of that type. If we’d drop T.Type completely, we’d lose
> functionality to do so.
>
> protocol A {
> init()
> }
>
> func foo(metatype: T.Type) -> T {
> return metatype.init()
> }
>
> In such cases, we can always refer to the type directly:

func foo(metatype: Type) -> T {
return T()
}

I would prefer to remove metatypes T.Type completely and replace them with
your somewhat transparent Type.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0120: Revise 'partition' Method Signature

2016-07-13 Thread Károly Lőrentey via swift-evolution

* What is your evaluation of the proposal?

+1; I like the new design, and I think once in a blue moon I may
actually use the new API.

I remember looking up partition in the stdlib docs, sighing and moving
on once or twice. It seemed easier to write an explicit loop than to
hammer my problem into the shape of the old API.

Nitpick: In the "Impact on Existing Code", the sample code for the
replacement ignores the return value.

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

I guess so; although it is a fix for a super minor problem, the
proposed change is equally nonintrusive.

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

Sure.

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

As Paul noted, Haskell and Ruby have nonmutating methods for the same
thing. It's fine to delay adding other variants for now.

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

Quick reading plus superficial research.

--
Karoly
@lorentey

On 2016-07-12 18:12:18 +, Chris Lattner via swift-evolution said:

Hello Swift community,

The review of "SE-0120: Revise ‘partition' Method Signature" begins now
and runs through July 19. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.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

--
Károly
@lorentey

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

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 Thread Adrian Zubarev via swift-evolution

This isn’t a full proposal (yet). We still can change things. I didn’t consider 
everything and can’t to that on my own. Feedback is welcome.

To answer your question, we still need the metatype to access initializer and 
static member of that type. If we’d drop T.Type completely, we’d lose 
functionality to do so.

protocol A {
init()
}

func foo(metatype: T.Type) -> T {
return metatype.init()
}
The downside of this proposal is the bottleneck property to access that 
functionality, otherwise adding Hashable or other things like size 
(MemoryLayout) won’t be possible without serious compiler magic. So do I 
believe.

func foo(type: Type) -> T {
return type.metatype.init()
}
This is huge tradeoff, but it’s worth considering if the community can life 
with that.

Furthermore as already been mentioned in this thread, we might consider to 
extend Type to add reflection functionality to it. (If we’d decide to go in 
that direction.)



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 13:15:02, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

Why can't we drop metatypes T.Type with your proposal? Do they bring some extra 
capabilities over Type struct? 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

> On Jul 12, 2016, at 4:53 PM, Chris Lattner  wrote:
> 
>   * What is your evaluation of the proposal?

I think grouping these into a type is a sensible approach, but I don't like 
that it allows the creation of meaningless MemoryLayout instances. The simplest 
fix would be to make `MemoryLayout` an empty enum instead of an empty struct. 
This would convey that no MemoryLayout instances do or can exist.

However, I'm also not really a fan of the way this reads. `MemoryLayout` 
is an unnatural way to access this functionality, quite different from how 
generics are typically used. The heavy use of type members, with instance 
behavior as a complete afterthought, is very unusual. If we are serious about 
use sites being the most important thing, we ought to be concerned about these 
use sites.

I would prefer to see an instance-centric version of this design, with use 
sites along the lines of:

MemoryLayout(of: Int.self).size
let buffer = UnsafeRawPointer.allocate(bytes: MemoryLayout(of: 
Int.self).stride * count)

If the problem is that it would sometimes misbehave—for instance, when someone 
tries to construct a MemoryLayout instance from a `type(of:)` call—then we 
should make it behave correctly, or at least consider it a bug to be fixed 
eventually.

(Incidentally, I notice that the ABI documentation lists the size, alignment, 
and stride as part of the type's value witness table. 

 Would it make sense to think of this as exposing the value witness table as a 
user-visible type? How might that be different from what's being proposed here?)

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

Yes. We need to lock this down.

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

See my comment above about how it reads.

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

Well, it *is* more coherent and less magical than the C family.

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

Quick reading, but I've chimed in during previous discussions (though not in 
this latest round—family duties have kept me from my mail client).

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`