Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Charles Srstka via swift-evolution]

> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> - Second is that clients of some other public API vended by a non-Apple 
> framework (e.g. a SwiftPM package) may end up in a situation where the 
> framework author didn’t consider subclass-ability, but the client desires it. 
>  In this situation, the core team feels that a bigger problem happened: the 
> vendor of the framework did not completely consider the use cases of the 
> framework.  This might have happened due to the framework not using 
> sufficient black box unit testing, a failure of the imagination of the 
> designer in terms of use cases, or because they have a bug in their framework 
> that needs unanticipated subclass-ability in order to “get a job done”.

Or because the framework was developed in the real world, rather than Elysium, 
and real-world framework developers just about *never* anticipate every single 
way someone might use their framework (Indeed, if developers were capable of 
such a thing, there would be no need for third-party software in the first 
place).

Charles

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

Re: [swift-evolution] executing a string

[Josh Parmenter via swift-evolution]

I could see a method being implemented that does something bad, but isn’t 
called directly anywhere in code. A code path analysis of a program may miss 
the problematic method (though unlikely?). But if the method signature is 
passed in dynamically as the result of a web call or something, it could then 
be called and cause a problem. However- the malicious code here really is 
already in the binary.

Since app store review is mentioned here, I can’t speak as to how a binary is 
inspected for review, or what tools the app store team has at its disposal. But 
I would be surprised if there isn’t at least some sort of automated step that 
would reveal the code block that might be problematic. And finding another 
instance where calling something by selector would also raise a flag (in fact, 
even Xcode points out the possibility of a leak in these cases). Yes - it MIGHT 
be problematic, but I think there are greater security holes in the iOS / Obj-C 
ecosystem than what is mentioned here. Since it is a compiled language, and 
apps don’t ship with compilers, it seems like the possibility for abuse here is 
not huge. However - many iOS apps can execute JavaScript or create WebViews 
with strings from just about any source - and this is where (it seems to mean) 
a strong sandboxing environment is really needed. But I am curious to know 
(like Félix) if there are examples of this happening.

Best,

Josh

On Jul 14, 2016, at 10:18 PM, Félix Cloutier via swift-evolution 
> wrote:

I've never heard of an app being exploited through selector abuse. Do you have 
any example of that?

Félix

Le 14 juil. 2016 à 08:48:53, Ford Prefect via swift-evolution 
> a écrit :

One of the major security flaws of Obj C is
the ability to convert a string into a selector, which
permits using private methods by constructing selectors
at runtime long after the app store review has been completed.
Does Swift do away with that? I understand it doesn't
use selectors per se but is there an analogous mechanism?

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

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

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

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Charlie Monroe via swift-evolution]

> On Jul 14, 2016, at 11:39 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> To sum this all up, the core team is rejecting this proposal and requesting a 
> revision to change the concrete syntax to “public open class Foo” instead of 
> “subclassable class Foo".  This approach satisfies the *unwavering* goal of 
> requiring additional thought when publishing a class as public API, makes 
> subclass-ability orthogonal to access control, and (admittedly as a bit of a 
> swift-evolution process hack) asks the community for an in-depth discussion 
> of the secondary points of the proposal: does it make sense to require every 
> member to be marked as “overridable” in order to be overridden by an open 
> subclass outside of the current module?

+1 on open instead of subclassable.

As per the overridability I'm coming back and forth. There are certainly 
classes where you want just a few things to be overridable and then there are 
classes where you want almost everything overridable.

I would personally prefer not overridable by default, but also an addition of a 
modifier on open that would allow to specify default overridability:

// by default everything is overridable
open(override) class Bar

Alternatives: open(members), open(all)

This, however, requires a new keyword for "closing" a member within the module:

// Not allowed overriding beyond the module.
closed func foo()

BTW I'm not a fan of the keyword "overridable" at all. Imagine that you 
subclass the class in another module, override the method and expose it for yet 
another module and keep the overridability:

overridable override func foo()

I'd prefer the open keyword to be reused here.

> 
>  -Chris
> 
> ___
> 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] executing a string

[Félix Cloutier via swift-evolution]

I've never heard of an app being exploited through selector abuse. Do you have 
any example of that?

Félix

> Le 14 juil. 2016 à 08:48:53, Ford Prefect via swift-evolution 
>  a écrit :
> 
> One of the major security flaws of Obj C is
> the ability to convert a string into a selector, which
> permits using private methods by constructing selectors
> at runtime long after the app store review has been completed.
> Does Swift do away with that? I understand it doesn't
> use selectors per se but is there an analogous mechanism?
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Chris Lattner via swift-evolution]

When/if we get an async/await like feature, of course we’ll try to pull 
completion handlers automatically into the model.  We can do that post swift 3.

-Chris

> On Jul 14, 2016, at 3:30 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> Right, but since this would affect the Obj-C importer and thus would be a 
> source-breaking change, it would probably not be possible anymore after Swift 
> 3.
> 
> Charles
> 
>> On Jul 14, 2016, at 4:57 PM, Dan Stenmark  
>> wrote:
>> 
>> I’d say it’s a little premature to be talking about this; the team has made 
>> it very clear that the discussion on Native Concurrency in Swift won’t begin 
>> for another couple months.
>> 
>> Dan
>> 
>>> On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution 
>>>  wrote:
>>> 
>>> I know it’s late, but I was wondering what the community thought of this:
>>> 
>>> MOTIVATION:
>>> 
>>> With the acceptance of SE-0112, the error handling picture looks much 
>>> stronger for Swift 3, but there is still one area of awkwardness remaining, 
>>> in the area of returns from asynchronous methods. Specifically, many 
>>> asynchronous APIs in the Cocoa framework are declared like this:
>>> 
>>> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
>>> _Nullable, NSError * _Nullable))completionHandler;
>>> 
>>> This will get imported into Swift as something like this:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
>>> 
>>> The intention of this API is that either the operation will succeed, and 
>>> something will be passed in the Bar parameter, and the error will be nil, 
>>> or else the operation will fail, and then the error parameter will be 
>>> populated while the Bar parameter is nil. However, this intention is not 
>>> expressed in the API, since the syntax leaves the possibility that both 
>>> parameters could be nil, or that they could both be non-nil. This forces 
>>> the developer to do needless and repetitive checks against a case which in 
>>> practice shouldn’t occur, as below:
>>> 
>>> doSomething(foo: foo) { bar, error in
>>> if let bar = bar {
>>> // handle success case
>>> } else if let error = error {
>>> self.handleError(error)
>>> } else {
>>> self.handleError(NSCocoaError.FileReadUnknownError)
>>> }
>>> }
>>> 
>>> This results in the dreaded “untested code.”
>>> 
>>> Note that while it is possible that the developer could simply force-unwrap 
>>> error in the failure case, this leaves the programs open to crashes in the 
>>> case where a misbehaved API forgets to populate the error on failure, 
>>> whereas some kind of default error would be more appropriate. The 
>>> do/try/catch mechanism works around this by returning a generic _NilError 
>>> in cases where this occurs.
>>> 
>>> PROPOSED SOLUTION:
>>> 
>>> Since the pattern for an async API that returns an error in the Cocoa APIs 
>>> is very similar to the pattern for a synchronous one, we can handle it in a 
>>> very similar way. To do this, we introduce a new Result enum type. We then 
>>> bridge asynchronous Cocoa APIs to return this Result type instead of 
>>> optional values. This more clearly expresses to the user the intent of the 
>>> API.
>>> 
>>> In addition to clarifying many Cocoa interfaces, this will provide a 
>>> standard format for asynchronous APIs that return errors, opening the way 
>>> for these APIs to be seamlessly integrated into future asynchronous 
>>> features added to Swift 4 and beyond, in a way that could seamlessly 
>>> interact with the do/try/catch feature as well.
>>> 
>>> DETAILED DESIGN:
>>> 
>>> 1. We introduce a Result type, which looks like this:
>>> 
>>> enum Result {
>>> case success(T)
>>> case error(Error)
>>> }
>>> 
>>> 2. Methods that return one parameter asynchronously with an error are 
>>> bridged like this:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Result) -> ())
>>> 
>>> and are used like this:
>>> 
>>> doSomething(foo: foo) { result in
>>> switch result {
>>> case let .success(bar):
>>> // handle success
>>> case let .error(error):
>>> self.handleError(error)
>>> }
>>> }
>>> 
>>> 3. Methods that return multiple parameters asynchronously with an error are 
>>> bridged using a tuple:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())
>>> 
>>> and are used like this:
>>> 
>>> doSomething(foo: foo) { result in
>>> switch result {
>>> case let .success(bar, baz):
>>> // handle success
>>> case let .error(error):
>>> self.handleError(error)
>>> }
>>> }
>>> 
>>> 4. Methods that return only an error and nothing else are bridged as they 
>>> are currently, with the exception of bridging NSError to Error as in 
>>> SE-0112:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Error?) -> ())
>>> 
>>> 

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Chris Lattner via swift-evolution]

On Jul 14, 2016, at 9:33 AM, Ben Rimmington  wrote:
>> 
>> This will restore the ability to express the idea of a closure parameter 
>> that carries labels as part of its declaration, without requiring parameter 
>> labels to be part of the type system (allowing, e.g. the operator + to be 
>> passed into something that requires parameter labels).
> 
> During the review, Michael Ilseman suggested using SE-0021 for declaration 
> names.
> 
>  >
> 
> Your example "op(lhs:,rhs:)" would be "op(lhs:rhs:)" instead (i.e. without 
> the comma).

Ok, sure.  I just trying to outline what the proposal would look like,

-Chris

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

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Chris Lattner via swift-evolution]

> On Jul 14, 2016, at 9:27 AM, Erica Sadun  wrote:
> 
> 
>> On Jul 14, 2016, at 10:01 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jul 14, 2016, at 1:20 AM, Taras Zakharko  wrote:
>>> 
>>> Great!
>>> 
>>> This cleanly separates between the type and the name/signature! Simple and 
>>> consistent. Thank you!
>>> 
>>> A clarification question: do i understand correctly that steps 2 and 3 will 
>>> not be included in Swift 3 due time constraints?
>> 
>> Yes, we are sadly really almost out of time for Swift 3 and need to remain 
>> as hyper-focused as possible.  There is always another release.
>> 
>> -Chris
> 
> I was under the impression that Swift 2.3 was going to go gold in September 
> for App Store submissions and Swift 3 in December. Is my timeline wrong?

Both Swift 2.3 and Swift 3 will GM along with Xcode 8 and iOS 10, whenever that 
ends up being.  Did I say something to contradict that?  I don’t know what 
Swift 2.3 has to do with this thread.

-Chris

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

Re: [swift-evolution] executing a string

[Karl via swift-evolution]

> On 14 Jul 2016, at 17:48, Ford Prefect via swift-evolution 
>  wrote:
> 
> One of the major security flaws of Obj C is
> the ability to convert a string into a selector, which
> permits using private methods by constructing selectors
> at runtime long after the app store review has been completed.
> Does Swift do away with that? I understand it doesn't
> use selectors per se but is there an analogous mechanism?
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

As has been pointed out, Swift selectors are already much safer. I believe you 
can still convert a string to a selector, but really…

I wouldn’t call it a security flaw. Objects in Obj-C are free to pass messages 
around fairly loosely - sometimes the method you are trying to call doesn’t 
even exist but will be dynamically created and hooked up at runtime when you 
call it. This is a good article to learn more about how powerful Obj-C’s 
messaging system is: 
https://www.mikeash.com/pyblog/friday-qa-2009-03-27-objective-c-message-forwarding.html

It’s only a security flaw if you can somehow perform privileged operations from 
doing that. I’m not sure how the jailbreak community actually implements it, 
but I’d assume that to write out to system/non-app files they would need to 
disable sandboxing, which is what really gives you the security that apps won’t 
grab your data or make persistent changes outside of their own containers, or 
talk to the network when they shouldn’t (see: iOS keyboard extensions).

Yeah, you can call non-public APIs. That’s true in basically all software. The 
reason Apple discourages it isn’t for security - it’s so they don’t have to 
maintain code they never promised to maintain. It leads to more stable and 
reliable software.

It’s not really an undocumented API (really an undocumented behaviour), but 
there’s a famous lesson from Microsoft about this:

> Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit 
> software perfectly. Microsoft obsessed about this, spending a big chunk of 
> change testing every old program they could find with Windows 95. Jon Ross, 
> who wrote the original version of SimCity for Windows 3.x, told me that he 
> accidentally left a bug in SimCity where he read memory that he had just 
> freed. Yep. It worked fine on Windows 3.x, because the memory never went 
> anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity 
> wasn't working in testing. Microsoft tracked down the bug and added specific 
> code to Windows 95 that looks for SimCity. If it finds SimCity running, it 
> runs the memory allocator in a special mode that doesn't free memory right 
> away. That's the kind of obsession with backward compatibility that made 
> people willing to upgrade to Windows 95.

If you like that, Raymond Chen’s oldnewthing is a great source of Microsoft 
technical war-stories (https://blogs.msdn.microsoft.com/oldnewthing/). But 
anyway, nobody wants that kind of headache, and then having to maintain those 
hacks for who-knows-how-long? That’s why they’re so strict about using official 
APIs and documented behaviour - because if you don’t, you’ll have to choose 
between breaking software and making users unhappy, or maintaining a collection 
of hacks to present the illusion of the old, never-intended-to-be-final 
behaviour.

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

[Anton Zhilin via swift-evolution]

2016-07-15 3:52 GMT+03:00 Brent Royal-Gordon :

> > On Jul 14, 2016, at 5:24 PM, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Ok, I forgot about it. Type should have all features of T.Type,
> except that Type will not contain static methods of T.
>
> Why? It seems to me like the most natural way to design this by far is to
> have `Type` be the type returned by `type(of:)`, which means it would
> have all static and class members on it.


An example where such behavior is required:

protocol HasStatic { static func staticMethod() }
func callStatic(_ type: HasStatic.Type) {
type.staticMethod()
}

I finally understand the reasons for keeping metatypes T.Type, "sealed"
inside Type. And such a feature would look odd on a struct.

It also seems like `Type`'s type would absolutely have to be
> `Type`, and some form of infinite regress is absolutely necessary
> (though in practice it could probably be simulated by having the first
> metatype with no static members act as its own type, or with some other
> form of lazy instantiation).


I don't see any problems with Type. There is finite number of
types that are used in the program, and compiler can collect and store
information about them all statically. Am I right?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] Proposal status page

[Felipe Cypriano via swift-evolution]

