Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Jens Alfke via swift-evolution]

> On Feb 8, 2017, at 4:48 PM, Jan Neumüller via swift-users 
>  wrote:
> 
> May I ask why with so many great open source forums that junk Discourse got 
> chosen? I'm very perplexed by this decision...

I’ve looked at a lot of forum software, and most of the open-source ones are 
pretty poor* in terms of UI and usability.
Discourse is very good as a web app, although its email integration doesn’t 
work that well IMHO, so it’s not really a direct replacement for a mailing list.
If I were proposing something, I’d propose groups.io . 
(Which is also not open source, sorry.)

—Jens

* I’m being diplomatic. Many of them are worse than poor. The word “wretched” 
comes to mind.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0065 A New Model for Collections and Indices

[Jens Alfke via swift-evolution]

> On Apr 10, 2016, at 2:41 PM, Chris Lattner  wrote:
> 
> The review of "A New Model for Collections and Indices" begins now and runs 
> through April 18th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md
>  
> 

That link actually goes to an earlier proposal, 0055, although the visible text 
forms the correct URL. Try this link 

 instead. :)

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

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

[Jens Alfke via swift-evolution]

> 
>> Do you have an imagined use for throwing getters?

The project I work on — a database engine 
 — has an API with a lot of 
things that are conceptually properties, but whose accessors can fail because 
they may have to read or write persistent storage. Some examples are 
Database.documentCount and Document.currentRevision.

In the current (Objective-C) API, some of these are exposed as methods that use 
the standard Cocoa NSError-returning pattern, while some that are very unlikely 
to fail are exposed as actual properties; the implementations either return a 
distinct failure value like nil, or just a default value like 0. I’m not saying 
this is great, but it’s a tradeoff between correctness and ease of use where 
we’ve sometimes leaned toward ease of use.

Failable property accessors would be a big help here, letting us have an 
expressive API where properties are properties, while not losing the ability to 
do proper error handling.

The same applies to subscripts, btw. Since our data stores are key-value 
collections it’s convenient to be able to subscript a database by key to get a 
value. Of course this has the potential to fail due to file corruption, disk 
I/O errors, etc. 

As another example, I’ve done some experimental work in the past on incremental 
JSON parsing; if using such a library, errors are not necessarily discovered up 
front, so it’s possible for accessing an item in a JSON array or dictionary to 
fail with a parse error. (Yes, you could syntax-check ahead of time, but since 
the major purpose of the incremental parsing is speed, that would be 
self-defeating.)

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