Only talking about the page and its content, since I didn't review the
code and how it works: I love it! I think it would be great to have this
in the official repo.
 
 
On Thu, Jul 14, 2016, at 11:46, Jacob Bandes-Storch via swift-evolution wrote:
> It occurs to me that moving swift-evolution to use *only* a gh-
> pages branch, like swift-internals does, would allow this to work
> without JS.
>
> On Thu, Jul 14, 2016 at 1:30 AM, Jacob Bandes-Storch
>  wrote:
>> I got sidetracked today and mocked up a proposal "status page":
>>
>> http://jtbandes.github.io/swift-evolution/
>>
>> This moves the proposal status info (currently in README.md) into a
>> separate "source of truth":
>>
>> https://github.com/jtbandes/swift-evolution/blob/master/proposals.xml
>>
>> The status page is then generated from the source of truth using
>> XSLT. Unfortunately, in order to get this working on GitHub Pages, I
>> had to load the files using JavaScript (otherwise the browser blocks
>> the cross-origin requests):
>> https://github.com/jtbandes/swift-evolution/blob/gh-pages/index.html.
>>
>>
>> If we wanted to adopt this for the official swift-evolution repo, the
>> steps would be:
>>
>> 1. push the XML and XSL files to master
>>
>> 2. push a gh-pages branch with the status page
>>
>> 3. update README.md on master to point to the status page, rather
>>than duplicating all the information.
>>
>>
>> Thoughts? Tweaks? Insults?
>>
>>
>> Jacob
>>
> _
> 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`

[Brent Royal-Gordon via swift-evolution]

> On Jul 14, 2016, at 5:24 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Ok, I forgot about it. Type should have all features of T.Type, except 
> that Type will not contain static methods of T.

Why? It seems to me like the most natural way to design this by far is to have 
`Type` be the type returned by `type(of:)`, which means it would have all 
static and class members on it. It also seems like `Type`'s type would 
absolutely have to be `Type`, and some form of infinite regress is 
absolutely necessary (though in practice it could probably be simulated by 
having the first metatype with no static members act as its own type, or with 
some other form of lazy instantiation).

You seem to have some very strong opinions about how this should work which run 
counter to the most straightforward designs, and I don't understand what their 
justifications are.

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

[Anton Zhilin via swift-evolution]

2016-07-15 0:02 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:

> I still can’t get my head around this.
>
> Originally I wanted to seal T.Type completely but I realized that there
> are to many downsides, therefore I think it’s better to revise the way how
> we construct a metatype in Swift + how to solve the ambiguity in
> array/dictionary shorthand syntax + open the door for reflections +
> combining SE–0101 into Type.
>
> I don’t think we have to make the whole model of Type that complicated
> that it contains different identifier for each type. This is already solved
> with metatypes.
>
We can have a field of type T.Type, that is what I meant, no need in
_uniqueIdentifier.
My point is that if we want to remove T.Type from the language, then we
can't just refer to it in docs.
We can use whatever we want for implementation, though.

The thing I believe you misinterpret with Type being the same as T.Type is
> that if Type would act like T.Type:
> T.self.init == T.init
> T.self.staticMember == T.staticMember
> We won’t be able to extend Type at all because otherwise all static
> members of Type would be reserved and cannot be implemented in T,
> which is clearly not how it should work.
> Type.init != T.init
> Type.staticMember != T.staticMember
> Thats why I’m talking about the metatype property all the time.

Ok, I forgot about it. Type should have all features of T.Type, *except
that* Type will not contain static methods of T.
I still can't see any concrete examples where this behaviour is necessary.
Metatypes T.Type can become an implementation detail of Type.

// do not construct full `Type` - use lightweight static calculation
> instead
> public var size: Int { return Type.size }
> public var stride: Int { return Type.stride }
> public var alignment: Int { return Type.alignment }
>
> public static var size: Int { return _sizeof(Type.metatype) }
> public static var stride: Int { return _strideof(Type.metatype) }
> public static var alignment: Int { return _alignof(Type.metatype) }


I agree with most of the code (without _uniqueIdentifier) but not with
this. Consider this example:

let x = Type()
let y = Type(casting: x)!
x.size  //=> 8
y.size  //=> 8 or 40?

I think that y.size should be 8, because we are dynamically checking size
of particular type y, specific subtype of CustomStringConvertible. We
should look into corresponding witness table or whatever, and get the size
at runtime.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] executing a string

[Saagar Jha via swift-evolution]

Here’s

how selectors in Swift work, based on this

proposal. Swift’s selectors are a lot safer than Objective-C’s.

> > > > > One of the major security flaws of Obj C is > > the ability to
convert a string into a selector, which > > permits using private methods
by constructing selectors > > at runtime long after the app store review
has been completed. > > Does Swift do away with that? I understand it
doesn't > > use selectors per se but is there an analogous mechanism? > > >
> >

--

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

On Thu, Jul 14, 2016 at 08:49 Ford Prefect via swift-evolution
swift-evolution@swift.org wrote:


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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Paul Cantrell via swift-evolution]

> On Jul 14, 2016, at 5:56 PM, David Waite  wrote:
> 
> 
>> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution 
>> > wrote:
>> 
>>> On Jul 14, 2016, at 4:39 PM, Chris Lattner >> > wrote:
>>> 
>>> [The core team] asks the community for an in-depth discussion of the 
>>> secondary points of the proposal: does it make sense to require every 
>>> member to be marked as “overridable” in order to be overridden by an open 
>>> subclass outside of the current module?
> 
> I don’t see a reason for the openness/overridability/virtualness/finalness of 
> a member to be more complex than a boolean. That is, while classes can be 
> final, sealed or open, I believe members should only be “open” or “final”. I 
> don’t see use cases to have members that are only overridable in-module but 
> not by external parties.

I tend to agree with that. The “overridable internally, final for the public” 
mode seems like it might have some use, but feels awfully esoteric.

>> This makes me wonder whether we should remove member-level “final” from the 
>> language, and require “overridable” (i.e. final methods by default) even for 
>> members of non-open classes just for consistency and simplicity. That may be 
>> a separate proposal, but does seem like it needs consideration for Swift 3.
> 
> In an inheritance chain, we have to decide whether a subclass inherits the 
> method openness. If so, “final override” could still be valid. Otherwise, I 
> agree about removing member-level ‘final’

My gut feeling is that “final override” is also a bit esoteric — too much to 
justify keeping a whole keyword in the language.

A compelling use case for either of these allegedly esoteric things could 
easily sway me.

Cheers,

Paul

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

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Johannes Neubauer via swift-evolution]

Hi Austin,

> Am 15.07.2016 um 00:35 schrieb Austin Zheng :
> 
> Additive proposals are out of scope for Swift 3; you'll have better luck if 
> you come back around August and propose these one at a time.

Ok. I didn’t know that proposals can be only for the next release. I will come 
back later ;).

> I don't see the need for "poor man's existentials" - existential improvements 
> are out of scope for the next release, and there are already a bunch of 
> designs floating around. You might want to search the archives for more 
> details. #3 falls out of a proper implementation of existential types that 
> support protocols with associated types and self requirements.


> If the storage implements `Equatable`, this problem should be solved, right?
> 
> Anyway (punch-line following), although I don’t know how exactly the 
> low-level Value-Witness-Table works, but if it works as I would expect, then 
> there should be only exactly one entry per „equal“ storage, and all 
> collection types with the same data point to the same reference (which is 
> very memory efficient and table lookup using hashing should be constant 
> time). If this is correct, a check for `===` suffices. AFAIK, the low-level 
> swift implementation already checks for `===` on value types that are stored 
> on the heap (see [this blog post][0]) and don’t bother calling `==` if `===` 
> holds.
> 
> This isn't true. Two buffers can have the same contents and therefore be 
> equal, but be distinct from each other in terms of identity.

Yeah, I had a discussion on swift-dev about this, too. There were some 
misleading blog posts out there. But perhaps it should be that way… could be 
another proposal, but not for Swift 3.

> 
> [0]: 
> https://www.raywenderlich.com/112029/reference-value-types-in-swift-part-2

All the best
Johannes



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

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Diego Sánchez via swift-evolution]

This is great news! Thank you!!

On Thursday, 14 July 2016, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>
> Shortly after SE-0111 was accepted last week, several people newly noticed
> the proposal and started a discussion about how it appears to be a
> regression for closure parameters (e.g. callbacks) that could formerly
> carry labels, but are now not allowed to.  These folks observed that it
> would be more expressive (and consistent with the rest of Swift) to allow
> parameter labels in function types, because the invocation site of a
> closure “should" be required to provide those labels.  The core team has
> been following the discussion, agrees that this is a concern, and wants to
> update the community with a path forward.
>
> The reality of the situation is that the current implementation of
> parameter labels in function types is inherently broken.  Specifically, as
> one example, there is an implicit conversion from "(a: Int) -> Int” to “(Int)
> -> Int”.  However, there is also an implicit conversion from "(Int) -> Int”
> to “(b : Int) -> Int”.  This means that the compiler currently allows
> converting from “(a: Int) -> Int” to “(b: Int) -> Int”, which doesn’t
> make sense, introduces surprising behavior, introduces complexity into the
> compiler implementation, and is generally a problem.  We do have one
> specific hack to prevent conversion of (e.g.) “(a : Int, b : Int) -> Void”
> to “(b : Int, a : Int) -> Void”, but this only triggers in specific
> cases.  There are other more complex cases as well, e.g. when using
> generics "T<(a : Int)->Int>” cannot be considered compatible with "T<(b :
> Int)->Int>”.
>
> These problems are what initially motivated SE-0111.  However, given the
> feedback, the core team went back to the drawing board to determine
> whether: a) SE-0111 by itself is the right long term answer, b) whether
> there were alternate models that could solve the same problems in a
> different way, or c) whether SE-0111 was the right first step to "ultimate
> glory" in the field of closure parameter labels.  After a long discussion,
> and many alternatives considered, the core team believes in c), that
> SE-0111 (with a minor modification) is the right step for Swift 3, because
> it paves the way for the right model over the long term.
>
> 8<
>
> The specific revision requested by the core team to SE-0111 is that all
> “cosmetic” labels should be required to include an API name of _.  For
> example, this would not be allowed:
>
>var op : (lhs : Int, rhs : Int) -> Int
>
> instead, it should be spelled as:
>
>var op : (_ lhs : Int, _ rhs : Int) -> Int
>
> With this change, we believe that we have paved the way for a purely
> additive proposal (and thus, post-Swift 3) that will restore the expressive
> capability of closures with parameter labels.
>
> 8<
>
> Here is a sketch of how that would work, in two steps:
>
>
> First, we extend declaration names for variables, properties, and
> parameters to allow *parameter names* as part of their declaration name.
> For example:
>
>var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
>x = op(lhs: 1, rhs: 2)   // use of the variable or property.
>
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // use of the parameter
>}
>foo(opToUse: +) // call of the function
>
> This will restore the ability to express the idea of a closure parameter
> that carries labels as part of its declaration, without requiring parameter
> labels to be part of the type system (allowing, e.g. the operator + to be
> passed into something that requires parameter labels).
>
>
> Second, extend the rules for function types to allow parameter API labels
> *if and only if* they are used as the type of a declaration that allows
> parameter labels, and interpret them as a sugar form for providing those
> labels on the underlying declaration.  This means that the example above
> could be spelled as:
>
>var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
>x = op(lhs: 1, rhs: 2)  // Same as above
>
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // Same as above.
>}
>foo(opToUse: +)  // Same as above.
>
>
> These two steps will provide the simple and expressive design approach
> that we have now, without all of the problems that representing parameter
> labels in the type system introduces.  The core team believes that the
> temporary regression in expressiveness is an acceptable loss for Swift 3,
> particularly given that this will have no impact on Cocoa or the 

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[David Waite via swift-evolution]

The issue with bringing this up now is that much of the core team is distracted 
by the work of finalizing the Swift 3 implementation, and won’t be able to 
fully participate.

I have a ton of questions about how opinionated the language will be with 
regards to concurrency approaches (I’m in the camp that believes Erlang, Go and 
Node.js have shown opinionated approaches are needed for widespread adoption of 
concurrency within a language). I’m waiting patiently :-)

-DW


> On Jul 14, 2016, at 4:57 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> Is there a way I can make that clearer than putting it in a section labeled 
> “FUTURE DIRECTIONS”?
> 
> Charles
> 
>> On Jul 14, 2016, at 5:52 PM, Dan Appel > > wrote:
>> 
>> Yes, it should be made clear that the 'async'/'await' suggestions are future 
>> directions, which are more to show how flexible the design is rather than 
>> actually be a part of the implementation.
>> 
>> On Thu, Jul 14, 2016 at 3:30 PM Charles Srstka via swift-evolution 
>> > wrote:
>> Right, but since this would affect the Obj-C importer and thus would be a 
>> source-breaking change, it would probably not be possible anymore after 
>> Swift 3.
>> 
>> Charles
>> 
>> > On Jul 14, 2016, at 4:57 PM, Dan Stenmark > > > wrote:
>> >
>> > I’d say it’s a little premature to be talking about this; the team has 
>> > made it very clear that the discussion on Native Concurrency in Swift 
>> > won’t begin for another couple months.
>> >
>> > Dan
>> >
>> >> On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution 
>> >> > wrote:
>> >>
>> >> I know it’s late, but I was wondering what the community thought of this:
>> >>
>> >> MOTIVATION:
>> >>
>> >> With the acceptance of SE-0112, the error handling picture looks much 
>> >> stronger for Swift 3, but there is still one area of awkwardness 
>> >> remaining, in the area of returns from asynchronous methods. 
>> >> Specifically, many asynchronous APIs in the Cocoa framework are declared 
>> >> like this:
>> >>
>> >> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
>> >> _Nullable, NSError * _Nullable))completionHandler;
>> >>
>> >> This will get imported into Swift as something like this:
>> >>
>> >> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
>> >>
>> >> The intention of this API is that either the operation will succeed, and 
>> >> something will be passed in the Bar parameter, and the error will be nil, 
>> >> or else the operation will fail, and then the error parameter will be 
>> >> populated while the Bar parameter is nil. However, this intention is not 
>> >> expressed in the API, since the syntax leaves the possibility that both 
>> >> parameters could be nil, or that they could both be non-nil. This forces 
>> >> the developer to do needless and repetitive checks against a case which 
>> >> in practice shouldn’t occur, as below:
>> >>
>> >> doSomething(foo: foo) { bar, error in
>> >>  if let bar = bar {
>> >>  // handle success case
>> >>  } else if let error = error {
>> >>  self.handleError(error)
>> >>  } else {
>> >>  self.handleError(NSCocoaError.FileReadUnknownError)
>> >>  }
>> >> }
>> >>
>> >> This results in the dreaded “untested code.”
>> >>
>> >> Note that while it is possible that the developer could simply 
>> >> force-unwrap error in the failure case, this leaves the programs open to 
>> >> crashes in the case where a misbehaved API forgets to populate the error 
>> >> on failure, whereas some kind of default error would be more appropriate. 
>> >> The do/try/catch mechanism works around this by returning a generic 
>> >> _NilError in cases where this occurs.
>> >>
>> >> PROPOSED SOLUTION:
>> >>
>> >> Since the pattern for an async API that returns an error in the Cocoa 
>> >> APIs is very similar to the pattern for a synchronous one, we can handle 
>> >> it in a very similar way. To do this, we introduce a new Result enum 
>> >> type. We then bridge asynchronous Cocoa APIs to return this Result type 
>> >> instead of optional values. This more clearly expresses to the user the 
>> >> intent of the API.
>> >>
>> >> In addition to clarifying many Cocoa interfaces, this will provide a 
>> >> standard format for asynchronous APIs that return errors, opening the way 
>> >> for these APIs to be seamlessly integrated into future asynchronous 
>> >> features added to Swift 4 and beyond, in a way that could seamlessly 
>> >> interact with the do/try/catch feature as well.
>> >>
>> >> DETAILED DESIGN:
>> >>
>> >> 1. We introduce a Result type, which looks like this:
>> >>
>> >> enum Result {
>> >>  case success(T)
>> >>  case error(Error)
>> >> }

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Charles Srstka via swift-evolution]

Is there a way I can make that clearer than putting it in a section labeled 
“FUTURE DIRECTIONS”?

Charles

> On Jul 14, 2016, at 5:52 PM, Dan Appel  wrote:
> 
> Yes, it should be made clear that the 'async'/'await' suggestions are future 
> directions, which are more to show how flexible the design is rather than 
> actually be a part of the implementation.
> 
> On Thu, Jul 14, 2016 at 3:30 PM Charles Srstka via swift-evolution 
> > wrote:
> Right, but since this would affect the Obj-C importer and thus would be a 
> source-breaking change, it would probably not be possible anymore after Swift 
> 3.
> 
> Charles
> 
> > On Jul 14, 2016, at 4:57 PM, Dan Stenmark  > > wrote:
> >
> > I’d say it’s a little premature to be talking about this; the team has made 
> > it very clear that the discussion on Native Concurrency in Swift won’t 
> > begin for another couple months.
> >
> > Dan
> >
> >> On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution 
> >> > wrote:
> >>
> >> I know it’s late, but I was wondering what the community thought of this:
> >>
> >> MOTIVATION:
> >>
> >> With the acceptance of SE-0112, the error handling picture looks much 
> >> stronger for Swift 3, but there is still one area of awkwardness 
> >> remaining, in the area of returns from asynchronous methods. Specifically, 
> >> many asynchronous APIs in the Cocoa framework are declared like this:
> >>
> >> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
> >> _Nullable, NSError * _Nullable))completionHandler;
> >>
> >> This will get imported into Swift as something like this:
> >>
> >> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
> >>
> >> The intention of this API is that either the operation will succeed, and 
> >> something will be passed in the Bar parameter, and the error will be nil, 
> >> or else the operation will fail, and then the error parameter will be 
> >> populated while the Bar parameter is nil. However, this intention is not 
> >> expressed in the API, since the syntax leaves the possibility that both 
> >> parameters could be nil, or that they could both be non-nil. This forces 
> >> the developer to do needless and repetitive checks against a case which in 
> >> practice shouldn’t occur, as below:
> >>
> >> doSomething(foo: foo) { bar, error in
> >>  if let bar = bar {
> >>  // handle success case
> >>  } else if let error = error {
> >>  self.handleError(error)
> >>  } else {
> >>  self.handleError(NSCocoaError.FileReadUnknownError)
> >>  }
> >> }
> >>
> >> This results in the dreaded “untested code.”
> >>
> >> Note that while it is possible that the developer could simply 
> >> force-unwrap error in the failure case, this leaves the programs open to 
> >> crashes in the case where a misbehaved API forgets to populate the error 
> >> on failure, whereas some kind of default error would be more appropriate. 
> >> The do/try/catch mechanism works around this by returning a generic 
> >> _NilError in cases where this occurs.
> >>
> >> PROPOSED SOLUTION:
> >>
> >> Since the pattern for an async API that returns an error in the Cocoa APIs 
> >> is very similar to the pattern for a synchronous one, we can handle it in 
> >> a very similar way. To do this, we introduce a new Result enum type. We 
> >> then bridge asynchronous Cocoa APIs to return this Result type instead of 
> >> optional values. This more clearly expresses to the user the intent of the 
> >> API.
> >>
> >> In addition to clarifying many Cocoa interfaces, this will provide a 
> >> standard format for asynchronous APIs that return errors, opening the way 
> >> for these APIs to be seamlessly integrated into future asynchronous 
> >> features added to Swift 4 and beyond, in a way that could seamlessly 
> >> interact with the do/try/catch feature as well.
> >>
> >> DETAILED DESIGN:
> >>
> >> 1. We introduce a Result type, which looks like this:
> >>
> >> enum Result {
> >>  case success(T)
> >>  case error(Error)
> >> }
> >>
> >> 2. Methods that return one parameter asynchronously with an error are 
> >> bridged like this:
> >>
> >> func doSomething(foo: Foo, completionHandler: (Result) -> ())
> >>
> >> and are used like this:
> >>
> >> doSomething(foo: foo) { result in
> >>  switch result {
> >>  case let .success(bar):
> >>  // handle success
> >>  case let .error(error):
> >>  self.handleError(error)
> >>  }
> >> }
> >>
> >> 3. Methods that return multiple parameters asynchronously with an error 
> >> are bridged using a tuple:
> >>
> >> func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())
> >>
> >> and are used like this:
> >>
> >> doSomething(foo: foo) { result in
> >>  

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[David Waite via swift-evolution]

> On Jul 14, 2016, at 4:18 PM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> 
>> On Jul 14, 2016, at 4:39 PM, Chris Lattner > > wrote:
>> 
>> To sum this all up, the core team is … requesting a revision to change the 
>> concrete syntax to “public open class Foo” instead of “subclassable class 
>> Foo”.
> 
> Yes, +1 to “public open Foo” instead of “subclassable Foo”.
> 
> Presumably “open” without “public” is an error…?
> 
>> [The core team] asks the community for an in-depth discussion of the 
>> secondary points of the proposal: does it make sense to require every member 
>> to be marked as “overridable” in order to be overridden by an open subclass 
>> outside of the current module?

I don’t see a reason for the openness/overridability/virtualness/finalness of a 
member to be more complex than a boolean. That is, while classes can be final, 
sealed or open, I believe members should only be “open” or “final”. I don’t see 
use cases to have members that are only overridable in-module but not by 
external parties. 

As we suspect an API designer to indicate whether a class is overridable or not 
by third parties and to determine whether members are exposed to third parties, 
I would expect them to also want to dictate *how* said type is overridable by 
third parties (e.g. which members are overridable). 

Whether we are open by default or final by default allows them to do this, but 
transitioning from final to open shouldn’t break existing API usage on 
revision. You won’t have someone accidentally using your library in a way you 
didn’t intend to support because you forgot to mark a method as ‘open’. 
Therefore, I lean toward final by default.

> This makes me wonder whether we should remove member-level “final” from the 
> language, and require “overridable” (i.e. final methods by default) even for 
> members of non-open classes just for consistency and simplicity. That may be 
> a separate proposal, but does seem like it needs consideration for Swift 3.

In an inheritance chain, we have to decide whether a subclass inherits the 
method openness. If so, “final override” could still be valid. Otherwise, I 
agree about removing member-level ‘final'

-DW

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

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Dan Stenmark via swift-evolution]

IIRC, one of the main goals in Swift 3 was to further stabilize the language 
spec and *minimize* breakage in future versions, not eliminate potential 
breakage altogether.  Considering the numerous directions Native Concurrency 
can take (Go-style green thread scheduling, async-await, continuation handler 
transforms, etc), it would be much better if that discussion got started first. 
 Asynchronous error handling will likely be a big talking point of said 
discussion anyway.

Dan

> On Jul 14, 2016, at 3:30 PM, Charles Srstka  wrote:
> 
> Right, but since this would affect the Obj-C importer and thus would be a 
> source-breaking change, it would probably not be possible anymore after Swift 
> 3.
> 
> Charles
> 
>> On Jul 14, 2016, at 4:57 PM, Dan Stenmark  
>> wrote:
>> 
>> I’d say it’s a little premature to be talking about this; the team has made 
>> it very clear that the discussion on Native Concurrency in Swift won’t begin 
>> for another couple months.
>> 
>> Dan
>> 
>>> On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution 
>>>  wrote:
>>> 
>>> I know it’s late, but I was wondering what the community thought of this:
>>> 
>>> MOTIVATION:
>>> 
>>> With the acceptance of SE-0112, the error handling picture looks much 
>>> stronger for Swift 3, but there is still one area of awkwardness remaining, 
>>> in the area of returns from asynchronous methods. Specifically, many 
>>> asynchronous APIs in the Cocoa framework are declared like this:
>>> 
>>> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
>>> _Nullable, NSError * _Nullable))completionHandler;
>>> 
>>> This will get imported into Swift as something like this:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
>>> 
>>> The intention of this API is that either the operation will succeed, and 
>>> something will be passed in the Bar parameter, and the error will be nil, 
>>> or else the operation will fail, and then the error parameter will be 
>>> populated while the Bar parameter is nil. However, this intention is not 
>>> expressed in the API, since the syntax leaves the possibility that both 
>>> parameters could be nil, or that they could both be non-nil. This forces 
>>> the developer to do needless and repetitive checks against a case which in 
>>> practice shouldn’t occur, as below:
>>> 
>>> doSomething(foo: foo) { bar, error in
>>> if let bar = bar {
>>> // handle success case
>>> } else if let error = error {
>>> self.handleError(error)
>>> } else {
>>> self.handleError(NSCocoaError.FileReadUnknownError)
>>> }
>>> }
>>> 
>>> This results in the dreaded “untested code.”
>>> 
>>> Note that while it is possible that the developer could simply force-unwrap 
>>> error in the failure case, this leaves the programs open to crashes in the 
>>> case where a misbehaved API forgets to populate the error on failure, 
>>> whereas some kind of default error would be more appropriate. The 
>>> do/try/catch mechanism works around this by returning a generic _NilError 
>>> in cases where this occurs.
>>> 
>>> PROPOSED SOLUTION:
>>> 
>>> Since the pattern for an async API that returns an error in the Cocoa APIs 
>>> is very similar to the pattern for a synchronous one, we can handle it in a 
>>> very similar way. To do this, we introduce a new Result enum type. We then 
>>> bridge asynchronous Cocoa APIs to return this Result type instead of 
>>> optional values. This more clearly expresses to the user the intent of the 
>>> API.
>>> 
>>> In addition to clarifying many Cocoa interfaces, this will provide a 
>>> standard format for asynchronous APIs that return errors, opening the way 
>>> for these APIs to be seamlessly integrated into future asynchronous 
>>> features added to Swift 4 and beyond, in a way that could seamlessly 
>>> interact with the do/try/catch feature as well.
>>> 
>>> DETAILED DESIGN:
>>> 
>>> 1. We introduce a Result type, which looks like this:
>>> 
>>> enum Result {
>>> case success(T)
>>> case error(Error)
>>> }
>>> 
>>> 2. Methods that return one parameter asynchronously with an error are 
>>> bridged like this:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Result) -> ())
>>> 
>>> and are used like this:
>>> 
>>> doSomething(foo: foo) { result in
>>> switch result {
>>> case let .success(bar):
>>> // handle success
>>> case let .error(error):
>>> self.handleError(error)
>>> }
>>> }
>>> 
>>> 3. Methods that return multiple parameters asynchronously with an error are 
>>> bridged using a tuple:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())
>>> 
>>> and are used like this:
>>> 
>>> doSomething(foo: foo) { result in
>>> switch result {
>>> case let .success(bar, baz):
>>> // handle success
>>> case let .error(error):
>>>  

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Austin Zheng via swift-evolution]

Additive proposals are out of scope for Swift 3; you'll have better luck if
you come back around August and propose these one at a time.

I don't see the need for "poor man's existentials" - existential
improvements are out of scope for the next release, and there are already a
bunch of designs floating around. You might want to search the archives for
more details. #3 falls out of a proper implementation of existential types
that support protocols with associated types and self requirements.


> If the storage implements `Equatable`, this problem should be solved,
> right?
>
> Anyway (punch-line following), although I don’t know how exactly the
> low-level Value-Witness-Table works, but if it works as I would expect,
> then there should be only exactly one entry per „equal“ storage, and all
> collection types with the same data point to the same reference (which is
> very memory efficient and table lookup using hashing should be constant
> time). If this is correct, a check for `===` suffices. AFAIK, the low-level
> swift implementation already checks for `===` on value types that are
> stored on the heap (see [this blog post][0]) and don’t bother calling `==`
> if `===` holds.
>

This isn't true. Two buffers can have the same contents and therefore be
equal, but be distinct from each other in terms of identity.


>
> All the best
> Johannes
>
> [0]:
> https://www.raywenderlich.com/112029/reference-value-types-in-swift-part-2
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Charles Srstka via swift-evolution]

Right, but since this would affect the Obj-C importer and thus would be a 
source-breaking change, it would probably not be possible anymore after Swift 3.

Charles

> On Jul 14, 2016, at 4:57 PM, Dan Stenmark  wrote:
> 
> I’d say it’s a little premature to be talking about this; the team has made 
> it very clear that the discussion on Native Concurrency in Swift won’t begin 
> for another couple months.
> 
> Dan
> 
>> On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> I know it’s late, but I was wondering what the community thought of this:
>> 
>> MOTIVATION:
>> 
>> With the acceptance of SE-0112, the error handling picture looks much 
>> stronger for Swift 3, but there is still one area of awkwardness remaining, 
>> in the area of returns from asynchronous methods. Specifically, many 
>> asynchronous APIs in the Cocoa framework are declared like this:
>> 
>> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
>> _Nullable, NSError * _Nullable))completionHandler;
>> 
>> This will get imported into Swift as something like this:
>> 
>> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
>> 
>> The intention of this API is that either the operation will succeed, and 
>> something will be passed in the Bar parameter, and the error will be nil, or 
>> else the operation will fail, and then the error parameter will be populated 
>> while the Bar parameter is nil. However, this intention is not expressed in 
>> the API, since the syntax leaves the possibility that both parameters could 
>> be nil, or that they could both be non-nil. This forces the developer to do 
>> needless and repetitive checks against a case which in practice shouldn’t 
>> occur, as below:
>> 
>> doSomething(foo: foo) { bar, error in
>>  if let bar = bar {
>>  // handle success case
>>  } else if let error = error {
>>  self.handleError(error)
>>  } else {
>>  self.handleError(NSCocoaError.FileReadUnknownError)
>>  }
>> }
>> 
>> This results in the dreaded “untested code.”
>> 
>> Note that while it is possible that the developer could simply force-unwrap 
>> error in the failure case, this leaves the programs open to crashes in the 
>> case where a misbehaved API forgets to populate the error on failure, 
>> whereas some kind of default error would be more appropriate. The 
>> do/try/catch mechanism works around this by returning a generic _NilError in 
>> cases where this occurs.
>> 
>> PROPOSED SOLUTION:
>> 
>> Since the pattern for an async API that returns an error in the Cocoa APIs 
>> is very similar to the pattern for a synchronous one, we can handle it in a 
>> very similar way. To do this, we introduce a new Result enum type. We then 
>> bridge asynchronous Cocoa APIs to return this Result type instead of 
>> optional values. This more clearly expresses to the user the intent of the 
>> API.
>> 
>> In addition to clarifying many Cocoa interfaces, this will provide a 
>> standard format for asynchronous APIs that return errors, opening the way 
>> for these APIs to be seamlessly integrated into future asynchronous features 
>> added to Swift 4 and beyond, in a way that could seamlessly interact with 
>> the do/try/catch feature as well.
>> 
>> DETAILED DESIGN:
>> 
>> 1. We introduce a Result type, which looks like this:
>> 
>> enum Result {
>>  case success(T)
>>  case error(Error)
>> }
>> 
>> 2. Methods that return one parameter asynchronously with an error are 
>> bridged like this:
>> 
>> func doSomething(foo: Foo, completionHandler: (Result) -> ())
>> 
>> and are used like this:
>> 
>> doSomething(foo: foo) { result in
>>  switch result {
>>  case let .success(bar):
>>  // handle success
>>  case let .error(error):
>>  self.handleError(error)
>>  }
>> }
>> 
>> 3. Methods that return multiple parameters asynchronously with an error are 
>> bridged using a tuple:
>> 
>> func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())
>> 
>> and are used like this:
>> 
>> doSomething(foo: foo) { result in
>>  switch result {
>>  case let .success(bar, baz):
>>  // handle success
>>  case let .error(error):
>>  self.handleError(error)
>>  }
>> }
>> 
>> 4. Methods that return only an error and nothing else are bridged as they 
>> are currently, with the exception of bridging NSError to Error as in SE-0112:
>> 
>> func doSomething(foo: Foo, completionHandler: (Error?) -> ())
>> 
>> and are used as they currently are:
>> 
>> doSomething(foo: foo) { error in
>>  if let error = error {
>>  // handle error
>>  } else {
>>  // handle success
>>  }
>> }
>> 
>> 5. For the case in part 2, the bridge works much like the do/try/catch 
>> mechanism. If the first parameter is non-nil, it is returned inside the 
>> .success case. If it is 

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Johannes Neubauer via swift-evolution]

Hi Daniel,

I will answer backwards, since it is easier for me this way.

> Am 14.07.2016 um 22:47 schrieb Daniel Resnick :
> 
> Furthermore, why should properties pointing to reference types always use 
> `===`? What if the reference type conforms to `Equatable`?

I proposed to use `===`, since a value of a reference a value type is 
referencing is the reference itself. But point taken. So a solution could be to 
use `==` for reference types implementing `Equatable`. But wait for the 
punch-line below ;).

> Forbidding custom `==` for value types would break equality for all Swift 
> collection types, since they use reference types behind the scenes for 
> storing memory and copy on write semantics.

If the storage implements `Equatable`, this problem should be solved, right?

Anyway (punch-line following), although I don’t know how exactly the low-level 
Value-Witness-Table works, but if it works as I would expect, then there should 
be only exactly one entry per „equal“ storage, and all collection types with 
the same data point to the same reference (which is very memory efficient and 
table lookup using hashing should be constant time). If this is correct, a 
check for `===` suffices. AFAIK, the low-level swift implementation already 
checks for `===` on value types that are stored on the heap (see [this blog 
post][0]) and don’t bother calling `==` if `===` holds.

All the best
Johannes

[0]: https://www.raywenderlich.com/112029/reference-value-types-in-swift-part-2


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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Paul Cantrell via swift-evolution]

> On Jul 14, 2016, at 4:39 PM, Chris Lattner  wrote:
> 
> To sum this all up, the core team is … requesting a revision to change the 
> concrete syntax to “public open class Foo” instead of “subclassable class 
> Foo”.

Yes, +1 to “public open Foo” instead of “subclassable Foo”.

Presumably “open” without “public” is an error…?

> [The core team] asks the community for an in-depth discussion of the 
> secondary points of the proposal: does it make sense to require every member 
> to be marked as “overridable” in order to be overridden by an open subclass 
> outside of the current module?

Tentative +1 to this, though I’m open to hearing arguments otherwise.

One could make a good case for overridable being the sensible default and 
require an explicit “final,” just as for internal subclassing. I lean against 
this for two reasons:

Explicit “overridable” is consistent with the general principle of explicit 
exposure of public promises in public APIs.
When a class is declared public, its members are still internal by default. By 
analogy, class-level “open” shouldn’t make members overridable by default 
either. With a language like Swift that encourages developers to lean on the 
compiler for verification, setting consistent expectations is crucial, and this 
behavior seems more consistent to me.

I look at this proposal primarily from the point of view of a library author 
who is trying to design their API right, and is looking for assistance from the 
language in achieving that goal. The core team’s proposals seem consistent with 
this.

This makes me wonder whether we should remove member-level “final” from the 
language, and require “overridable” (i.e. final methods by default) even for 
members of non-open classes just for consistency and simplicity. That may be a 
separate proposal, but does seem like it needs consideration for Swift 3.

Cheers,

Paul

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

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Dan Stenmark via swift-evolution]

I’d say it’s a little premature to be talking about this; the team has made it 
very clear that the discussion on Native Concurrency in Swift won’t begin for 
another couple months.

Dan

> On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> I know it’s late, but I was wondering what the community thought of this:
> 
> MOTIVATION:
> 
> With the acceptance of SE-0112, the error handling picture looks much 
> stronger for Swift 3, but there is still one area of awkwardness remaining, 
> in the area of returns from asynchronous methods. Specifically, many 
> asynchronous APIs in the Cocoa framework are declared like this:
> 
> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
> _Nullable, NSError * _Nullable))completionHandler;
> 
> This will get imported into Swift as something like this:
> 
> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
> 
> The intention of this API is that either the operation will succeed, and 
> something will be passed in the Bar parameter, and the error will be nil, or 
> else the operation will fail, and then the error parameter will be populated 
> while the Bar parameter is nil. However, this intention is not expressed in 
> the API, since the syntax leaves the possibility that both parameters could 
> be nil, or that they could both be non-nil. This forces the developer to do 
> needless and repetitive checks against a case which in practice shouldn’t 
> occur, as below:
> 
> doSomething(foo: foo) { bar, error in
>   if let bar = bar {
>   // handle success case
>   } else if let error = error {
>   self.handleError(error)
>   } else {
>   self.handleError(NSCocoaError.FileReadUnknownError)
>   }
> }
> 
> This results in the dreaded “untested code.”
> 
> Note that while it is possible that the developer could simply force-unwrap 
> error in the failure case, this leaves the programs open to crashes in the 
> case where a misbehaved API forgets to populate the error on failure, whereas 
> some kind of default error would be more appropriate. The do/try/catch 
> mechanism works around this by returning a generic _NilError in cases where 
> this occurs.
> 
> PROPOSED SOLUTION:
> 
> Since the pattern for an async API that returns an error in the Cocoa APIs is 
> very similar to the pattern for a synchronous one, we can handle it in a very 
> similar way. To do this, we introduce a new Result enum type. We then bridge 
> asynchronous Cocoa APIs to return this Result type instead of optional 
> values. This more clearly expresses to the user the intent of the API.
> 
> In addition to clarifying many Cocoa interfaces, this will provide a standard 
> format for asynchronous APIs that return errors, opening the way for these 
> APIs to be seamlessly integrated into future asynchronous features added to 
> Swift 4 and beyond, in a way that could seamlessly interact with the 
> do/try/catch feature as well.
> 
> DETAILED DESIGN:
> 
> 1. We introduce a Result type, which looks like this:
> 
> enum Result {
>   case success(T)
>   case error(Error)
> }
> 
> 2. Methods that return one parameter asynchronously with an error are bridged 
> like this:
> 
> func doSomething(foo: Foo, completionHandler: (Result) -> ())
> 
> and are used like this:
> 
> doSomething(foo: foo) { result in
>   switch result {
>   case let .success(bar):
>   // handle success
>   case let .error(error):
>   self.handleError(error)
>   }
> }
> 
> 3. Methods that return multiple parameters asynchronously with an error are 
> bridged using a tuple:
> 
> func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())
> 
> and are used like this:
> 
> doSomething(foo: foo) { result in
>   switch result {
>   case let .success(bar, baz):
>   // handle success
>   case let .error(error):
>   self.handleError(error)
>   }
> }
> 
> 4. Methods that return only an error and nothing else are bridged as they are 
> currently, with the exception of bridging NSError to Error as in SE-0112:
> 
> func doSomething(foo: Foo, completionHandler: (Error?) -> ())
> 
> and are used as they currently are:
> 
> doSomething(foo: foo) { error in
>   if let error = error {
>   // handle error
>   } else {
>   // handle success
>   }
> }
> 
> 5. For the case in part 2, the bridge works much like the do/try/catch 
> mechanism. If the first parameter is non-nil, it is returned inside the 
> .success case. If it is nil, then the error is returned inside the .error 
> case if it is non-nil, and otherwise _NilError is returned in the .error case.
> 
> 6. For the case in part 3, in which there are multiple return values, the 
> same pattern is followed, with the exception that we introduce a new 
> Objective-C annotation. I am provisionally naming this annotation 
> 

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

[Adrian Zubarev via swift-evolution]

I must correct the dynamicType implementation. It’s true that the function will 
produce Type but we still need to extract the dynamic metatype from the 
value, store it in _underlyingMetatype and recalculate _uniqueIdentifier.

public func `dynamicType`(_ instance: T) -> Metatype {
 
let dynamicMetatype = /* extract from `instance` */
let rawPointerMetatype = unsafeBitCast(dynamicMetatype, to: 
Builtin.RawPointer.metatype)
 
var type = Type()
type._underlyingMetatype = dynamicMetatype
type._uniqueIdentifier = Int(Builtin.ptrtoint_Word(rawPointerMetatype))
 
return type
}


-- 
Adrian Zubarev
Sent with Airmail
___
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`

[Adrian Zubarev via swift-evolution]

Here is the formatted gist of the possible impementation: 
https://gist.github.com/DevAndArtist/a5744f21107812b2d4e6baee2c55e0bf



-- 
Adrian Zubarev
Sent with Airmail

Am 14. Juli 2016 um 23:02:52, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

I still can’t get my head around this.

Originally I wanted to seal T.Type completely but I realized that there are to 
many downsides, therefore I think it’s better to revise the way how we 
construct a metatype in Swift + how to solve the ambiguity in array/dictionary 
shorthand syntax + open the door for reflections + combining SE–0101 into 
Type.

I don’t think we have to make the whole model of Type that complicated that 
it contains different identifier for each type. This is already solved with 
metatypes.

The thing I believe you misinterpret with Type being the same as T.Type is 
that if Type would act like T.Type:

T.self.init == T.init
T.self.staticMember == T.staticMember
We won’t be able to extend Type at all because otherwise all static members 
of Type would be reserved and cannot be implemented in T, which is clearly 
not how it should work.

Type.init != T.init
Type.staticMember != T.staticMember   
Thats why I’m talking about the metatype property all the time.

Here is full bikeshedding implementation. I’ll use T.Metatype instead of T.Type 
for internal use only + T.metatype instead of T.self for internal use only + 
I’ll drop .self in public use and assume we can construct Type from T.

/// `T.metatype` returns an instance of `T.Metatype` == `Metatype`
/// `T.metatype` is only used internally and not visible in public
/// `T.Metatype` is visible in public but not allowed in declarations - use 
`Metatype` instead
/// `T.self` is dropped in public
/// `T` returns an instance of `Type` if its not part of a declaration
/// To instantiate `Metatype` use `Type.metatype` or `Type().metatype`

internal func _sizeof(_ metatype: Metatype) -> Int {
return Int(Builtin.sizeof(metatype))
}

internal func _strideof(_ metatype: Metatype) -> Int {
return Int(Builtin.strideof_nonzero(metatype))
}

internal func _alignof(_ metatype: Metatype) -> Int {
return Int(Builtin.alignof(metatype))
}

public func unsafeBitCast(_: T, to: Type) -> U { ... }

public typealias Metatype = T.Metatype

public struct Type : Hashable, CustomStringConvertible, 
CustomDebugStringConvertible {
  
// Stored as `Any` to make `init?(casting:)` work as expected.
// There is no need to contain different identifier like a Set!
internal let _underlyingMetatype: Any
internal let _uniqueIdentifier: Int
  
public init() {
  
self._underlyingMetatype = T.metatype
  
// Same hash calculation like in `ObjectIdentifier`
let rawPointerMetatype = unsafeBitCast(T.metatype, to: 
Builtin.RawPointer.metatype)
self._uniqueIdentifier = Int(Builtin.ptrtoint_Word(rawPointerMetatype))
}
  
public init(_ copy: Type) {

self._underlyingMetatype = copy._underlyingMetatype
self._uniqueIdentifier = copy._uniqueIdentifier
}

// Creates an instance referring to type, which is referred by `otherType`, 
if possible
public init?(casting otherType: Type) {
  
// check if we can up- or downcast ther metatype from `otherType` to 
`Metatype`
guard (otherType._underlyingMetatype as? Metatype) != nil else {
return nil
}
  
// create a new `Type` but copy the metatype and the identifier from 
`otherType`
self._underlyingMetatype = otherType._underlyingMetatype
self._uniqueIdentifier = otherType._uniqueIdentifier
}

public func `is`(_ otherType: Type) -> Bool {
return Type(casting: self) != nil
}
  
public var metatype: Metatype { return Type.metatype }
public static var metatype: Metatype { return T.metatype }
  
// do not construct full `Type` - use lightweight static calculation 
instead
public var size: Int { return Type.size }
public var stride: Int { return Type.stride }
public var alignment: Int { return Type.alignment }
  
public static var size: Int { return _sizeof(Type.metatype) }
public static var stride: Int { return _strideof(Type.metatype) }
public static var alignment: Int { return _alignof(Type.metatype) }
  
public var hashValue: Int { return self._uniqueIdentifier }
  
public var description: String {
return "Type<\(self.metatype)>"
}
  
public var debugDescription: String {
return "<" + self.description
+ " metatype: \(self.metatype)"
+ " size: \(self.size)"
+ " stride: \(self.stride)"
+ " alignment: \(self.alignment)>"
}
}

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

/// class A {}
/// class B: A {}
///
/// let anything: Any = B()
///
/// `Any.Type` or `Metatype`
/// let 

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

[Adrian Zubarev via swift-evolution]

I still can’t get my head around this.

Originally I wanted to seal T.Type completely but I realized that there are to 
many downsides, therefore I think it’s better to revise the way how we 
construct a metatype in Swift + how to solve the ambiguity in array/dictionary 
shorthand syntax + open the door for reflections + combining SE–0101 into 
Type.

I don’t think we have to make the whole model of Type that complicated that 
it contains different identifier for each type. This is already solved with 
metatypes.

The thing I believe you misinterpret with Type being the same as T.Type is 
that if Type would act like T.Type:

T.self.init == T.init
T.self.staticMember == T.staticMember
We won’t be able to extend Type at all because otherwise all static members 
of Type would be reserved and cannot be implemented in T, which is clearly 
not how it should work.

Type.init != T.init
Type.staticMember != T.staticMember  
Thats why I’m talking about the metatype property all the time.

Here is full bikeshedding implementation. I’ll use T.Metatype instead of T.Type 
for internal use only + T.metatype instead of T.self for internal use only + 
I’ll drop .self in public use and assume we can construct Type from T.

/// `T.metatype` returns an instance of `T.Metatype` == `Metatype`
/// `T.metatype` is only used internally and not visible in public
/// `T.Metatype` is visible in public but not allowed in declarations - use 
`Metatype` instead
/// `T.self` is dropped in public
/// `T` returns an instance of `Type` if its not part of a declaration
/// To instantiate `Metatype` use `Type.metatype` or `Type().metatype`

internal func _sizeof(_ metatype: Metatype) -> Int {
return Int(Builtin.sizeof(metatype))
}

internal func _strideof(_ metatype: Metatype) -> Int {
return Int(Builtin.strideof_nonzero(metatype))
}

internal func _alignof(_ metatype: Metatype) -> Int {
return Int(Builtin.alignof(metatype))
}

public func unsafeBitCast(_: T, to: Type) -> U { ... }

public typealias Metatype = T.Metatype

public struct Type : Hashable, CustomStringConvertible, 
CustomDebugStringConvertible {
 
// Stored as `Any` to make `init?(casting:)` work as expected.
// There is no need to contain different identifier like a Set!
internal let _underlyingMetatype: Any
internal let _uniqueIdentifier: Int
 
public init() {
 
self._underlyingMetatype = T.metatype
 
// Same hash calculation like in `ObjectIdentifier`
let rawPointerMetatype = unsafeBitCast(T.metatype, to: 
Builtin.RawPointer.metatype)
self._uniqueIdentifier = Int(Builtin.ptrtoint_Word(rawPointerMetatype))
}
 
public init(_ copy: Type) {

self._underlyingMetatype = copy._underlyingMetatype
self._uniqueIdentifier = copy._uniqueIdentifier
}

// Creates an instance referring to type, which is referred by `otherType`, 
if possible
public init?(casting otherType: Type) {
 
// check if we can up- or downcast ther metatype from `otherType` to 
`Metatype`
guard (otherType._underlyingMetatype as? Metatype) != nil else {
return nil
}
 
// create a new `Type` but copy the metatype and the identifier from 
`otherType`
self._underlyingMetatype = otherType._underlyingMetatype
self._uniqueIdentifier = otherType._uniqueIdentifier
}

public func `is`(_ otherType: Type) -> Bool {
return Type(casting: self) != nil
}
 
public var metatype: Metatype { return Type.metatype }
public static var metatype: Metatype { return T.metatype }
 
// do not construct full `Type` - use lightweight static calculation 
instead
public var size: Int { return Type.size }
public var stride: Int { return Type.stride }
public var alignment: Int { return Type.alignment }
 
public static var size: Int { return _sizeof(Type.metatype) }
public static var stride: Int { return _strideof(Type.metatype) }
public static var alignment: Int { return _alignof(Type.metatype) }
 
public var hashValue: Int { return self._uniqueIdentifier }
 
public var description: String {
return "Type<\(self.metatype)>"
}
 
public var debugDescription: String {
return "<" + self.description
+ " metatype: \(self.metatype)"
+ " size: \(self.size)"
+ " stride: \(self.stride)"
+ " alignment: \(self.alignment)>"
}
}

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

/// class A {}
/// class B: A {}
///
/// let anything: Any = B()
///
/// `Any.Type` or `Metatype`
/// let metatype = dynamicType(anything)
///
/// ((metatype as? Metatype) != nil) == true
///

// This function can only extract the metatype from an instance.
// What we'll do to the metatype is up to us.
public func `dynamicType`(_: T) -> Metatype {
return Type.metatype
}
And 

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Daniel Resnick via swift-evolution]

Forbidding custom `==` for value types would break equality for all Swift
collection types, since they use reference types behind the scenes for
storing memory and copy on write semantics. Furthermore, why should
properties pointing to reference types always use `===`? What if the
reference type conforms to `Equatable`?

On Thu, Jul 14, 2016 at 1:36 PM, Johannes Neubauer via swift-evolution <
swift-evolution@swift.org> wrote:

> Dear Evolutionaries,
>
> First off, I like Swift!
>
> I have some proposals for swift 3ff. (since the `++` operator is
> discouraged ;) ):
>
> 1. Custom implementation of equals operator `==` for value types should be
> forbidden. Rationale: Why has it been added in the first place? For
> omitting some values from the equals test? A user may introduce
> side-effects in that very method, i.e., check some global variable. It
> should to the most be allowed to mark/annotate some properties with
> `transient` or some better name, in order to prevent it being part of the
> equals test. But I would discourage the ability to omit some of the values
> from the equals test, since it does not make sense for value types, does
> it? If a value instance is equal to another, but the value may differ...
> this is odd semantics. Properties pointing at reference types should be
> tested with `===`. The `hashValue` for `Hashable` value types, should be
> auto-computed, too. Since a value type is "kind of" immutable (will be
> copied if it is changed), the hash value can be cached.
> 2. `dispatch` keyword on functions/parameters especially for operators.
> Which leads to dynamic dispatch of one or more parameters (as defined via
> the keyword). Rationale: Swift is a multi-paradigm language. It is neither
> as hard with immutability as Haskell is, but not as open as Python or
> whatever. I see Swift as a golden middle course. This is why in Swift value
> and reference types coexist, isn't it? So, although the focus seems to lie
> on value types and static dispatch, the dynamic world still is your frient,
> right? Adding dynamic/multi dispatch on-demand would be great. Now I have
> to implement it by defining an operator on a super type and implement an
> instance method, which the operator can delegate to. Last but not least, in
> the instance method I have to do the dispatch of the second parameter by
> hand. This feature could be used wonderfully together with value types
> using your great Existential Containers, too.
> 3. As a follow-up to *2.*: `default`-case for methods/operators like
> equals (`==`) to allow safe polymorphic calls for mixed types (or even
> complete pattern matching for method overloading, like many functional
> languages do it for having functions with different entry points for
> different values). Rationale: If you could add a `default`-case (e.g. as an
> additional statement to the `return` or beneath the definition of the
> return type in the method head) which returns `false`, then you could
> safely implement all `T == T` checks and all `T == U` checks will just
> return false. This does not make sense for all methods, but I can imagine
> of more than just equals ;) . This way swift could soften the requirement
> of PATs (Protocol with Associated Types) with the associated type `Self`.
> This would be a very first step to existentials... leading to the next and
> last proposal for today
> 4. Add poor-mans existentials which allow to access non-PAT methods as
> well as methods with a `default`-case (see *3.*). Rationale: I read the
> [generics manifesto][0] and really liked the part [existentials][1]. In a
> first step I wouldn't do complicated things like chaining existentials, but
> do something similar like in structs with `mutating` functions: You just
> cannot call them on `let` variables (compiler error). The same could be
> done for methods using the associated type in their signature (because of
> the co-/contravariance problem) unless the associated type is `Self` and
> the function has a `default`-clause. By the way I think, that not
> implementing pseudo-existentials (like Java and Kotlin do with their
> wildcards or variance declarations `in`/`out` respectively) and I hope that
> the existentials will come to swift in the future... I was a little bit
> afraid that the "Existentials" section is beneath "Unlikely" and "Potential
> Removals", but since these headings are on the same level, this does not
> mean that implementing existentials in the future are unlikely, does it? I
> have some ideas how they could fit into the language very well, if you like
> to hear them...?
>
> I would really appreciate discussing these 4 proposals :) .
>
> All the best
> Johannes
>
> [0]: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
> [1]:
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#existentials
>
> --
> Dr. Johannes Neubauer
> E-Mail: neuba...@kingsware.de
> WWW   : http://www.kingsware.de
>
>
> 

[swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Johannes Neubauer via swift-evolution]

Dear Evolutionaries,

First off, I like Swift!

I have some proposals for swift 3ff. (since the `++` operator is discouraged ;) 
):

1. Custom implementation of equals operator `==` for value types should be 
forbidden. Rationale: Why has it been added in the first place? For omitting 
some values from the equals test? A user may introduce side-effects in that 
very method, i.e., check some global variable. It should to the most be allowed 
to mark/annotate some properties with `transient` or some better name, in order 
to prevent it being part of the equals test. But I would discourage the ability 
to omit some of the values from the equals test, since it does not make sense 
for value types, does it? If a value instance is equal to another, but the 
value may differ... this is odd semantics. Properties pointing at reference 
types should be tested with `===`. The `hashValue` for `Hashable` value types, 
should be auto-computed, too. Since a value type is "kind of" immutable (will 
be copied if it is changed), the hash value can be cached.
2. `dispatch` keyword on functions/parameters especially for operators. Which 
leads to dynamic dispatch of one or more parameters (as defined via the 
keyword). Rationale: Swift is a multi-paradigm language. It is neither as hard 
with immutability as Haskell is, but not as open as Python or whatever. I see 
Swift as a golden middle course. This is why in Swift value and reference types 
coexist, isn't it? So, although the focus seems to lie on value types and 
static dispatch, the dynamic world still is your frient, right? Adding 
dynamic/multi dispatch on-demand would be great. Now I have to implement it by 
defining an operator on a super type and implement an instance method, which 
the operator can delegate to. Last but not least, in the instance method I have 
to do the dispatch of the second parameter by hand. This feature could be used 
wonderfully together with value types using your great Existential Containers, 
too.
3. As a follow-up to *2.*: `default`-case for methods/operators like equals 
(`==`) to allow safe polymorphic calls for mixed types (or even complete 
pattern matching for method overloading, like many functional languages do it 
for having functions with different entry points for different values). 
Rationale: If you could add a `default`-case (e.g. as an additional statement 
to the `return` or beneath the definition of the return type in the method 
head) which returns `false`, then you could safely implement all `T == T` 
checks and all `T == U` checks will just return false. This does not make sense 
for all methods, but I can imagine of more than just equals ;) . This way swift 
could soften the requirement of PATs (Protocol with Associated Types) with the 
associated type `Self`. This would be a very first step to existentials... 
leading to the next and last proposal for today
4. Add poor-mans existentials which allow to access non-PAT methods as well as 
methods with a `default`-case (see *3.*). Rationale: I read the [generics 
manifesto][0] and really liked the part [existentials][1]. In a first step I 
wouldn't do complicated things like chaining existentials, but do something 
similar like in structs with `mutating` functions: You just cannot call them on 
`let` variables (compiler error). The same could be done for methods using the 
associated type in their signature (because of the co-/contravariance problem) 
unless the associated type is `Self` and the function has a `default`-clause. 
By the way I think, that not implementing pseudo-existentials (like Java and 
Kotlin do with their wildcards or variance declarations `in`/`out` 
respectively) and I hope that the existentials will come to swift in the 
future... I was a little bit afraid that the "Existentials" section is beneath 
"Unlikely" and "Potential Removals", but since these headings are on the same 
level, this does not mean that implementing existentials in the future are 
unlikely, does it? I have some ideas how they could fit into the language very 
well, if you like to hear them...?

I would really appreciate discussing these 4 proposals :) .

All the best
Johannes

[0]: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
[1]: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#existentials

--
Dr. Johannes Neubauer
E-Mail: neuba...@kingsware.de
WWW   : http://www.kingsware.de



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

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

[Anton Zhilin via swift-evolution]

I still didn't answer the original question:

>> Values of Type store identifiers of U such that U: T.
>Why would we want to store more than one unique identifier?

We don't. What I meant is the following.
Type can have multiple non-equal values. Each of them contains a single
identifier of some type U:T. This type U is different for non-equal values
of Type.

2016-07-14 22:01 GMT+03:00 Anton Zhilin :

> I didn't send the link to evolution, so here it is:
> https://gist.github.com/Anton3/08a069a3b6f634bece7ad666922741d2
>
> Response inline:
>
> 2016-07-14 20:52 GMT+03:00 Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>:
>>
>>
>>-
>>
>>There is a small typo (SE–0090 is not accepted yet) - only in the
>>first example:
>>
>>func unsafeBitCast(_: T, to: U.Type)
>>unsafeBitCast(10, to: Double)
>>
>>// The second line should be
>>unsafeBitCast(10, to: Double.self)
>>
>>
>> I'll fix the examples.
>
>>
>>-
>>
>>Size and internal structure of Type will be the same as of T.Type
>>
>>- Do we really need this to be the same?
>>
>> Yes, otherwise we cannot remove T.Type. If you want to store *additional*
> data in Type and have a reason for that, then why not.
>
>>
>>-
>>   -
>>
>>Values of Type store identifiers of U such that U: T.
>>
>>- Why would we want to store more than one unique identifier?
>>
>> Another try at explaining my model of Type. Warning: it will be a
> long read this time!
>
> During compilation, each type is assigned a unique integer identifier.
> Let's suppose there are only three types used in the program: Any is 1,
> BaseClass is 2, DerivedClass is 3.
>
> Values of type Type can contain one of identifiers 1, 2 or 3.
> Values of type Type can contain one of identifiers 2 or 3.
> Values of type Type can only contain 3.
>
> The same in terms of sets:
>
> Type = { 1, 2, 3 }
> Type = { 2, 3 }
> Type = { 3 }
>
> In terms of set theory, type Type contains identifiers of all types U
> that are subtypes of T.
> If U1, ..., Uk are subtypes of T used in the program, then Type = { T,
> U1, ..., Uk }
>
> Example:
>
> let x = Type()
> let y = Type(casting: x)
> Type.size  //=> 50
> Type.size  //=> 40
> x.size //=> 50
> y.size //=> 50
>
> Again, example with dynamicType. Let's suppose that T = BaseClass and 
> DerivedClass:
> BaseClass.
>
> func dynamicType(_ value: BaseClass) -> Type
>
> We can't know statically, which type information it returns.
> Type = { 2, 3 }
> At runtime, we get to know if value is of BaseClass or of DerivedClass.
>
> In my version, Type should get all capabilities and all syntax of
> T.Type, therefore we should be able to drop the latter.
>
> Again, main idea: *rename* T.Type to Type, *maintain* its behaviour
> and tweak syntax.
>
> Actually I thought for a while about the negative effect of fully removing
>> metatypes from the language. Metatypes allow us to build neat looking
>> execution branches like showed in SE–0101.
>>
>> extension MemoryLayout {
>> init(_ : @autoclosure () -> T) {}
>> public static func of(_ candidate : @autoclosure () -> T) -> 
>> MemoryLayout.Type {
>> return MemoryLayout.init(candidate).dynamicType
>> }
>> }
>>
>> // Value
>> let x: UInt8 = 5
>> MemoryLayout.of(x).size // 1
>> MemoryLayout.of(1).size // 8
>> MemoryLayout.of("hello").stride // 24
>> MemoryLayout.of(29.2).alignment // 8
>>
>> I wouldn’t want to throw this away.
>>
> We won't lose literally anything by moving from T.Type to Type.
>
> of returns MemoryLayout.Type, which currently doesn't have size
> property. Could you correct your example?
>
>> I played with the idea of keeping T.Type internally but disallow it in
>> public declarations. Furthermore metatypes would still exist, but can only
>> be instantiated through Type.metatype or Type().metatype.
>>
>> To keep the neat designing feature but get rid of T.Type we could abuse
>> generic typealiases here:
>>
>> // T.Type would be only visible here but is disallowed in public declarations
>> // in favor of `Metatype`
>> public typealias Metatype = T.Type
>>
>> public struct Type : Hashable, CustomStringConvertible, 
>> CustomDebugStringConvertible {
>>
>> …
>> public var metatype: Metatype { return Type.metatype }
>>
>> // Internally `.self` should be renamed to `.metatype` and return
>> // a metatype instance
>> public static var metatype: Metatype { return T.metatype }
>> …
>> }
>>
>> That way the sample from above won’t break from its designing point, but
>> will require some refactoring:
>>
>> extension MemoryLayout {
>> init(_ : @autoclosure () -> T) {}
>> public static func of(_ candidate : @autoclosure () -> T) -> 
>> Metatype {
>> return dynamicType(MemoryLayout.init(candidate)).metatype
>> }
>> }
>>
>>  If you wish, Type in my version is rebranded metatype T.Type.
>
>> We should also mention that dynamic casts need some 

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

[Anton Zhilin via swift-evolution]

I didn't send the link to evolution, so here it is:
https://gist.github.com/Anton3/08a069a3b6f634bece7ad666922741d2

Response inline:

2016-07-14 20:52 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:
>
>
>-
>
>There is a small typo (SE–0090 is not accepted yet) - only in the
>first example:
>
>func unsafeBitCast(_: T, to: U.Type)
>unsafeBitCast(10, to: Double)
>
>// The second line should be
>unsafeBitCast(10, to: Double.self)
>
>
> I'll fix the examples.

>
>-
>
>Size and internal structure of Type will be the same as of T.Type
>
>- Do we really need this to be the same?
>
> Yes, otherwise we cannot remove T.Type. If you want to store *additional*
data in Type and have a reason for that, then why not.

>
>-
>   -
>
>Values of Type store identifiers of U such that U: T.
>
>- Why would we want to store more than one unique identifier?
>
> Another try at explaining my model of Type. Warning: it will be a long
read this time!

During compilation, each type is assigned a unique integer identifier.
Let's suppose there are only three types used in the program: Any is 1,
BaseClass is 2, DerivedClass is 3.

Values of type Type can contain one of identifiers 1, 2 or 3.
Values of type Type can contain one of identifiers 2 or 3.
Values of type Type can only contain 3.

The same in terms of sets:

Type = { 1, 2, 3 }
Type = { 2, 3 }
Type = { 3 }

In terms of set theory, type Type contains identifiers of all types U
that are subtypes of T.
If U1, ..., Uk are subtypes of T used in the program, then Type = { T,
U1, ..., Uk }

Example:

let x = Type()
let y = Type(casting: x)
Type.size  //=> 50
Type.size  //=> 40
x.size //=> 50
y.size //=> 50

Again, example with dynamicType. Let's suppose that T = BaseClass and
DerivedClass:
BaseClass.

func dynamicType(_ value: BaseClass) -> Type

We can't know statically, which type information it returns.
Type = { 2, 3 }
At runtime, we get to know if value is of BaseClass or of DerivedClass.

In my version, Type should get all capabilities and all syntax of T.Type,
therefore we should be able to drop the latter.

Again, main idea: *rename* T.Type to Type, *maintain* its behaviour and
tweak syntax.

Actually I thought for a while about the negative effect of fully removing
> metatypes from the language. Metatypes allow us to build neat looking
> execution branches like showed in SE–0101.
>
> extension MemoryLayout {
> init(_ : @autoclosure () -> T) {}
> public static func of(_ candidate : @autoclosure () -> T) -> 
> MemoryLayout.Type {
> return MemoryLayout.init(candidate).dynamicType
> }
> }
>
> // Value
> let x: UInt8 = 5
> MemoryLayout.of(x).size // 1
> MemoryLayout.of(1).size // 8
> MemoryLayout.of("hello").stride // 24
> MemoryLayout.of(29.2).alignment // 8
>
> I wouldn’t want to throw this away.
>
We won't lose literally anything by moving from T.Type to Type.

of returns MemoryLayout.Type, which currently doesn't have size
property. Could you correct your example?

> I played with the idea of keeping T.Type internally but disallow it in
> public declarations. Furthermore metatypes would still exist, but can only
> be instantiated through Type.metatype or Type().metatype.
>
> To keep the neat designing feature but get rid of T.Type we could abuse
> generic typealiases here:
>
> // T.Type would be only visible here but is disallowed in public declarations
> // in favor of `Metatype`
> public typealias Metatype = T.Type
>
> public struct Type : Hashable, CustomStringConvertible, 
> CustomDebugStringConvertible {
>
> …
> public var metatype: Metatype { return Type.metatype }
>
> // Internally `.self` should be renamed to `.metatype` and return
> // a metatype instance
> public static var metatype: Metatype { return T.metatype }
> …
> }
>
> That way the sample from above won’t break from its designing point, but
> will require some refactoring:
>
> extension MemoryLayout {
> init(_ : @autoclosure () -> T) {}
> public static func of(_ candidate : @autoclosure () -> T) -> 
> Metatype {
> return dynamicType(MemoryLayout.init(candidate)).metatype
> }
> }
>
>  If you wish, Type in my version is rebranded metatype T.Type.

> We should also mention that dynamic casts need some tweaking to work with 
> Type.
>
> In the gist, I suggest to live without tweaking and replace dynamic casts
with failable initializer of Type. That will tweaking syntax of that
casts, but reduce amount of magic.

> And one more thing:
>
> public var size: Int  { get }
> public var stride: Int{ get }
> public var alignment: Int { get }
>
> public static var size: Int  { return Type().size }
> public static var stride: Int{ return Type().stride }
> public static var alignment: Int { return Type().alignment }
>
> Shouldn’t these work exactly the opposite way? If in the future Type
> would be extended with 

Re: [swift-evolution] [Meta] Proposal status page

[Jacob Bandes-Storch via swift-evolution]

It occurs to me that moving swift-evolution to use *only* a gh-pages
branch, like swift-internals does, would allow this to work without JS.

On Thu, Jul 14, 2016 at 1:30 AM, Jacob Bandes-Storch 
wrote:

> I got sidetracked today and mocked up a proposal "status page":
>
> http://jtbandes.github.io/swift-evolution/
>
> This moves the proposal status info (currently in README.md) into a
> separate "source of truth":
>
> https://github.com/jtbandes/swift-evolution/blob/master/proposals.xml
>
> The status page is then generated from the source of truth using XSLT.
> Unfortunately, in order to get this working on GitHub Pages, I had to load
> the files using JavaScript (otherwise the browser blocks the cross-origin
> requests):
> https://github.com/jtbandes/swift-evolution/blob/gh-pages/index.html.
>
>
> If we wanted to adopt this for the official swift-evolution repo, the
> steps would be:
>
> 1. push the XML and XSL files to master
>
> 2. push a gh-pages branch with the status page
>
> 3. update README.md on master to point to the status page, rather than
> duplicating all the information.
>
>
> Thoughts? Tweaks? Insults?
>
> Jacob
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Dan Appel via swift-evolution]

Result is one way to do it, but I'm not a huge fan. I would personally
prefer this kind of api.

doSomethingAsync { getResult in
do {
let result = try getResult()
} catch {
// handle error
}
}

Where the signature would go from

func doSomethingAsync(callback: (T?, Error?) -> ())

to

func doSomethingAsync(callback: (() throws -> T) -> ())

No new types defined; the current callbacks just have to be wrapped in
another closure.
On Thu, Jul 14, 2016 at 10:54 AM Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> I know it’s late, but I was wondering what the community thought of this:
>
> MOTIVATION:
>
> With the acceptance of SE-0112, the error handling picture looks much
> stronger for Swift 3, but there is still one area of awkwardness remaining,
> in the area of returns from asynchronous methods. Specifically, many
> asynchronous APIs in the Cocoa framework are declared like this:
>
> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar *
> _Nullable, NSError * _Nullable))completionHandler;
>
> This will get imported into Swift as something like this:
>
> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
>
> The intention of this API is that either the operation will succeed, and
> something will be passed in the Bar parameter, and the error will be nil,
> or else the operation will fail, and then the error parameter will be
> populated while the Bar parameter is nil. However, this intention is not
> expressed in the API, since the syntax leaves the possibility that both
> parameters could be nil, or that they could both be non-nil. This forces
> the developer to do needless and repetitive checks against a case which in
> practice shouldn’t occur, as below:
>
> doSomething(foo: foo) { bar, error in
> if let bar = bar {
> // handle success case
> } else if let error = error {
> self.handleError(error)
> } else {
> self.handleError(NSCocoaError.FileReadUnknownError)
> }
> }
>
> This results in the dreaded “untested code.”
>
> Note that while it is possible that the developer could simply
> force-unwrap error in the failure case, this leaves the programs open to
> crashes in the case where a misbehaved API forgets to populate the error on
> failure, whereas some kind of default error would be more appropriate. The
> do/try/catch mechanism works around this by returning a generic _NilError
> in cases where this occurs.
>
> PROPOSED SOLUTION:
>
> Since the pattern for an async API that returns an error in the Cocoa APIs
> is very similar to the pattern for a synchronous one, we can handle it in a
> very similar way. To do this, we introduce a new Result enum type. We then
> bridge asynchronous Cocoa APIs to return this Result type instead of
> optional values. This more clearly expresses to the user the intent of the
> API.
>
> In addition to clarifying many Cocoa interfaces, this will provide a
> standard format for asynchronous APIs that return errors, opening the way
> for these APIs to be seamlessly integrated into future asynchronous
> features added to Swift 4 and beyond, in a way that could seamlessly
> interact with the do/try/catch feature as well.
>
> DETAILED DESIGN:
>
> 1. We introduce a Result type, which looks like this:
>
> enum Result {
> case success(T)
> case error(Error)
> }
>
> 2. Methods that return one parameter asynchronously with an error are
> bridged like this:
>
> func doSomething(foo: Foo, completionHandler: (Result) -> ())
>
> and are used like this:
>
> doSomething(foo: foo) { result in
> switch result {
> case let .success(bar):
> // handle success
> case let .error(error):
> self.handleError(error)
> }
> }
>
> 3. Methods that return multiple parameters asynchronously with an error
> are bridged using a tuple:
>
> func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())
>
> and are used like this:
>
> doSomething(foo: foo) { result in
> switch result {
> case let .success(bar, baz):
> // handle success
> case let .error(error):
> self.handleError(error)
> }
> }
>
> 4. Methods that return only an error and nothing else are bridged as they
> are currently, with the exception of bridging NSError to Error as in
> SE-0112:
>
> func doSomething(foo: Foo, completionHandler: (Error?) -> ())
>
> and are used as they currently are:
>
> doSomething(foo: foo) { error in
> if let error = error {
> // handle error
> } else {
> // handle success
> }
> }
>
> 5. For the case in part 2, the bridge works much like the do/try/catch
> mechanism. If the first parameter is non-nil, it is returned inside the
> .success case. If it is nil, then the error is returned inside the .error
> case if it is non-nil, and otherwise _NilError is returned in the 

Re: [swift-evolution] [SE-0088] Dispatch API names

[Matt Wright via swift-evolution]

> On Jul 14, 2016, at 3:44 AM, Karl  wrote:
> 
> I just discovered this thread by accident - thank the Lord I’m not the only 
> one who feels like this about the new Dispatch API!
> 
>> On 8 Jul 2016, at 04:16, Darren Mo via swift-evolution 
>>  wrote:
>> 
>> Should I create a bug report for changing `DispatchQueue.after` and 
>> `DispatchSource.read`?
>> 
>> Darren
>> 
>>> On Jun 21, 2016, at 7:35 PM, Darren Mo  wrote:
>>> 
>>> On Jun 21, 2016, at 5:28 PM, Matt Wright  wrote:
> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution 
>  wrote:
> DispatchQueue.after(when:execute:)
> --
> This one simply doesn’t read grammatically. For example, 
> `queue.after(when: .now) { … }` becomes “queue, after when now …”. Since 
> dispatch_after is semantically just an extended version of dispatch_async 
> (I think), we can name this .executeAsync(after:_:).
 
 I replied to messages out of order but I agree, moving `.after` onto 
 .async seems like the more natural place for it to live.
>>> 
>>> Yay!
>>> 

To somewhat follow up on Darren’s suggestion: after internal discussion, moving 
`.after` into `.async` isn’t as good an idea as I had hoped. The behaviour of 
`.after`, both in execution and performance, differ substantially from `.async`.

> 
> So long as the signature then reads grammatically - I had a little battle 
> about this yesterday: 
> http://comments.gmane.org/gmane.comp.lang.swift.evolution/23867
> 
> To summarise:
> - “after” should take a plain time interval
> - “deadline” is just simply the wrong word - means something else entirely
> - since we can’t take an interval without a clock, we need a default clock
> - but the nuances with those clocks are very important and a source of subtle 
> bugs, so we should also ask for precise intention
> 
> => I think we should split DispatchQueue.after() based on clock type. This 
> would allow us to provide a default value for “now”, meaning we can also 
> accept plain time intervals, as the resulting API would be explicit about the 
> clock nuances that are often overlooked.

I don’t think this topic needs forking and rehashing on this thread too.

> 
> DispatchSource subclass names
> -
> Why is it DispatchSourceMemoryPressure instead of 
> MemoryPressureDispatchSource? I don’t think I’ve ever seen subclass names 
> where the superclass part is at the beginning of the name.
 
 I’m not so keen to remove the Dispatch prefix from the front of the source 
 types, given that we avoided doing that for the remainder of the module.
>>> 
>>> What is the rationale for keeping the Dispatch prefix anyways? (I couldn’t 
>>> find it in the archives.)
> 
> I would also like to know this. I really don’t like typing Dispatch... every 
> time. It doesn’t seem to be very forgiving with code-completion.

This was covered somewhat during initial evolution, after discussion with the 
core team we decided to keep the Dispatch prefix. Several of the class names 
make more contextual sense with a Dispatch prefix, where they would not 
otherwise; Queues, Groups, etc. Secondly, Dispatch is implicitly imported by 
Foundation and we feel that keeping the prefix is clearer to the developer what 
it is you’re actually using.

> 
> Also, dispatch code tends to contain a fair amount of nested closures. It’s 
> nice to keep the line lengths short in that case.
> 
> Karl

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

[swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Charles Srstka via swift-evolution]

I know it’s late, but I was wondering what the community thought of this:

MOTIVATION:

With the acceptance of SE-0112, the error handling picture looks much stronger 
for Swift 3, but there is still one area of awkwardness remaining, in the area 
of returns from asynchronous methods. Specifically, many asynchronous APIs in 
the Cocoa framework are declared like this:

- (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
_Nullable, NSError * _Nullable))completionHandler;

This will get imported into Swift as something like this:

func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())

The intention of this API is that either the operation will succeed, and 
something will be passed in the Bar parameter, and the error will be nil, or 
else the operation will fail, and then the error parameter will be populated 
while the Bar parameter is nil. However, this intention is not expressed in the 
API, since the syntax leaves the possibility that both parameters could be nil, 
or that they could both be non-nil. This forces the developer to do needless 
and repetitive checks against a case which in practice shouldn’t occur, as 
below:

doSomething(foo: foo) { bar, error in
if let bar = bar {
// handle success case
} else if let error = error {
self.handleError(error)
} else {
self.handleError(NSCocoaError.FileReadUnknownError)
}
}

This results in the dreaded “untested code.”

Note that while it is possible that the developer could simply force-unwrap 
error in the failure case, this leaves the programs open to crashes in the case 
where a misbehaved API forgets to populate the error on failure, whereas some 
kind of default error would be more appropriate. The do/try/catch mechanism 
works around this by returning a generic _NilError in cases where this occurs.

PROPOSED SOLUTION:

Since the pattern for an async API that returns an error in the Cocoa APIs is 
very similar to the pattern for a synchronous one, we can handle it in a very 
similar way. To do this, we introduce a new Result enum type. We then bridge 
asynchronous Cocoa APIs to return this Result type instead of optional values. 
This more clearly expresses to the user the intent of the API.

In addition to clarifying many Cocoa interfaces, this will provide a standard 
format for asynchronous APIs that return errors, opening the way for these APIs 
to be seamlessly integrated into future asynchronous features added to Swift 4 
and beyond, in a way that could seamlessly interact with the do/try/catch 
feature as well.

DETAILED DESIGN:

1. We introduce a Result type, which looks like this:

enum Result {
case success(T)
case error(Error)
}

2. Methods that return one parameter asynchronously with an error are bridged 
like this:

func doSomething(foo: Foo, completionHandler: (Result) -> ())

and are used like this:

doSomething(foo: foo) { result in
switch result {
case let .success(bar):
// handle success
case let .error(error):
self.handleError(error)
}
}

3. Methods that return multiple parameters asynchronously with an error are 
bridged using a tuple:

func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())

and are used like this:

doSomething(foo: foo) { result in
switch result {
case let .success(bar, baz):
// handle success
case let .error(error):
self.handleError(error)
}
}

4. Methods that return only an error and nothing else are bridged as they are 
currently, with the exception of bridging NSError to Error as in SE-0112:

func doSomething(foo: Foo, completionHandler: (Error?) -> ())

and are used as they currently are:

doSomething(foo: foo) { error in
if let error = error {
// handle error
} else {
// handle success
}
}

5. For the case in part 2, the bridge works much like the do/try/catch 
mechanism. If the first parameter is non-nil, it is returned inside the 
.success case. If it is nil, then the error is returned inside the .error case 
if it is non-nil, and otherwise _NilError is returned in the .error case.

6. For the case in part 3, in which there are multiple return values, the same 
pattern is followed, with the exception that we introduce a new Objective-C 
annotation. I am provisionally naming this annotation NS_REQUIRED_RETURN_VALUE, 
but the developer team can of course rename this annotation to whatever they 
find appropriate. All parameters annotated with NS_REQUIRED RETURN_VALUE will 
be required to be non-nil in order to avoid triggering the error case. 
Parameters not annotated with NS_REQUIRED RETURN_VALUE will be inserted into 
the tuple as optionals. If there are no parameters annotated with NS_REQUIRED 
RETURN_VALUE, the first parameter will be implicitly annotated as such. This 

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

[Adrian Zubarev via swift-evolution]

Okay I carefully read the gist and here is my feedback:

First of all thank you for combining your thoughts with mine.

There is a small typo (SE–0090 is not accepted yet) - only in the first example:

func unsafeBitCast(_: T, to: U.Type)
unsafeBitCast(10, to: Double)
 
// The second line should be
unsafeBitCast(10, to: Double.self)
Size and internal structure of Type will be the same as of T.Type
Do we really need this to be the same?
Values of Type store identifiers of U such that U: T.
Why would we want to store more than one unique identifier?
Actually I thought for a while about the negative effect of fully removing 
metatypes from the language. Metatypes allow us to build neat looking execution 
branches like showed in SE–0101.

extension MemoryLayout {
init(_ : @autoclosure () -> T) {}
public static func of(_ candidate : @autoclosure () -> T) -> 
MemoryLayout.Type {
return MemoryLayout.init(candidate).dynamicType
}
}

// Value
let x: UInt8 = 5
MemoryLayout.of(x).size // 1
MemoryLayout.of(1).size // 8
MemoryLayout.of("hello").stride // 24
MemoryLayout.of(29.2).alignment // 8
I wouldn’t want to throw this away.

I played with the idea of keeping T.Type internally but disallow it in public 
declarations. Furthermore metatypes would still exist, but can only be 
instantiated through Type.metatype or Type().metatype.

To keep the neat designing feature but get rid of T.Type we could abuse generic 
typealiases here:

// T.Type would be only visible here but is disallowed in public declarations
// in favor of `Metatype`
public typealias Metatype = T.Type

public struct Type : Hashable, CustomStringConvertible, 
CustomDebugStringConvertible {

…
public var metatype: Metatype { return Type.metatype }
 
// Internally `.self` should be renamed to `.metatype` and return
// a metatype instance  
public static var metatype: Metatype { return T.metatype }
…
}
That way the sample from above won’t break from its designing point, but will 
require some refactoring:

extension MemoryLayout {
init(_ : @autoclosure () -> T) {}
public static func of(_ candidate : @autoclosure () -> T) -> 
Metatype {
return dynamicType(MemoryLayout.init(candidate)).metatype
}
}
I’m aware that we are moving size etc. into Type but the example I just used 
was to show that metatypes are still very useful in terms of designing neat 
looking apis.

That’s why I’d suggest that our proposal should tackle solving SE–0090, opening 
the door for reflections, combining SE–0101 and providing an easier 
implementation for SE–0096.

Internally the core team might rename T.Type to T.Metatype to sort out any 
confusion. And we still would migrate all public T.Type to use Type instead.

PS:

We should also mention that dynamic casts need some tweaking to work with 
Type.

And one more thing:

public var size: Int  { get }
public var stride: Int{ get }
public var alignment: Int { get }

public static var size: Int  { return Type().size }
public static var stride: Int{ return Type().stride }
public static var alignment: Int { return Type().alignment }
Shouldn’t these work exactly the opposite way? If in the future Type would 
be extended with reflection functionality and contain more stored properties, 
it would be lightweight to compute size etc. from static size without the need 
of instantiating the whole type.

public var size: Int  { return Type.size  }
public var stride: Int{ return Type.stride }
public var alignment: Int { return Type.alignment }

public static var size: Int  { get }
public static var stride: Int{ get }
public static var alignment: Int { get }


-- 
Adrian Zubarev
Sent with Airmail

Am 14. Juli 2016 um 12:39:05, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

Plase take a look:
https://gist.github.com/Anton3/08a069a3b6f634bece7ad666922741d2

2016-07-14 0:38 GMT+03:00 Adrian Zubarev via swift-evolution 
:
I’m still not fully convinced about fully removing the access to the metatype.

If you look at Ericas and Daves current proposal for MemoryLayout it would 
completely break and it would become impossible to build something like this.

And yes I borrowed the idea of putting properties like size into Type from 
SE–0101. That was mentioned in my previews posts.

If we remove .Type, how’d we access static members in other types like 
MemoryLayout?

This is another contra argument to consider.
@Erica @Dave: Any statement on our conversation about Type?

I apologize that this whole idea raised in parallel to your proposal.

PS: We can merge our ideas into a single formal proposal. Ping me off-list when 
you get some time tomorrow.

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

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Ben Rimmington via swift-evolution]

> On 14 Jul 2016, at 05:47, Chris Lattner via swift-evolution 
>  wrote:
> 
> Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>  
> 
> Shortly after SE-0111 was accepted last week, several people newly noticed 
> the proposal and started a discussion about how it appears to be a regression 
> for closure parameters (e.g. callbacks) that could formerly carry labels, but 
> are now not allowed to.  These folks observed that it would be more 
> expressive (and consistent with the rest of Swift) to allow parameter labels 
> in function types, because the invocation site of a closure “should" be 
> required to provide those labels.  The core team has been following the 
> discussion, agrees that this is a concern, and wants to update the community 
> with a path forward.
> 
> The reality of the situation is that the current implementation of parameter 
> labels in function types is inherently broken.  Specifically, as one example, 
> there is an implicit conversion from "(a: Int) -> Int” to “(Int) -> Int”.  
> However, there is also an implicit conversion from "(Int) -> Int” to “(b : 
> Int) -> Int”.  This means that the compiler currently allows converting from 
> “(a: Int) -> Int” to “(b: Int) -> Int”, which doesn’t make sense, introduces 
> surprising behavior, introduces complexity into the compiler implementation, 
> and is generally a problem.  We do have one specific hack to prevent 
> conversion of (e.g.) “(a : Int, b : Int) -> Void” to “(b : Int, a : Int) -> 
> Void”, but this only triggers in specific cases.  There are other more 
> complex cases as well, e.g. when using generics "T<(a : Int)->Int>” cannot be 
> considered compatible with "T<(b : Int)->Int>”.
> 
> These problems are what initially motivated SE-0111.  However, given the 
> feedback, the core team went back to the drawing board to determine whether: 
> a) SE-0111 by itself is the right long term answer, b) whether there were 
> alternate models that could solve the same problems in a different way, or c) 
> whether SE-0111 was the right first step to "ultimate glory" in the field of 
> closure parameter labels.  After a long discussion, and many alternatives 
> considered, the core team believes in c), that SE-0111 (with a minor 
> modification) is the right step for Swift 3, because it paves the way for the 
> right model over the long term.
> 
> 8<
> 
> The specific revision requested by the core team to SE-0111 is that all 
> “cosmetic” labels should be required to include an API name of _.  For 
> example, this would not be allowed:
> 
>var op : (lhs : Int, rhs : Int) -> Int
> 
> instead, it should be spelled as:
> 
>var op : (_ lhs : Int, _ rhs : Int) -> Int
> 
> With this change, we believe that we have paved the way for a purely additive 
> proposal (and thus, post-Swift 3) that will restore the expressive capability 
> of closures with parameter labels.  
> 
> 8<
> 
> Here is a sketch of how that would work, in two steps:
> 
> 
> First, we extend declaration names for variables, properties, and parameters 
> to allow *parameter names* as part of their declaration name.  For example:
> 
>var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
>x = op(lhs: 1, rhs: 2)   // use of the variable or property.
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // use of the parameter
>}
>foo(opToUse: +) // call of the function
> 
> This will restore the ability to express the idea of a closure parameter that 
> carries labels as part of its declaration, without requiring parameter labels 
> to be part of the type system (allowing, e.g. the operator + to be passed 
> into something that requires parameter labels).

During the review, Michael Ilseman suggested using SE-0021 for declaration 
names.



Your example "op(lhs:,rhs:)" would be "op(lhs:rhs:)" instead (i.e. without the 
comma).

-- Ben

> Second, extend the rules for function types to allow parameter API labels *if 
> and only if* they are used as the type of a declaration that allows parameter 
> labels, and interpret them as a sugar form for providing those labels on the 
> underlying declaration.  This means that the example above could be spelled 
> as:
> 
>var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
>x = op(lhs: 1, rhs: 2)  // Same as above
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // Same as above.
>}
>foo(opToUse: +)

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Erica Sadun via swift-evolution]

> On Jul 14, 2016, at 10:01 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 14, 2016, at 1:20 AM, Taras Zakharko  wrote:
>> 
>> Great!
>> 
>> This cleanly separates between the type and the name/signature! Simple and 
>> consistent. Thank you!
>> 
>> A clarification question: do i understand correctly that steps 2 and 3 will 
>> not be included in Swift 3 due time constraints?
> 
> Yes, we are sadly really almost out of time for Swift 3 and need to remain as 
> hyper-focused as possible.  There is always another release.
> 
> -Chris

I was under the impression that Swift 2.3 was going to go gold in September for 
App Store submissions and Swift 3 in December. Is my timeline wrong?

-- E

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

Re: [swift-evolution] executing a string

[Tino Heth via swift-evolution]

Turning strings into selectors is a powerful feature as well ;-) — but afaik, 
Swift doesn't use another sort of special dispatch besides what is known from 
other languages.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Chris Lattner via swift-evolution]

> On Jul 14, 2016, at 1:20 AM, Taras Zakharko  wrote:
> 
> Great!
> 
> This cleanly separates between the type and the name/signature! Simple and 
> consistent. Thank you!
> 
> A clarification question: do i understand correctly that steps 2 and 3 will 
> not be included in Swift 3 due time constraints?

Yes, we are sadly really almost out of time for Swift 3 and need to remain as 
hyper-focused as possible.  There is always another release.

-Chris

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

[swift-evolution] executing a string

[Ford Prefect via swift-evolution]

One of the major security flaws of Obj C is

the ability to convert a string into a selector, which

permits using private methods by constructing selectors

at runtime long after the app store review has been completed.

Does Swift do away with that? I understand it doesn't

use selectors per se but is there an analogous mechanism?

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

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

[Tino Heth via swift-evolution]

I share the minor concerns that have been expressed so far.
My first thought on this topic ("MyStruct.size") had a obvious flaw, but I 
wouldn't fear name collisions with something like "MyStruct.memoryLayout.size".
This one most likely has issues as well, but imho they aren't that obvious and 
deserve being discussed in the alternatives-section (or a short answer here to 
wake up my tired mind ;-)

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

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Vladimir.S via swift-evolution]

Just +100. One more wise decision from the core team. Thank you for all of 
your work.


On 14.07.2016 7:47, Chris Lattner via swift-evolution wrote:

Proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

Shortly after SE-0111 was accepted last week, several people newly noticed
the proposal and started a discussion about how it appears to be a
regression for closure parameters (e.g. callbacks) that could formerly
carry labels, but are now not allowed to.  These folks observed that it
would be more expressive (and consistent with the rest of Swift) to allow
parameter labels in function types, because the invocation site of a
closure “should" be required to provide those labels.  The core team has
been following the discussion, agrees that this is a concern, and wants to
update the community with a path forward.

The reality of the situation is that the current implementation of
parameter labels in function types is inherently broken.  Specifically, as
one example, there is an implicit conversion from "(a: Int) -> Int” to
“(Int) -> Int”.  However, there is also an implicit conversion from "(Int)
-> Int” to “(b : Int) -> Int”.  This means that the compiler currently
allows converting from “(a: Int) -> Int” to “(b: Int) -> Int”, which
doesn’t make sense, introduces surprising behavior, introduces complexity
into the compiler implementation, and is generally a problem.  We do have
one specific hack to prevent conversion of (e.g.) “(a : Int, b : Int) ->
Void” to “(b : Int, a : Int) -> Void”, but this only triggers in specific
cases.  There are other more complex cases as well, e.g. when using
generics "T<(a : Int)->Int>” cannot be considered compatible with "T<(b :
Int)->Int>”.

These problems are what initially motivated SE-0111.  However, given the
feedback, the core team went back to the drawing board to determine
whether: a) SE-0111 by itself is the right long term answer, b) whether
there were alternate models that could solve the same problems in a
different way, or c) whether SE-0111 was the right first step to "ultimate
glory" in the field of closure parameter labels.  After a long discussion,
and many alternatives considered, the core team believes in c), that
SE-0111 (with a minor modification) is the right step for Swift 3, because
it paves the way for the right model over the long term.

8<

The specific revision requested by the core team to SE-0111 is that all
“cosmetic” labels should be required to include an API name of _.  For
example, this would not be allowed:

   var op : (lhs : Int, rhs : Int) -> Int

instead, it should be spelled as:

   var op : (_ lhs : Int, _ rhs : Int) -> Int

With this change, we believe that we have paved the way for a purely
additive proposal (and thus, post-Swift 3) that will restore the expressive
capability of closures with parameter labels.

8<

Here is a sketch of how that would work, in two steps:


First, we extend declaration names for variables, properties, and
parameters to allow *parameter names* as part of their declaration name.
 For example:

   var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
   x = op(lhs: 1, rhs: 2)   // use of the variable or property.

   // API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
   func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
 x = op(lhs: 1, rhs: 2) // use of the parameter
   }
   foo(opToUse: +) // call of the function

This will restore the ability to express the idea of a closure parameter
that carries labels as part of its declaration, without requiring parameter
labels to be part of the type system (allowing, e.g. the operator + to be
passed into something that requires parameter labels).


Second, extend the rules for function types to allow parameter API labels
*if and only if* they are used as the type of a declaration that allows
parameter labels, and interpret them as a sugar form for providing those
labels on the underlying declaration.  This means that the example above
could be spelled as:

   var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
   x = op(lhs: 1, rhs: 2)  // Same as above

   // API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
   func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
 x = op(lhs: 1, rhs: 2) // Same as above.
   }
   foo(opToUse: +)  // Same as above.


These two steps will provide the simple and expressive design approach that
we have now, without all of the problems that representing parameter labels
in the type system introduces.  The core team believes that the temporary
regression in expressiveness is an acceptable loss for Swift 3,
particularly given that this will have no impact on Cocoa or the standard
library.  In the case of Cocoa, recall that C and Objective-C don’t have
parameter labels on their corresponding concepts (Blocks and C function

Re: [swift-evolution] [SE-0088] Dispatch API names

[Karl via swift-evolution]

I just discovered this thread by accident - thank the Lord I’m not the only one 
who feels like this about the new Dispatch API!

> On 8 Jul 2016, at 04:16, Darren Mo via swift-evolution 
>  wrote:
> 
> Should I create a bug report for changing `DispatchQueue.after` and 
> `DispatchSource.read`?
> 
> Darren
> 
>> On Jun 21, 2016, at 7:35 PM, Darren Mo > > wrote:
>> 
>> On Jun 21, 2016, at 5:28 PM, Matt Wright > > wrote:
 On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution 
 > wrote:
 DispatchQueue.after(when:execute:)
 --
 This one simply doesn’t read grammatically. For example, 
 `queue.after(when: .now) { … }` becomes “queue, after when now …”. Since 
 dispatch_after is semantically just an extended version of dispatch_async 
 (I think), we can name this .executeAsync(after:_:).
>>> 
>>> I replied to messages out of order but I agree, moving `.after` onto .async 
>>> seems like the more natural place for it to live.
>> 
>> Yay!
>> 

So long as the signature then reads grammatically - I had a little battle about 
this yesterday: http://comments.gmane.org/gmane.comp.lang.swift.evolution/23867

To summarise:
- “after” should take a plain time interval
- “deadline” is just simply the wrong word - means something else entirely
- since we can’t take an interval without a clock, we need a default clock
- but the nuances with those clocks are very important and a source of subtle 
bugs, so we should also ask for precise intention

=> I think we should split DispatchQueue.after() based on clock type. This 
would allow us to provide a default value for “now”, meaning we can also accept 
plain time intervals, as the resulting API would be explicit about the clock 
nuances that are often overlooked.

 DispatchSource subclass names
 -
 Why is it DispatchSourceMemoryPressure instead of 
 MemoryPressureDispatchSource? I don’t think I’ve ever seen subclass names 
 where the superclass part is at the beginning of the name.
>>> 
>>> I’m not so keen to remove the Dispatch prefix from the front of the source 
>>> types, given that we avoided doing that for the remainder of the module.
>> 
>> What is the rationale for keeping the Dispatch prefix anyways? (I couldn’t 
>> find it in the archives.)

I would also like to know this. I really don’t like typing Dispatch... every 
time. It doesn’t seem to be very forgiving with code-completion.

Also, dispatch code tends to contain a fair amount of nested closures. It’s 
nice to keep the line lengths short in that case.

Karl


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

[swift-evolution] [Meta] Proposal status page

[Jacob Bandes-Storch via swift-evolution]

I got sidetracked today and mocked up a proposal "status page":

http://jtbandes.github.io/swift-evolution/

This moves the proposal status info (currently in README.md) into a
separate "source of truth":

https://github.com/jtbandes/swift-evolution/blob/master/proposals.xml

The status page is then generated from the source of truth using XSLT.
Unfortunately, in order to get this working on GitHub Pages, I had to load
the files using JavaScript (otherwise the browser blocks the cross-origin
requests):
https://github.com/jtbandes/swift-evolution/blob/gh-pages/index.html.


If we wanted to adopt this for the official swift-evolution repo, the steps
would be:

1. push the XML and XSL files to master

2. push a gh-pages branch with the status page

3. update README.md on master to point to the status page, rather than
duplicating all the information.


Thoughts? Tweaks? Insults?

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

Re: [swift-evolution] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Taras Zakharko via swift-evolution]

Great!

This cleanly separates between the type and the name/signature! Simple and 
consistent. Thank you!

A clarification question: do i understand correctly that steps 2 and 3 will not 
be included in Swift 3 due time constraints?

— T


> On 14 Jul 2016, at 06:47, Chris Lattner via swift-evolution 
>  wrote:
> 
> Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>  
> 
> Shortly after SE-0111 was accepted last week, several people newly noticed 
> the proposal and started a discussion about how it appears to be a regression 
> for closure parameters (e.g. callbacks) that could formerly carry labels, but 
> are now not allowed to.  These folks observed that it would be more 
> expressive (and consistent with the rest of Swift) to allow parameter labels 
> in function types, because the invocation site of a closure “should" be 
> required to provide those labels.  The core team has been following the 
> discussion, agrees that this is a concern, and wants to update the community 
> with a path forward.
> 
> The reality of the situation is that the current implementation of parameter 
> labels in function types is inherently broken.  Specifically, as one example, 
> there is an implicit conversion from "(a: Int) -> Int” to “(Int) -> Int”.  
> However, there is also an implicit conversion from "(Int) -> Int” to “(b : 
> Int) -> Int”.  This means that the compiler currently allows converting from 
> “(a: Int) -> Int” to “(b: Int) -> Int”, which doesn’t make sense, introduces 
> surprising behavior, introduces complexity into the compiler implementation, 
> and is generally a problem.  We do have one specific hack to prevent 
> conversion of (e.g.) “(a : Int, b : Int) -> Void” to “(b : Int, a : Int) -> 
> Void”, but this only triggers in specific cases.  There are other more 
> complex cases as well, e.g. when using generics "T<(a : Int)->Int>” cannot be 
> considered compatible with "T<(b : Int)->Int>”.
> 
> These problems are what initially motivated SE-0111.  However, given the 
> feedback, the core team went back to the drawing board to determine whether: 
> a) SE-0111 by itself is the right long term answer, b) whether there were 
> alternate models that could solve the same problems in a different way, or c) 
> whether SE-0111 was the right first step to "ultimate glory" in the field of 
> closure parameter labels.  After a long discussion, and many alternatives 
> considered, the core team believes in c), that SE-0111 (with a minor 
> modification) is the right step for Swift 3, because it paves the way for the 
> right model over the long term.
> 
> 8<
> 
> The specific revision requested by the core team to SE-0111 is that all 
> “cosmetic” labels should be required to include an API name of _.  For 
> example, this would not be allowed:
> 
>var op : (lhs : Int, rhs : Int) -> Int
> 
> instead, it should be spelled as:
> 
>var op : (_ lhs : Int, _ rhs : Int) -> Int
> 
> With this change, we believe that we have paved the way for a purely additive 
> proposal (and thus, post-Swift 3) that will restore the expressive capability 
> of closures with parameter labels.  
> 
> 8<
> 
> Here is a sketch of how that would work, in two steps:
> 
> 
> First, we extend declaration names for variables, properties, and parameters 
> to allow *parameter names* as part of their declaration name.  For example:
> 
>var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
>x = op(lhs: 1, rhs: 2)   // use of the variable or property.
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // use of the parameter
>}
>foo(opToUse: +) // call of the function
> 
> This will restore the ability to express the idea of a closure parameter that 
> carries labels as part of its declaration, without requiring parameter labels 
> to be part of the type system (allowing, e.g. the operator + to be passed 
> into something that requires parameter labels).
> 
> 
> Second, extend the rules for function types to allow parameter API labels *if 
> and only if* they are used as the type of a declaration that allows parameter 
> labels, and interpret them as a sugar form for providing those labels on the 
> underlying declaration.  This means that the example above could be spelled 
> as:
> 
>var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
>x = op(lhs: 1, rhs: 2)  // Same as above
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // Same as above.
>}
>foo(opToUse: +)  // Same as 

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 14 Jul 2016, at 04:58, Chris Lattner  wrote:
> 
> 
>> On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 9 Jul 2016, at 00:53, Jon Shier  wrote:
>>> 
>>> While I can see why removing the labels from the type system would be a 
>>> good idea, I don’t see why calling the functions with labels would be 
>>> actively prohibited. That’s useful information for the developer to have, 
>>> and if the compiler doesn’t know them in some way, you can be assured 
>>> Xcode’s autocomplete won’t see them. 
>> 
>> I wish the core team or the author of the proposal came to this thread and 
>> engaged again with the community. 
> 
> Hi.  The core team had a long discussion about this today.  I will start a 
> new thread to capture the discussion and update the community on the result 
> of that.  Thank for for all of the input (even after the review period).  The 
> core team really does care (even though everyone is insanely busy right now), 
> we just can’t necessarily respond to every email in real time :-)
> 
> -Chris

Hi Chris,

I do appreciate you are all working hard at closing perhaps the biggest update 
to your new programming language in its history, I also trust you care about 
community input.

This was one of the issues that were key for me in this language (even though 
some people do not miss parameter labels in other languages) and I also felt 
ashamed for not being able to take active part in the review and throwing toys 
out of the pram now, but it is such a small yet defining and clarifying feature 
I had to speak out.

Thank you for listening, talking again about it, and making a plan on how to 
move forward.

> 
>> 
>> I imagine scenarios of callbacks, say for an image downloader or something 
>> that ought to happen asynchronously, injected in a method, stored, and then 
>> used when the asynchronous operation completed one way or the other. 
>> How does this promote local reasoning so much stressed by Apple itself at 
>> WWDC when you have to jump through several hoops to have any idea what the 
>> callbacks does or what parameters and in which order it needs them?
>> 
>> The benefits to the compiler should be weighed against the negative effects 
>> to every day's code and the bugs this may introduce in a safe by default 
>> promise language like Swift.
>> 
 On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution 
  wrote:
 
 I still say that this is the case where we do take a stand and do ask for 
 this proposal to be blocked and re-analised, I cannot believe that we are 
 going to be addingthis kind of incosistency to the language and take 
 readability/ease of local reasoning (which Apple stressed at the last WWDC 
 once again) away. The community and the core team just finished 
 bikeshedding a huge change to how API's are imported and how labels are 
 used and how important they are and then we do this?
 
> On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> Aw. It's really bad that labels are gone for closures at the call site 
>> . IMHO, the same principles that encourage the use of labels for 
>> "normal" function calls should prevail here. 
> No need to feel bad — if I wasn't ignored (it's hard to notice if this 
> happens ;-), the argument has been considered.
> 
> Additionally, those labels may return in the future — although there is a 
> astoundingly long list of features that will be removed because their 
> implementation is flawed, and whose fans have been calmed down with the 
> argument that they'll be re-added in an improved form later ;-)
> 
> ___
> 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] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[David Hart via swift-evolution]



> On 14 Jul 2016, at 06:47, Chris Lattner via swift-evolution 
>  wrote:
> 
> Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>  
> 
> Shortly after SE-0111 was accepted last week, several people newly noticed 
> the proposal and started a discussion about how it appears to be a regression 
> for closure parameters (e.g. callbacks) that could formerly carry labels, but 
> are now not allowed to.  These folks observed that it would be more 
> expressive (and consistent with the rest of Swift) to allow parameter labels 
> in function types, because the invocation site of a closure “should" be 
> required to provide those labels.  The core team has been following the 
> discussion, agrees that this is a concern, and wants to update the community 
> with a path forward.
> 
> The reality of the situation is that the current implementation of parameter 
> labels in function types is inherently broken.  Specifically, as one example, 
> there is an implicit conversion from "(a: Int) -> Int” to “(Int) -> Int”.  
> However, there is also an implicit conversion from "(Int) -> Int” to “(b : 
> Int) -> Int”.  This means that the compiler currently allows converting from 
> “(a: Int) -> Int” to “(b: Int) -> Int”, which doesn’t make sense, introduces 
> surprising behavior, introduces complexity into the compiler implementation, 
> and is generally a problem.  We do have one specific hack to prevent 
> conversion of (e.g.) “(a : Int, b : Int) -> Void” to “(b : Int, a : Int) -> 
> Void”, but this only triggers in specific cases.  There are other more 
> complex cases as well, e.g. when using generics "T<(a : Int)->Int>” cannot be 
> considered compatible with "T<(b : Int)->Int>”.
> 
> These problems are what initially motivated SE-0111.  However, given the 
> feedback, the core team went back to the drawing board to determine whether: 
> a) SE-0111 by itself is the right long term answer, b) whether there were 
> alternate models that could solve the same problems in a different way, or c) 
> whether SE-0111 was the right first step to "ultimate glory" in the field of 
> closure parameter labels.  After a long discussion, and many alternatives 
> considered, the core team believes in c), that SE-0111 (with a minor 
> modification) is the right step for Swift 3, because it paves the way for the 
> right model over the long term.
> 
> 8<
> 
> The specific revision requested by the core team to SE-0111 is that all 
> “cosmetic” labels should be required to include an API name of _.  For 
> example, this would not be allowed:
> 
>var op : (lhs : Int, rhs : Int) -> Int
> 
> instead, it should be spelled as:
> 
>var op : (_ lhs : Int, _ rhs : Int) -> Int
> 
> With this change, we believe that we have paved the way for a purely additive 
> proposal (and thus, post-Swift 3) that will restore the expressive capability 
> of closures with parameter labels.  
> 
> 8<
> 
> Here is a sketch of how that would work, in two steps:
> 
> 
> First, we extend declaration names for variables, properties, and parameters 
> to allow *parameter names* as part of their declaration name.  For example:
> 
>var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
>x = op(lhs: 1, rhs: 2)   // use of the variable or property.
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // use of the parameter
>}
>foo(opToUse: +) // call of the function
> 
> This will restore the ability to express the idea of a closure parameter that 
> carries labels as part of its declaration, without requiring parameter labels 
> to be part of the type system (allowing, e.g. the operator + to be passed 
> into something that requires parameter labels).
> 
> 
> Second, extend the rules for function types to allow parameter API labels *if 
> and only if* they are used as the type of a declaration that allows parameter 
> labels, and interpret them as a sugar form for providing those labels on the 
> underlying declaration.  This means that the example above could be spelled 
> as:
> 
>var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
>x = op(lhs: 1, rhs: 2)  // Same as above
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // Same as above.
>}
>foo(opToUse: +)  // Same as above.
> 
> 
> These two steps will provide the simple and expressive design approach that 
> we have now, without all of the problems that representing parameter labels 
> in the type system introduces.  The core team believes that the