[swift-evolution] Swift 3 vs "additive" proposals

[Chris Lattner via swift-evolution]

Hi Everyone,

As I mentioned before, the Swift 3 release is winding down.  There is still 
time left to make changes, but it is very short.  As such, we - as a community 
- need to stay focused on the goals for this release, principally the goal to 
get to source stability.  It is very important for users of Swift that Swift 3 
and the Swift 4 compiler be as compatible as possible.  This is important for 
the continued growth of Swift into new places, like new platforms (which don’t 
get the benefit of Xcode migration) and Swift Playgrounds.

As such, “additive" proposals will need very strong rationale explaining why 
they are critical for the Swift 3 release, and we won’t be merging these 
proposals into the swift-evolution repository unless they have that.  We should 
stay focused on proposals that perfect the features we have, rather than adding 
new ones.

Similarly, general discussions on this mailing list about blue sky additions to 
the language are distracting from our important goals, and the core team 
generally isn’t paying attention to these anyway.  I would really appreciate it 
if we could stay focused on what is important, until the time is right to look 
beyond Swift 3.  This time is in August (which will be here way too soon :-), 
at which point we can look to the future.  I outlined this here earlier:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017701.html

Sorry to be a “downer”, but Swift 3 really is a very important release for the 
Swift developer community as a whole.

-Chris

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

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

[Chris Lattner via swift-evolution]

> On Jun 20, 2016, at 4:22 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
> 
> I hope it's not too late to submit a proposal.
> 
> [stdlib/public/core/FloatingPointTypes.swift.gyb]
> 
>   public struct Float32: BinaryFloatingPoint
>   public struct Float64: BinaryFloatingPoint
>   public struct Float80: BinaryFloatingPoint

FWIW, I think it is extremely unlikely that we would go away from Float/Double.

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

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

[Chris Lattner via swift-evolution]

> On Jun 21, 2016, at 10:41 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 20, 2016, at 11:10 AM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> Good morning all.  Attached is the proposal Harlan Haskins and I will be 
>> submitting shortly about adding generic and `throw`ing subscript 
>> declarations to the language.  
> 
> I mentioned this in the PR, but for everyone’s benefit: Swift 3 is in its 
> late end game.  This is a very important release, and we need to stay focused 
> on the goals for the release, at least until we pivot and start working on 
> releases that follow it.  I expect this time to be sometime around August.  
> Until then, any evolution proposals that are strictly additive will need very 
> strong rationale, explaining why they are critical for inclusion in Swift 3.
> 
> Here is my previous email about this:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017701.html

I will pop this out to its own thread, since it is more general than this topic.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

[Chris Lattner via swift-evolution]

> On Jun 20, 2016, at 11:10 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Good morning all.  Attached is the proposal Harlan Haskins and I will be 
> submitting shortly about adding generic and `throw`ing subscript declarations 
> to the language.  

I mentioned this in the PR, but for everyone’s benefit: Swift 3 is in its late 
end game.  This is a very important release, and we need to stay focused on the 
goals for the release, at least until we pivot and start working on releases 
that follow it.  I expect this time to be sometime around August.  Until then, 
any evolution proposals that are strictly additive will need very strong 
rationale, explaining why they are critical for inclusion in Swift 3.

Here is my previous email about this:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017701.html

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

Re: [swift-evolution] [Pitch] Detecting and working with Optionals from Any

[Charlie Monroe via swift-evolution]

Unfortunately, this is not as easy, because automatic bridging won't be applied:

let myString: String? = "Hello"
let anyValue: Any = myString

myString as? AnyObject // _NSContiguousString
anyValue as? AnyObject // nil, since String is struct

let array: [String]? = ["Hello"]
let anyArray: Any = array
anyArray as? AnyObject // nil
anyArray as? [AnyObject] // nil
array as? AnyObject // ["Hello"]

And this goes for strings, arrays, dictionaries and possibly other types. Which 
means that you need to handle manually all of the bridging to ObjC types, which 
has really grown in Swift 3, taking into account all the Foundation types that 
are now structs.

Should this then be considered compiler bug that bridging isn't taken into 
account?

Nevertheless, I'd still find it useful exposing the isOptional() function as 
well as the asOptional which would allow a cast from Any to Optional which 
is not possible at all at this moment since any such cast will pick up the 
Optional first:

let myString: String? = "Hello"
let anyValue: Any = myString
if let value = anyValue as? Any {
value.dynamicType // This is still Optional, not naively just the 
value of the optional
}



> On Jun 21, 2016, at 8:18 PM, Joe Groff  wrote:
> 
> 'as?' should already do this. If you have an Any that contains an Optional 
> and cast 'any as? T', you'll get the value inside the Optional if there is 
> one, or the cast will fail if the optional is nil or the type doesn't match.
> 
> -Joe
> 
>> On Jun 20, 2016, at 11:00 PM, Charlie Monroe via swift-evolution 
>>  wrote:
>> 
>> I've recently written a CoreData editor on iOS which automatically generates 
>> UI based on the model which is described using classes such as 
>> PrimitiveProperty, etc. Since it automatically sets the value on the entity, 
>> it needs to convert the value to AnyObject in order to pass it to 
>> setValue(_:forKey:), so it needs to be able to detect whether the value is 
>> Optional and in case it is, either transform the non-nil value to AnyObject 
>> (String -> NSString, Array -> NSArray, ...). Which is currently really hard 
>> to achieve: 
>> 
>> var obj: IndexPath? = IndexPath()
>> let anyValue: Any = obj
>> anyValue.dynamicType /// Optional.Type
>> 
>> /// Using only anyValue, determine if it's Optional and retrieve its value 
>> if 
>> /// non-nil as AnyObject.
>> func isOptional(anyValue: Any) -> Bool {
>>// Error: Cannot downcast from 'Any' (aka 'protocol<>') to a more 
>>// optional type 'Optional<_>'
>>return anyValue is Optional
>>return anyValue as? Optional != nil
>>...
>> }
>> 
>> Unless there are major reasons why it's not exposed, I'd propose introducing 
>> a new function isOptional(anyValue: Any) -> Bool, which would simply call 
>> Builtin.isOptional just like _isOptional does in Builtin.swift. (which 
>> pretty much is just taking the current _isOptional, removing underscore and 
>> marking it public).
>> 
>> However, this still doesn't help with the issue of retrieving the value of 
>> the Optional. You now know the value in `anyValue` is Optional, but there is 
>> no good way to cast it to e.g. Optional. Here we're getting into 
>> a vicious cycle that Any can be an Optional which is Any.
>> 
>> My second part of the proposal introduces another function:
>> 
>> func asOptional(anyValue: Any) -> Optional?
>> 
>> Which will:
>> - return nil if !isOptional(anyValue)
>> - return a non-nil value only if `anyValue` contains in fact an Optional of 
>> type T.
>> 
>> Usage:
>> 
>> if let anyObjOptional: AnyObject? = asOptional(anyValue: anyValue) {
>>if let anyObj = anyObjOptional {
>>// anyObj is now the actual content of the optional.
>>}
>> }
>> 
>> As a sidenote, this is my current workaround:
>> 
>> private protocol _XUOptional {
>>var objectValue: AnyObject? { get }
>> }
>> 
>> extension Optional: _XUOptional {
>>var objectValue: AnyObject? {
>>switch self {
>>case .None:
>>return nil
>>case .Some(_):
>>return self! as? AnyObject
>>}
>>}
>> }
>> 
>> if let optional = anyValue as? _XUOptional {
>>let object = optional.objectValue
>>/// ...
>> }
>> 
>> 
>> 
>> ___
>> 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] Thoughts on replacing \() with $() or some other symbol

[Wahlstedt Jyrki via swift-evolution]

> On 22.6.2016, at 1.10, Daniel Resnick via swift-evolution 
> > wrote:
> 
> I also disagree for the same reasons that Gwynne and Brent mentioned: I find 
> '\(...)' easy to read, fine to type, and consistent with other string 
> escaping syntax.

+1

I’m using Finnish keyboard, for \ the key combination is opt-shift-7, then () 
are shift-8 and shift-9, so very easy. Actually, using @ (opt-2) or $ (opt-4) 
would be harder, because one would have to switch hands, using opt with right 
hand and then using left hand for shift for () or opt-shift for {}.
The code is written once, but read maybe thousands of times, so readability is 
immensely more important.

!
! Jyrki Wahlstedt
!   http://www.wahlstedt.fi/jyrki/  
Twitter: @jyrkiw
!
! Our life is no dream; but it ought to become one and perhaps will.
! 



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

[swift-evolution] [Review] SE-0103: Make non-escaping closures the default

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0103: Make non-escaping closures the default" begins now and 
runs through June 27. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md

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

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

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

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


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

Re: [swift-evolution] the "guard" keyword, again

[Chris Lattner via swift-evolution]

> On Jun 21, 2016, at 6:44 AM, Sean Heber via swift-evolution 
>  wrote:
> 
>> In the Commonly Rejected Changes page and in this swift-evolution email to 
>> which it refers, I read that first there was “unless", then “require” then 
>> finally “guard ... else”.
>> 
>> I couldn’t find the earlier discussion in which “unless” was replaced for a 
>> while by “require”, so I am moved to ask, “Was there ever “require … else”, 
>> or was it just “require”? I’ll assume it was just “require”.
> 
> FYI the decisions and discussions that lead to “guard" occurred within Apple 
> well before Swift was open sourced.

Correct.  There is no publicly released Swift version that used ‘unless’, but 
you can see it appear in the changelog.

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

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

[Chris Lattner via swift-evolution]

On Jun 21, 2016, at 12:15 PM, Xiaodi Wu via swift-evolution 
 wrote:
> 
> Any discussion about this ought to start from UAX #31, the Unicode 
> consortium's recommendations on identifiers in programming languages:
> 
> http://unicode.org/reports/tr31/ 
> 
> Section 2.3 specifically calls out the situations in which ZWJ and ZWNJ need 
> to be allowed. The document also describes a stability policy for handling 
> new Unicode versions, other confusability issues, and many of the other 
> problems with adopting Unicode in a programming language's syntax.
> 
> That's a fantastic document--a very edifying read. Given Swift's robust 
> support for Unicode in its core libraries, it's kind of surprising to me that 
> identifiers aren't canonicalized at compile time. From a quick first read, 
> faithful adoption of UAX #31 recommendations would address most if not all of 
> the confusability and zero-width security issues raised in this conversation.
>  

+1

-Chris


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

Re: [swift-evolution] IUO in Swift 3.0

[Chris Lattner via swift-evolution]

> On Jun 21, 2016, at 1:39 PM, Jonathan Cotton via swift-evolution 
>  wrote:
> 
> I was also surprised this type still exists as I'd taken that the proposal 
> was for the removal of IUO as an explicit type, but after some testing of IUO 
> propagation behaviour in Swift 3.0, I'm happy to report the behaviour has 
> been changed to meet the desired behaviour in the spec, specifically, I now 
> don't need to define a separate interface signature to specifically expect 
> type T!

I think that there is some confusion here: it is true that IUO exists 
internally as a type within the compiler, but the idea of our current 
implementation is that that is just an implementation detail within the 
compiler (similar to LValueType, which has no user syntax), not an exposed part 
of the programmer model.

That said, the “T!” *syntax* is intended to stay in Swift.  This is the way to 
model the IUO declaration modifier, as outlined in the proposal.

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Chris Lattner via swift-evolution]

> On Jun 21, 2016, at 3:51 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Jun 21, 2016, at 15:26, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Tue, Jun 21, 2016 at 5:10 PM, Daniel Resnick via swift-evolution 
>> > wrote:
>> I also disagree for the same reasons that Gwynne and Brent mentioned: I find 
>> '\(...)' easy to read, fine to type, and consistent with other string 
>> escaping syntax.
>> 
>> Those are persuasive arguments. Consistency with other string escaping 
>> syntax is a huge plus. Moreover, now that I think about it, \r or \n isn't 
>> really a bother to type. The \( combination takes a little getting used to, 
>> but it's not absurdly terrible. I suppose we could consider \{} or even \[] 
>> instead of \() to alleviate the reach.
> 
> Gwynne and Brent indeed hit on the logic for the original design: backslash 
> is already an escape character in strings. The parentheses () over another 
> kind of delimiter were originally to match calls (string interpolation once 
> generated direct calls to String initializers), but even without that it’s 
> still something that’s used with expressions, while curly braces {} are used 
> for general code blocks and square brackets [] are used with collections.
> 
> I’m strongly in favor of keeping things the way they are, both because I like 
> it a fair bit and because it’d be another source-breaking change that would 
> be very hard to migrate.

I completely agree with Jordan.

This is a classical bikeshed, and any new design would have to be extremely 
compelling, because it would have to overcome the advantage of the \() 
approach: that it is compatible with the use of \ as the escape character for 
other things.  It would be really unfortunate to have to start escaping $ or 
whatever other character you would pick.

-Chris

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 21, 2016, at 5:51 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Jun 21, 2016, at 15:26, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>>> On Tue, Jun 21, 2016 at 5:10 PM, Daniel Resnick via swift-evolution 
>>>  wrote:
>>> I also disagree for the same reasons that Gwynne and Brent mentioned: I 
>>> find '\(...)' easy to read, fine to type, and consistent with other string 
>>> escaping syntax.
>> 
>> Those are persuasive arguments. Consistency with other string escaping 
>> syntax is a huge plus. Moreover, now that I think about it, \r or \n isn't 
>> really a bother to type. The \( combination takes a little getting used to, 
>> but it's not absurdly terrible. I suppose we could consider \{} or even \[] 
>> instead of \() to alleviate the reach.
> 
> Gwynne and Brent indeed hit on the logic for the original design: backslash 
> is already an escape character in strings. The parentheses () over another 
> kind of delimiter were originally to match calls (string interpolation once 
> generated direct calls to String initializers), but even without that it’s 
> still something that’s used with expressions, while curly braces {} are used 
> for general code blocks and square brackets [] are used with collections.
> 
> I’m strongly in favor of keeping things the way they are, both because I like 
> it a fair bit and because it’d be another source-breaking change that would 
> be very hard to migrate.

+1.  I really liked this when I Swift was first released.  Using the existing 
escape character makes perfect sense.  We've made enough breaking changes for 
what are arguably aesthetic preferences.  The bar should be higher going 
forward and I really don't think this makes the cut.

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[David Sweeris via swift-evolution]

> On Jun 21, 2016, at 17:26, Xiaodi Wu via swift-evolution 
>  wrote:
> 

> The \( combination takes a little getting used to, but it's not absurdly 
> terrible. I suppose we could consider \{} or even \[] instead of \() to 
> alleviate the reach.

\{} is kinda nice because it mirrors the closure syntax.

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

Re: [swift-evolution] [swigt-evolution] [Pitch] Make NSOrderedSet behave like any other collections from Foundation

[Brent Royal-Gordon via swift-evolution]

> We’re thinking about it but there are no plans for Swift 3 in this respect 

I didn't mean to imply otherwise. What I was trying to say is that it's on your 
team's radar and trying to propose it probably won't be especially helpful. 

-- 
Brent Royal-Gordon
Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Shawn Erickson via swift-evolution]

Curious on the possibility of something like the following to denote a no
return function?

func foo() -> !

...or mostly joking...

func foo() -> (for thing like fatalError)
func foo() -> (for things like dispatch main)

Anyway I am generally -0.5 on this change without understanding if this
could be a bottom type and how that could work in the bigger picture.


-Shawn

On Tue, Jun 21, 2016 at 10:04 AM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0102: Remove @noreturn attribute and introduce an empty
> NoReturn type" begins now and runs through June 27. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 6:06 PM, Dave Abrahams  wrote:
>> 
>> It's just that I don't think this part of the library API is important
>> enough, to enough people, that this readability is worth the additional
>> exposed surface area (and further exposure later on—I can easily imagine
>> a “minimumAlignment”).  I would *much* rather keep this stuff corralled
>> in a single namespace where it can all be found.
>
> See? That, I totally get.
>
>> I think you represented it just fine, thanks... I just don't think
>> you're accounting for the big picture.  These APIs are not like “map,”
>> “filter,” and “Dictionary.”  They're specialty items that you should
>> only reach for when performing unsafe operations, mostly inside the guts
>> of higher-level constructs.
>> 
>> -- 
>> Dave
>
> Would you like me to edit it and flip the proposal then? Put the
> MemoryLayout in as primary, mine as secondary, and add in text to
> explain that the motivation is less usability than serving an unsafe
> API with minimal surface area?

Well, the review has already started, so I don't think we ought to go
inverting the proposal now.  Let's see how the discussion plays out.  If
at the end, you agree with my point-of-view, you can say so and the
review manager and core team will take that into account.

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

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 6:06 PM, Dave Abrahams  wrote:
> 
> It's just that I don't think this part of the library API is important
> enough, to enough people, that this readability is worth the additional
> exposed surface area (and further exposure later on—I can easily imagine
> a “minimumAlignment”).  I would *much* rather keep this stuff corralled
> in a single namespace where it can all be found.

See? That, I totally get.

> I think you represented it just fine, thanks... I just don't think
> you're accounting for the big picture.  These APIs are not like “map,”
> “filter,” and “Dictionary.”  They're specialty items that you should
> only reach for when performing unsafe operations, mostly inside the guts
> of higher-level constructs.
> 
> -- 
> Dave

Would you like me to edit it and flip the proposal then? Put the MemoryLayout 
in as primary,
mine as secondary, and add in text to explain that the motivation is less 
usability than serving
an unsafe API with minimal surface area?

-- E

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

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

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

Generally in support, with two small exceptions:

1. I think the type variants should have the parameter label `of`. 
`memorySize(of: Int.self)` reads grammatically (other than the hopefully 
soon-to-be-vestigial `self`); `memorySize(Int.self)` does not.

2. I am not convinced that the `ofValue` variants are valuable enough to keep, 
although they do help support the (I think necessary, though I could probably 
be convinced otherwise now that these three all have a `memory` prefix) change 
to `type(ofValue:)`.

(Actually, I'm now considering the idea that these should be `valueSize(of: 
T.Type)`, etc., since they measure only the size of the immediate value, not 
any objects that value might reference. But that thought is underdeveloped, so 
I'm not ready to stand behind it.)

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

Yes; these are inconsistent with the API guidelines.

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

Yes.

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

I like that it's a little clearer what sort of "size" is meant; people are 
unlikely to imagine this will tell them an array's length, for instance.

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

Quick reading.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Xiaodi Wu via swift-evolution]

On Tue, Jun 21, 2016 at 7:10 PM, Kenny Wyland  wrote:

> On Tue, Jun 21, 2016 at 5:07 PM, Xiaodi Wu  wrote:
>
>> (Whoops, reply to list; also adding a reply.)
>>
>> On Tue, Jun 21, 2016 at 6:55 PM, Kenny Wyland  wrote:
>>
>>> On Tue, Jun 21, 2016 at 4:40 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 On Tue, Jun 21, 2016 at 6:25 PM, Brandon Knope  wrote:

> How can it be unpersuasive? I can *show* you that keys that are easier
> to type/reach exist for a large majority of user’s.
>

 As I pointed out, your results are flawed because there are two keys
 frequently reached for in the vicinity of \ which are excluded from your
 analysis. Those keys are delete/backspace and return/enter.

>>>
>>> True, however, both of those keys (delete/backspace and return/enter)
>>> are over-sized for the specific reasons that they are difficult to hit in
>>> that position and we use them a lot so we compensate by making them larger.
>>>
>>
>> If you google some pictures of typewriter keyboards, you'll see that the
>> backspace key was once the same size as all other keys (whereas the shift
>> keys and space bar were not). Moreover, if you check out international
>> keyboards, you'll find that several of these keys vary in size based on
>> country, so clearly their specific size is not considered to be very
>> important (even though (I presume) people delete things and advance lines
>> at similar frequencies regardless of language). So I don't really buy the
>> idea that these keys are sized "for the specific reason that they are
>> difficult to hit."
>>
>
> International support and ease of use is certainly important, but I'm not
> sure how old typewriter keyboards are any sort of valid data point in the
> discussion.
>

Well, given that hand sizes haven't really changed, it's an entirely valid
data point with respect to your assertion that certain parts of the
keyboard are difficult to hit. In fact, I'd argue it's probably one of the
better data points. Our keyboard layouts today are constrained in part by
habit and tradition, and what's more, we're more numb now to how learnable
typing really is because the skill is now so commonplace. But given a blank
slate, and with ample concern about the learning curve, our forbears could
make the keys almost any size they wished--and they chose a small backspace
key.


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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Brandon Knope  wrote:

> Maybe this is flawed, but I think it is hard to argue that the \ is
> easy to type when there are far more usable alternatives.

While I agree with you, readability is *so* much more important than
typeability that I think this line of argument doesn't count for much.

-- 
Dave

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Brandon Knope via swift-evolution]

Sent from my iPad

> On Jun 21, 2016, at 8:07 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> (Whoops, reply to list; also adding a reply.)
> 
> On Tue, Jun 21, 2016 at 6:55 PM, Kenny Wyland  wrote:
>>> On Tue, Jun 21, 2016 at 4:40 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
 On Tue, Jun 21, 2016 at 6:25 PM, Brandon Knope  wrote:
>>> 
 How can it be unpersuasive? I can *show* you that keys that are easier to 
 type/reach exist for a large majority of user’s.
>>> 
>>> As I pointed out, your results are flawed because there are two keys 
>>> frequently reached for in the vicinity of \ which are excluded from your 
>>> analysis. Those keys are delete/backspace and return/enter.
>> 
>> True, however, both of those keys (delete/backspace and return/enter) are 
>> over-sized for the specific reasons that they are difficult to hit in that 
>> position and we use them a lot so we compensate by making them larger. 
> 
> If you google some pictures of typewriter keyboards, you'll see that the 
> backspace key was once the same size as all other keys (whereas the shift 
> keys and space bar were not). Moreover, if you check out international 
> keyboards, you'll find that several of these keys vary in size based on 
> country, so clearly their specific size is not considered to be very important

Are you surprised that usability isn't taken into consideration for a lot of 
products?

Brandon

> (even though (I presume) people delete things and advance lines at similar 
> frequencies regardless of language). So I don't really buy the idea that 
> these keys are sized "for the specific reason that they are difficult to hit."
>  
 I am not saying it is a good idea or not to replace \, but to pretend that 
 there isn’t an inconvenience there is unfair when every other part of the 
 language is put under a magnifying glass for the sake of grammar, newbie 
 friendliness, or this or that, etc...
 
>>> 
>>> We've discussed why it's sensible grammar; there is no argument to be made 
>>> here about whether pressing one labeled key or another is friendlier to a 
>>> beginner.
>> 
>> The idea that \ is already a special character inside strings isn't a valid 
>> argument for it being the -best- choice, it's simply an argument for it 
>> being the -easiest to code for- in the compiler. Backslashes in strings are 
>> used for special characters like \n, but I don't know of any language, other 
>> than Swift, that uses them for variable interpolation.
>> 
>> So, if we're also talking about being friendlier to a beginner, I think that 
>> using blackslash is a disservice to them because it teaches them a pattern 
>> that isn't used by any other language for intra-string variable 
>> interpolation.
> 
> Gwynne's argument here was persuasive to me, which is that each major 
> C-family language takes a different approach to interpolation. There is no 
> symbol which can be said to be widely used. Which is not to say that there 
> aren't poor choices and better ones.
>  
>> 
>> Kenny Wyland
>>  
>>>  
 This is measurable…it just depends on whether it bothers people or not 
 enough. Most other things are based on opinion, but this *can* be based on 
 numbers and usability.
>>> 
>>> See above; you measured wrong...
>>>  
 This is something used by everyone. The usability cost is there and it is 
 real. Just because “well it is easy for me to type” does not mean that it 
 is ideal. It also doesn’t mean that the current choice is the wrong choice 
 either. But it still is important to discuss while we can.
 
 And yes a keyboard IS only so big, but the range to that bigness can be 
 pretty… big.
 
 Also, $ is not the only option. There are still far easier keys to type 
 than \.
 Brandon
 
> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu  wrote:
> 
>> On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution 
>>  wrote:
>> Actually… we can go pretty scientific on this sort of thing and heat map 
>> keyboard usage to get a better picture of how “usable” this is.
>> 
>> I pasted a file that contains seven \’s in it and heat mapped it at 
>> https://www.patrick-wied.at/projects/heatmap-keyboard/
>> 
>> Even *with* several \’s throughout my source file the majority of my key 
>> presses take place much closer to the $ key than the \ key.
>> 
>> I think we can all argue about what is clearer or not, but I think for 
>> the majority of us, the \ key is quite inconvenient compared to the keys 
>> around where we type the most.
>> 
>> I also ran several of iOS 10’s sample code through the heat map and 
>> continue to get pretty similar results: the \ is much further from the 
>> hottest part of the keyboard than the ones closer to where 

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Xiaodi Wu via swift-evolution]

(Whoops, reply to list; also adding a reply.)

On Tue, Jun 21, 2016 at 6:55 PM, Kenny Wyland  wrote:

> On Tue, Jun 21, 2016 at 4:40 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Tue, Jun 21, 2016 at 6:25 PM, Brandon Knope  wrote:
>>
>>> How can it be unpersuasive? I can *show* you that keys that are easier
>>> to type/reach exist for a large majority of user’s.
>>>
>>
>> As I pointed out, your results are flawed because there are two keys
>> frequently reached for in the vicinity of \ which are excluded from your
>> analysis. Those keys are delete/backspace and return/enter.
>>
>
> True, however, both of those keys (delete/backspace and return/enter) are
> over-sized for the specific reasons that they are difficult to hit in that
> position and we use them a lot so we compensate by making them larger.
>

If you google some pictures of typewriter keyboards, you'll see that the
backspace key was once the same size as all other keys (whereas the shift
keys and space bar were not). Moreover, if you check out international
keyboards, you'll find that several of these keys vary in size based on
country, so clearly their specific size is not considered to be very
important (even though (I presume) people delete things and advance lines
at similar frequencies regardless of language). So I don't really buy the
idea that these keys are sized "for the specific reason that they are
difficult to hit."


> I am not saying it is a good idea or not to replace \, but to pretend that
>>> there isn’t an inconvenience there is unfair when every other part of the
>>> language is put under a magnifying glass for the sake of grammar, newbie
>>> friendliness, or this or that, etc...
>>>
>>>
>> We've discussed why it's sensible grammar; there is no argument to be
>> made here about whether pressing one labeled key or another is friendlier
>> to a beginner.
>>
>
> The idea that \ is already a special character inside strings isn't a
> valid argument for it being the -best- choice, it's simply an argument for
> it being the -easiest to code for- in the compiler. Backslashes in strings
> are used for special characters like \n, but I don't know of any language,
> other than Swift, that uses them for variable interpolation.
>
> So, if we're also talking about being friendlier to a beginner, I think
> that using blackslash is a disservice to them because it teaches them a
> pattern that isn't used by any other language for intra-string variable
> interpolation.
>

Gwynne's argument here was persuasive to me, which is that each major
C-family language takes a different approach to interpolation. There is no
symbol which can be said to be widely used. Which is not to say that there
aren't poor choices and better ones.


>
> Kenny Wyland
>
>
>>
>>
>>> This is *measurable*…it just depends on whether it bothers people or
>>> not enough. Most other things are based on opinion, but this *can* be based
>>> on numbers and usability.
>>>
>>
>> See above; you measured wrong...
>>
>>
>>> This is *something used by everyone*. The usability cost is there and
>>> it is real. Just because “well it is easy for me to type” does not mean
>>> that it is ideal. It also doesn’t mean that the current choice is the wrong
>>> choice either. But it still is important to discuss while we can.
>>>
>>> And yes a keyboard IS only so big, but the range to that bigness can be
>>> pretty… big.
>>>
>>> Also, $ is not the only option. There are still far easier keys to type
>>> than \.
>>> Brandon
>>>
>>> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu  wrote:
>>>
>>> On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Actually… we can go pretty scientific on this sort of thing and heat
 map keyboard usage to get a better picture of how “usable” this is.

 I pasted a file that contains seven \’s in it and heat mapped it at
 https://www.patrick-wied.at/projects/heatmap-keyboard/

 Even *with* several \’s throughout my source file the majority of my
 key presses take place much closer to the $ key than the \ key.

 I think we can all argue about what is clearer or not, but I think for
 the majority of us, the \ key is quite inconvenient compared to the keys
 around where we type the most.

 I also ran several of iOS 10’s sample code through the heat map and
 continue to get pretty similar results: the \ is much further from the
 hottest part of the keyboard than the ones closer to where your hand
 usually rests.

 Maybe this is flawed, but I think it is hard to argue that the \ is
 easy to type when there are far more usable alternatives.

>>>
>>> I'm rather unpersuaded by this line of argument. The keyboard is only so
>>> big; it's a stretch to say that any key is less than absolutely usable.
>>> Moreover, \ is next the delete key, which I presume 

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 3:02 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> If I didn't think it would produce semantic confusion, these would be
>> static members e.g. `Array.memoryAlignment`, and you'd have to “scan
>> past” `Array`.  It's a perfectly natural way to express a property of a
>> type.
>
> I think
>
> Array.memoryAlignment 
>
> is quite different to scan than
>
> MemoryLayout(Array).alignment
>
> (And I obviously like the former a lot more if it wouldn't produce
> semantic confusion -- I assume you mean in the compiler and not
> the reader of the code). 

No, I mean to the reader of the code.  The former might easily be
interpreted as the memory alignment of the elements in the array, for
example.  And the effect is much worse with the counterpart to sizeof.

> That said, I think
>
> memoryAlignment(Array.self)
>
> reads better than
>
> MemoryLayout(Array).alignment
>
> You don't have to brainparse(TM by Cognition Inc) two other things 
> before arriving at alignment.  The MemoryLayout feels more prominent
> than it should. The alignment feels less prominent than it should.
>
> I recognize we disagree on this, 

We don't, actually.  I agree that by themselves the APIs you are
proposing look better.

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”).  I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

So, my argument is really about the overall shape of the standard
library and its effect on ordinary users more than the look/feel of
these particular APIs.

> and we're unlikely to convince each other on-list, which is why I
> tried hard to make sure that your alternative was properly presented
> in the proposal. If I have made any errors in expressing your design,
> its intent, and rationale, please let me know and I will edit the
> proposal to fix.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture.  These APIs are not like “map,”
“filter,” and “Dictionary.”  They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Sean Heber via swift-evolution]

The situation is very different on an iPad. I don't think this argument is a 
good enough reason either. It will differ based on locale, accessibility 
technology, device, personal key shortcuts, etc. 

l8r
Sean 

Sent from my iPhone

> On Jun 21, 2016, at 6:52 PM, Brandon Knope via swift-evolution 
>  wrote:
> 
> You're going to be holding shift for the parens anyways so it might be easier 
> to type instead of not pressing and then pressing shift
> 
> Brandon 
> 
> Sent from my iPad
> 
>> On Jun 21, 2016, at 7:47 PM, Andrey Fidrya  wrote:
>> 
>> I think that introducing another escape character is not a good idea.
>> \() is consistent with \r \n etc.
>> 
>> And I'm not sure if $ is easier to type. '\' is a single keypress and is 
>> located
>> near Backspace & Enter.
>> 
>> $ is SHIFT+4 and is harder to type without looking at the keyboard.
>> 
>> Andrey
>> 
>> 
>>> On 22 Jun 2016, at 02:25, Brandon Knope via swift-evolution 
>>>  wrote:
>>> 
>>> How can it be unpersuasive? I can *show* you that keys that are easier to 
>>> type/reach exist for a large majority of user’s.
>>> 
>>> I am not saying it is a good idea or not to replace \, but to pretend that 
>>> there isn’t an inconvenience there is unfair when every other part of the 
>>> language is put under a magnifying glass for the sake of grammar, newbie 
>>> friendliness, or this or that, etc...
>>> 
>>> This is measurable…it just depends on whether it bothers people or not 
>>> enough. Most other things are based on opinion, but this *can* be based on 
>>> numbers and usability.
>>> This is something used by everyone. The usability cost is there and it is 
>>> real. Just because “well it is easy for me to type” does not mean that it 
>>> is ideal. It also doesn’t mean that the current choice is the wrong choice 
>>> either. But it still is important to discuss while we can.
>>> 
>>> And yes a keyboard IS only so big, but the range to that bigness can be 
>>> pretty… big.
>>> 
>>> Also, $ is not the only option. There are still far easier keys to type 
>>> than \.
>>> 
>>> Brandon
>>> 
 On Jun 21, 2016, at 7:15 PM, Xiaodi Wu  wrote:
 
> On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution 
>  wrote:
> Actually… we can go pretty scientific on this sort of thing and heat map 
> keyboard usage to get a better picture of how “usable” this is.
> 
> I pasted a file that contains seven \’s in it and heat mapped it at 
> https://www.patrick-wied.at/projects/heatmap-keyboard/
> 
> Even *with* several \’s throughout my source file the majority of my key 
> presses take place much closer to the $ key than the \ key.
> 
> I think we can all argue about what is clearer or not, but I think for 
> the majority of us, the \ key is quite inconvenient compared to the keys 
> around where we type the most.
> 
> I also ran several of iOS 10’s sample code through the heat map and 
> continue to get pretty similar results: the \ is much further from the 
> hottest part of the keyboard than the ones closer to where your hand 
> usually rests.
> 
> Maybe this is flawed, but I think it is hard to argue that the \ is easy 
> to type when there are far more usable alternatives.
 
 I'm rather unpersuaded by this line of argument. The keyboard is only so 
 big; it's a stretch to say that any key is less than absolutely usable. 
 Moreover, \ is next the delete key, which I presume you use frequently and 
 find no difficulty in reaching.
 
 You know what *is* unusable though? Try finding the $ key on an 
 international keyboard.
  
> Brandon
> 
> 
> 
>> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution 
>>  wrote:
>> 
>> I also disagree for the same reasons that Gwynne and Brent mentioned: I 
>> find '\(...)' easy to read, fine to type, and consistent with other 
>> string escaping syntax.
>> 
>>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> > I find that typing \(var) is very disruptive to my typing flow. The 
>>> > more I code in Swift, the more I like it, but every time I'm coding 
>>> > and then have to hiccup while typing \ then ( causes me to be 
>>> > annoyed. I know, it's minor, but it isn't a key combination that 
>>> > flows quickly.
>>> >
>>> > I would much rather have $() or perhaps ${} (like Groovy lang) or 
>>> > perhaps @() to go along with other uses of @ throughout the language.
>>> 
>>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I 
>>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third 
>>> character (besides \ and ") to mean something special in a 

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

[Xiaodi Wu via swift-evolution]

On Tue, Jun 21, 2016 at 6:44 PM, Darren Mo  wrote:

> On Jun 20, 2016, at 10:12 PM, Xiaodi Wu  wrote:
>
> On Mon, Jun 20, 2016 at 9:05 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
>> > --
>> > The lack of verb in the base name bothers me. The API Design Guidelines
>> say “methods with side-effects should read as imperative verb phrases”. You
>> could argue that the argument label “execute” serves as the verb. However,
>> .async and .sync are most commonly used with trailing closures where the
>> argument label is not present.
>> >
>> > This issue was brought up during the review, but I did not see it being
>> addressed. Why not name the methods something like .executeAsync(_:) and
>> .executeSync(_:)?
>>
>> That feels a little redundant to me. It's worth remembering that the API
>> Guidelines are a means of creating clear APIs, not an end in themselves.
>> It's okay to deviate a little if you get a better result.
>>
>
> The guideline that methods should "read as imperative verb phrases"
> applies to the full name, labels and arguments and all, and not just the
> base name. You'll recall that the original proposal had
> .asynchronously(execute:), which is very much an imperative phrase.
> `.async(execute:)` was substituted by popular demand, with "async" being
> regarded as a term-of-art exception.
>
>
> Can you link me something that says it applies to the full name?
>

In the document, all examples for verb phrases and noun phrases include the
labels and arguments (e.g.: "distance to y"). In the subsequent section, it
outlines scenarios for labeling the first argument when it forms part of a
prepositional phrase or other grammatical phrase; in either case, the label
is read as part of the phrase. The only exception to this convention is
explicitly outlined: "Initializer and factory method calls should form a
phrase that does not include the first argument."


> In all the examples, the verb is always in the base name and the argument
> labels are always prepositions or objects (the grammar version).
>

Yes; these names are exceptional in that way. But it is apt: the base name
holds the distinguishing feature (async vs. sync), whereas the verb here is
correctly a label for the argument, which is a code block to be executed.


> And what about when a trailing closure is used? Then the verb disappears.
>

Which is fine, because the verb couldn't really be anything else
(`doNotExecute`?). To me, at least, braces surrounding code blocks
satisfactorily imply 'do' or 'execute,' much like parentheses around
arguments are sometimes taken to imply 'with' or 'using.'
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Brent Royal-Gordon via swift-evolution]

> * [LibraryEvolution.rst] @noreturn is a versioned attribute, so how will this 
> proposal affect that design?

If library evolution permitted you to change a return type into one of its 
subtypes (for instance, to change an NSObject return into an NSResponder 
return), and if Never were a subtype-of-all-types bottom type, then you would 
always be able to change any return type to Never. There may be ABI reasons 
that this couldn't be supported—for instance, a Boolean existential has a 
different representation than a concrete Bool struct—but I believe it would be 
semantically sound.

(Of course, if you had to write `Any` instead of `Boolean`, the fact 
that you couldn't replace it with `Bool` would be a little more straightforward 
to understand...)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Brandon Knope via swift-evolution]

You're going to be holding shift for the parens anyways so it might be easier 
to type instead of not pressing and then pressing shift

Brandon 

Sent from my iPad

> On Jun 21, 2016, at 7:47 PM, Andrey Fidrya  wrote:
> 
> I think that introducing another escape character is not a good idea.
> \() is consistent with \r \n etc.
> 
> And I'm not sure if $ is easier to type. '\' is a single keypress and is 
> located
> near Backspace & Enter.
> 
> $ is SHIFT+4 and is harder to type without looking at the keyboard.
> 
> Andrey
> 
> 
>> On 22 Jun 2016, at 02:25, Brandon Knope via swift-evolution 
>>  wrote:
>> 
>> How can it be unpersuasive? I can *show* you that keys that are easier to 
>> type/reach exist for a large majority of user’s.
>> 
>> I am not saying it is a good idea or not to replace \, but to pretend that 
>> there isn’t an inconvenience there is unfair when every other part of the 
>> language is put under a magnifying glass for the sake of grammar, newbie 
>> friendliness, or this or that, etc...
>> 
>> This is measurable…it just depends on whether it bothers people or not 
>> enough. Most other things are based on opinion, but this *can* be based on 
>> numbers and usability.
>> This is something used by everyone. The usability cost is there and it is 
>> real. Just because “well it is easy for me to type” does not mean that it is 
>> ideal. It also doesn’t mean that the current choice is the wrong choice 
>> either. But it still is important to discuss while we can.
>> 
>> And yes a keyboard IS only so big, but the range to that bigness can be 
>> pretty… big.
>> 
>> Also, $ is not the only option. There are still far easier keys to type than 
>> \.
>> 
>> Brandon
>> 
>>> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu  wrote:
>>> 
 On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution 
  wrote:
 Actually… we can go pretty scientific on this sort of thing and heat map 
 keyboard usage to get a better picture of how “usable” this is.
 
 I pasted a file that contains seven \’s in it and heat mapped it at 
 https://www.patrick-wied.at/projects/heatmap-keyboard/
 
 Even *with* several \’s throughout my source file the majority of my key 
 presses take place much closer to the $ key than the \ key.
 
 I think we can all argue about what is clearer or not, but I think for the 
 majority of us, the \ key is quite inconvenient compared to the keys 
 around where we type the most.
 
 I also ran several of iOS 10’s sample code through the heat map and 
 continue to get pretty similar results: the \ is much further from the 
 hottest part of the keyboard than the ones closer to where your hand 
 usually rests.
 
 Maybe this is flawed, but I think it is hard to argue that the \ is easy 
 to type when there are far more usable alternatives.
>>> 
>>> I'm rather unpersuaded by this line of argument. The keyboard is only so 
>>> big; it's a stretch to say that any key is less than absolutely usable. 
>>> Moreover, \ is next the delete key, which I presume you use frequently and 
>>> find no difficulty in reaching.
>>> 
>>> You know what *is* unusable though? Try finding the $ key on an 
>>> international keyboard.
>>>  
 Brandon
 
 
 
> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution 
>  wrote:
> 
> I also disagree for the same reasons that Gwynne and Brent mentioned: I 
> find '\(...)' easy to read, fine to type, and consistent with other 
> string escaping syntax.
> 
>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> > I find that typing \(var) is very disruptive to my typing flow. The 
>> > more I code in Swift, the more I like it, but every time I'm coding 
>> > and then have to hiccup while typing \ then ( causes me to be annoyed. 
>> > I know, it's minor, but it isn't a key combination that flows quickly.
>> >
>> > I would much rather have $() or perhaps ${} (like Groovy lang) or 
>> > perhaps @() to go along with other uses of @ throughout the language.
>> 
>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I 
>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third 
>> character (besides \ and ") to mean something special in a string 
>> literal, it reuses one of the existing ones. There's no need to escape a 
>> character you wouldn't otherwise have to touch, or to think of another 
>> character as "magical" in a string. It fits nicely with the rest of the 
>> syntax, with `\` indicating a special construct and then `()` delimiting 
>> an expression, just as they do elsewhere in the language. It's an 
>> elegant solution to a problem traditionally solved 

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Andrey Fidrya via swift-evolution]

I think that introducing another escape character is not a good idea.
\() is consistent with \r \n etc.

And I'm not sure if $ is easier to type. '\' is a single keypress and is located
near Backspace & Enter.

$ is SHIFT+4 and is harder to type without looking at the keyboard.

Andrey


> On 22 Jun 2016, at 02:25, Brandon Knope via swift-evolution 
>  wrote:
> 
> How can it be unpersuasive? I can *show* you that keys that are easier to 
> type/reach exist for a large majority of user’s.
> 
> I am not saying it is a good idea or not to replace \, but to pretend that 
> there isn’t an inconvenience there is unfair when every other part of the 
> language is put under a magnifying glass for the sake of grammar, newbie 
> friendliness, or this or that, etc...
> 
> This is measurable…it just depends on whether it bothers people or not 
> enough. Most other things are based on opinion, but this *can* be based on 
> numbers and usability.
> This is something used by everyone. The usability cost is there and it is 
> real. Just because “well it is easy for me to type” does not mean that it is 
> ideal. It also doesn’t mean that the current choice is the wrong choice 
> either. But it still is important to discuss while we can.
> 
> And yes a keyboard IS only so big, but the range to that bigness can be 
> pretty… big.
> 
> Also, $ is not the only option. There are still far easier keys to type than 
> \.
> 
> Brandon
> 
>> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution 
>> > wrote:
>> Actually… we can go pretty scientific on this sort of thing and heat map 
>> keyboard usage to get a better picture of how “usable” this is.
>> 
>> I pasted a file that contains seven \’s in it and heat mapped it at 
>> https://www.patrick-wied.at/projects/heatmap-keyboard/ 
>> 
>> 
>> Even *with* several \’s throughout my source file the majority of my key 
>> presses take place much closer to the $ key than the \ key.
>> 
>> I think we can all argue about what is clearer or not, but I think for the 
>> majority of us, the \ key is quite inconvenient compared to the keys around 
>> where we type the most.
>> 
>> I also ran several of iOS 10’s sample code through the heat map and continue 
>> to get pretty similar results: the \ is much further from the hottest part 
>> of the keyboard than the ones closer to where your hand usually rests.
>> 
>> Maybe this is flawed, but I think it is hard to argue that the \ is easy to 
>> type when there are far more usable alternatives.
>> 
>> I'm rather unpersuaded by this line of argument. The keyboard is only so 
>> big; it's a stretch to say that any key is less than absolutely usable. 
>> Moreover, \ is next the delete key, which I presume you use frequently and 
>> find no difficulty in reaching.
>> 
>> You know what *is* unusable though? Try finding the $ key on an 
>> international keyboard.
>>  
>> Brandon
>> 
>> 
>> 
>>> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution 
>>> > wrote:
>>> 
>>> I also disagree for the same reasons that Gwynne and Brent mentioned: I 
>>> find '\(...)' easy to read, fine to type, and consistent with other string 
>>> escaping syntax.
>>> 
>>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> > I find that typing \(var) is very disruptive to my typing flow. The more 
>>> > I code in Swift, the more I like it, but every time I'm coding and then 
>>> > have to hiccup while typing \ then ( causes me to be annoyed. I know, 
>>> > it's minor, but it isn't a key combination that flows quickly.
>>> >
>>> > I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps 
>>> > @() to go along with other uses of @ throughout the language.
>>> 
>>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I 
>>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third 
>>> character (besides \ and ") to mean something special in a string literal, 
>>> it reuses one of the existing ones. There's no need to escape a character 
>>> you wouldn't otherwise have to touch, or to think of another character as 
>>> "magical" in a string. It fits nicely with the rest of the syntax, with `\` 
>>> indicating a special construct and then `()` delimiting an expression, just 
>>> as they do elsewhere in the language. It's an elegant solution to a problem 
>>> traditionally solved inelegantly. It's very Swifty in that way.
>>> 
>>> > A shifted key, like $ or @, followed by another shifted key like (, 
>>> > allows for a much faster flow and they are much closer to the home keys 
>>> > than \ which is nearly as 

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

[Darren Mo via swift-evolution]

On Jun 21, 2016, at 5:24 PM, Matt Wright  wrote:
>> On Jun 20, 2016, at 7:12 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> On Mon, Jun 20, 2016 at 9:05 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>>> DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
>>> --
>>> The lack of verb in the base name bothers me. The API Design Guidelines say 
>>> “methods with side-effects should read as imperative verb phrases”. You 
>>> could argue that the argument label “execute” serves as the verb. However, 
>>> .async and .sync are most commonly used with trailing closures where the 
>>> argument label is not present.
>>> 
>>> This issue was brought up during the review, but I did not see it being 
>>> addressed. Why not name the methods something like .executeAsync(_:) and 
>>> .executeSync(_:)?
>> 
>> That feels a little redundant to me. It's worth remembering that the API 
>> Guidelines are a means of creating clear APIs, not an end in themselves. 
>> It's okay to deviate a little if you get a better result.
>> 
>> The guideline that methods should "read as imperative verb phrases" applies 
>> to the full name, labels and arguments and all, and not just the base name. 
>> You'll recall that the original proposal had .asynchronously(execute:), 
>> which is very much an imperative phrase. `.async(execute:)` was substituted 
>> by popular demand, with "async" being regarded as a term-of-art exception.
> 
> Right, the naming here strayed from the guidelines here under the term-of-art 
> exception. None of the various alternatives really fit amazingly well, the 
> async{,hronous} part of the API name communicates an important facet of what 
> the call does. In that it goes away and executes the closure “somewhere 
> else”. I feel this particular point is lost in example such as 
> perform{andWait}. `.asynchronously` was an attempt to move towards the 
> guidelines but it still missed that mark. I believe it’s still clearer to 
> have `.async` as an exception.

What do you think of the names .executeAsync/.executeSync or 
.asyncExecute/.syncExecute?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Brandon Knope via swift-evolution]

Unfortunately I know nothing about international keyboards.

But surely someone could heat map their international keyboards?

I don't want to take this to ridiculous levels, but I hope I am making somewhat 
of a point here. Maybe not =/

Brandon

Sent from my iPad

On Jun 21, 2016, at 7:38 PM, Erica Sadun  wrote:

>>> You know what *is* unusable though? Try finding the $ key on an 
>>> international keyboard.
> 
> And that, for me, is motivation in a nutshell. Swift won't always be used on 
> OS X, where it's easy to set up Keyboard prefs to substitute (dollar) with $. 
> 
> I did a search for "which symbol keys appear on most international keyboards" 
> but didn't get very far. Surely this is something to bring into the 
> discussion if it exists?
> 
> -- E
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Darren Mo via swift-evolution]

On Jun 20, 2016, at 10:12 PM, Xiaodi Wu  wrote:
> On Mon, Jun 20, 2016 at 9:05 PM, Brent Royal-Gordon via swift-evolution 
> > wrote:
> > DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
> > --
> > The lack of verb in the base name bothers me. The API Design Guidelines say 
> > “methods with side-effects should read as imperative verb phrases”. You 
> > could argue that the argument label “execute” serves as the verb. However, 
> > .async and .sync are most commonly used with trailing closures where the 
> > argument label is not present.
> >
> > This issue was brought up during the review, but I did not see it being 
> > addressed. Why not name the methods something like .executeAsync(_:) and 
> > .executeSync(_:)?
> 
> That feels a little redundant to me. It's worth remembering that the API 
> Guidelines are a means of creating clear APIs, not an end in themselves. It's 
> okay to deviate a little if you get a better result.
> 
> The guideline that methods should "read as imperative verb phrases" applies 
> to the full name, labels and arguments and all, and not just the base name. 
> You'll recall that the original proposal had .asynchronously(execute:), which 
> is very much an imperative phrase. `.async(execute:)` was substituted by 
> popular demand, with "async" being regarded as a term-of-art exception.

Can you link me something that says it applies to the full name? In all the 
examples, the verb is always in the base name and the argument labels are 
always prepositions or objects (the grammar version).

And what about when a trailing closure is used? Then the verb disappears.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

I like the idea, but not the name. I would prefer a more general name like 
`Never`.

If `NoReturn` becomes a universal bottom type, it's going to need a more 
universal name than `NoReturn` It's very narrow and specialized, so it's not 
appropriate for bottom types in other contexts; just think of the `NoReturn?` 
variable created by optional chaining, or the `[NoReturn]` array created by 
`map`. As soon as you take even the tiniest step away from a return value, the 
name doesn't really make sense anymore.

Therefore, I strongly suspect we'll have to change this name again in the 
future as `NoReturn` becomes a more powerful bottom type. I'm not really 
looking forward to changing `@noreturn` to `-> NoReturn` in Swift 3 and then 
changing it again to `-> Never` in Swift 4, so I think we should just do it 
here and now.

I also don't like the way `NoReturn` reads. It *is* understandable, but it 
bluntly disobeys type naming conventions by describing not the value being 
returned, but the member returning it. There are many sensible names we might 
have given `Void` if not for C—`Nothing`, `None`, `Empty`—but I don't think 
anybody would advocate for `EmptyReturn`. It just isn't an appropriate type 
name.

An attribute is an adjective describing a member, and `@noreturn` (or rather, 
`@nonreturning`) is a perfectly fine adjective to attach to a function, so the 
name works fine there. But a type is a *noun* describing a *value*, and 
`NoReturn` is not. You are trying to cram a square peg into a round hole.

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

Yes. Something should be done about `@noreturn`, and this basic approach is the 
most elegant one available.

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

The approach, but not the name. As I pointed out previously, it does not match 
naming conventions or even the general semantic meaning of a return type.

(Incidentally, another reason I like the idea of eventually having a 
subtype-of-all-types `Never` is that I think we should treat 
`UnsafePointer` as our "pointer of uncertain type" type. That is, `void 
*` should be imported to Swift as `UnsafePointer`. That would inherently 
prevent you from using the `pointee` property, and if you thought of 
`sizeof(Never)` as being infinite—a plausible interpretation since `Never` 
*could* be a subtype of a type of any size—it would also imply that pointer 
arithmetic or allocation of `Never` buffers would always overflow unless you 
were handling zero `Never`s.)

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

I've used other languages with equivalents to `@noreturn`, and I think the 
bottom return value approach will be an improvement on that.

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

Quick reading of the final proposal, but I've participated in much of the 
discussion about this feature.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Xiaodi Wu via swift-evolution]

On Tue, Jun 21, 2016 at 6:25 PM, Brandon Knope  wrote:

> How can it be unpersuasive? I can *show* you that keys that are easier to
> type/reach exist for a large majority of user’s.
>

As I pointed out, your results are flawed because there are two keys
frequently reached for in the vicinity of \ which are excluded from your
analysis. Those keys are delete/backspace and return/enter.


>
> I am not saying it is a good idea or not to replace \, but to pretend that
> there isn’t an inconvenience there is unfair when every other part of the
> language is put under a magnifying glass for the sake of grammar, newbie
> friendliness, or this or that, etc...
>
>
We've discussed why it's sensible grammar; there is no argument to be made
here about whether pressing one labeled key or another is friendlier to a
beginner.


> This is *measurable*…it just depends on whether it bothers people or not
> enough. Most other things are based on opinion, but this *can* be based on
> numbers and usability.
>

See above; you measured wrong...


> This is *something used by everyone*. The usability cost is there and it
> is real. Just because “well it is easy for me to type” does not mean that
> it is ideal. It also doesn’t mean that the current choice is the wrong
> choice either. But it still is important to discuss while we can.
>
> And yes a keyboard IS only so big, but the range to that bigness can be
> pretty… big.
>
> Also, $ is not the only option. There are still far easier keys to type
> than \.
> Brandon
>
> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu  wrote:
>
> On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Actually… we can go pretty scientific on this sort of thing and heat map
>> keyboard usage to get a better picture of how “usable” this is.
>>
>> I pasted a file that contains seven \’s in it and heat mapped it at
>> https://www.patrick-wied.at/projects/heatmap-keyboard/
>>
>> Even *with* several \’s throughout my source file the majority of my key
>> presses take place much closer to the $ key than the \ key.
>>
>> I think we can all argue about what is clearer or not, but I think for
>> the majority of us, the \ key is quite inconvenient compared to the keys
>> around where we type the most.
>>
>> I also ran several of iOS 10’s sample code through the heat map and
>> continue to get pretty similar results: the \ is much further from the
>> hottest part of the keyboard than the ones closer to where your hand
>> usually rests.
>>
>> Maybe this is flawed, but I think it is hard to argue that the \ is easy
>> to type when there are far more usable alternatives.
>>
>
> I'm rather unpersuaded by this line of argument. The keyboard is only so
> big; it's a stretch to say that any key is less than absolutely usable.
> Moreover, \ is next the delete key, which I presume you use frequently and
> find no difficulty in reaching.
>
> You know what *is* unusable though? Try finding the $ key on an
> international keyboard.
>
>
>> Brandon
>>
>>
>>
>> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I also disagree for the same reasons that Gwynne and Brent mentioned: I
>> find '\(...)' easy to read, fine to type, and consistent with other string
>> escaping syntax.
>>
>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> > I find that typing \(var) is very disruptive to my typing flow. The
>>> more I code in Swift, the more I like it, but every time I'm coding and
>>> then have to hiccup while typing \ then ( causes me to be annoyed. I know,
>>> it's minor, but it isn't a key combination that flows quickly.
>>> >
>>> > I would much rather have $() or perhaps ${} (like Groovy lang) or
>>> perhaps @() to go along with other uses of @ throughout the language.
>>>
>>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I
>>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third
>>> character (besides \ and ") to mean something special in a string literal,
>>> it reuses one of the existing ones. There's no need to escape a character
>>> you wouldn't otherwise have to touch, or to think of another character as
>>> "magical" in a string. It fits nicely with the rest of the syntax, with `\`
>>> indicating a special construct and then `()` delimiting an expression, just
>>> as they do elsewhere in the language. It's an elegant solution to a problem
>>> traditionally solved inelegantly. It's very Swifty in that way.
>>>
>>> > A shifted key, like $ or @, followed by another shifted key like (,
>>> allows for a much faster flow and they are much closer to the home keys
>>> than \ which is nearly as far from home keys as possible (and awkward).
>>>
>>>
>>> I don't have any trouble typing it personally. If you find yourself
>>> accidentally typing `\9` or `|(`, we could probably offer an 

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Erica Sadun via swift-evolution]

>> You know what *is* unusable though? Try finding the $ key on an 
>> international keyboard.

And that, for me, is motivation in a nutshell. Swift won't always be used on OS 
X, where it's easy to set up Keyboard prefs to substitute (dollar) with $. 

I did a search for "which symbol keys appear on most international keyboards" 
but didn't get very far. Surely this is something to bring into the discussion 
if it exists?

-- E

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

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

[Darren Mo via swift-evolution]

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!

>> 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.)

>> DispatchSource factory methods
>> --
>> e.g. DispatchSource.read(fileDescriptor:queue:). The API Design Guidelines 
>> mandate that factory methods begin with the prefix “make”. Indeed, 
>> DispatchSource.read might mislead people to think that a read will be 
>> performed by this method. A better name would be 
>> .makeReadSource(fileDescriptor:queue:).
> 
> Agreed, these should probably be brought into line with that guideline.

Yay!

>> And why are these factory methods on DispatchSource instead of initializers 
>> on the subclasses? ReadDispatchSource.init(fileDescriptor:queue:) would be 
>> way clearer.
> 
> The source types are not subclasses, due to implementation details they are 
> protocols.

Oops, missed that. Sorry.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swigt-evolution] [Pitch] Make NSOrderedSet behave like any other collections from Foundation

[Tony Parker via swift-evolution]

Hi Remy, Brent,

We’re thinking about it but there are no plans for Swift 3 in this respect 
(although I think we’re going to keep the NS prefix on these types).

One of the complexities with this type is its performance characteristics, 
especially when used with CoreData (the reason it was introduced). CoreData 
relies a lot on proxying for performance reasons, but there is currently an 
impedance mismatch between that behavior and Swift’s focus on static typing.

- Tony

> On Jun 17, 2016, at 10:43 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> Unlike its companion collections like NSArray, NSDictionary, and NSSet, 
>> NSOrdered is still a class rather than a struct and has a subclass that is 
>> still NSMutableOrderedSet. This should probably receive the same treatment 
>> as the other classes
> 
> Swift Evolution proposal SE-0069 "Mutability and Foundation Value Types" 
> notes at the bottom 
> :
> 
>> The following classes were considered and rejected or deferred for the 
>> described reasons:
>> …
>>  • OrderedSet, CountedSet: We will consider these types in a future 
>> proposal.
> 
> 
> So sit tight—the Foundation team is already thinking about this. (That 
> doesn't mean you'll necessarily see it this year, though.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Thoughts on replacing \() with $() or some other symbol

[Brandon Knope via swift-evolution]

How can it be unpersuasive? I can *show* you that keys that are easier to 
type/reach exist for a large majority of user’s.

I am not saying it is a good idea or not to replace \, but to pretend that 
there isn’t an inconvenience there is unfair when every other part of the 
language is put under a magnifying glass for the sake of grammar, newbie 
friendliness, or this or that, etc...

This is measurable…it just depends on whether it bothers people or not enough. 
Most other things are based on opinion, but this *can* be based on numbers and 
usability.
This is something used by everyone. The usability cost is there and it is real. 
Just because “well it is easy for me to type” does not mean that it is ideal. 
It also doesn’t mean that the current choice is the wrong choice either. But it 
still is important to discuss while we can.

And yes a keyboard IS only so big, but the range to that bigness can be pretty… 
big.

Also, $ is not the only option. There are still far easier keys to type than \.

Brandon

> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu  wrote:
> 
> On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution 
> > wrote:
> Actually… we can go pretty scientific on this sort of thing and heat map 
> keyboard usage to get a better picture of how “usable” this is.
> 
> I pasted a file that contains seven \’s in it and heat mapped it at 
> https://www.patrick-wied.at/projects/heatmap-keyboard/ 
> 
> 
> Even *with* several \’s throughout my source file the majority of my key 
> presses take place much closer to the $ key than the \ key.
> 
> I think we can all argue about what is clearer or not, but I think for the 
> majority of us, the \ key is quite inconvenient compared to the keys around 
> where we type the most.
> 
> I also ran several of iOS 10’s sample code through the heat map and continue 
> to get pretty similar results: the \ is much further from the hottest part of 
> the keyboard than the ones closer to where your hand usually rests.
> 
> Maybe this is flawed, but I think it is hard to argue that the \ is easy to 
> type when there are far more usable alternatives.
> 
> I'm rather unpersuaded by this line of argument. The keyboard is only so big; 
> it's a stretch to say that any key is less than absolutely usable. Moreover, 
> \ is next the delete key, which I presume you use frequently and find no 
> difficulty in reaching.
> 
> You know what *is* unusable though? Try finding the $ key on an international 
> keyboard.
>  
> Brandon
> 
> 
> 
>> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution 
>> > wrote:
>> 
>> I also disagree for the same reasons that Gwynne and Brent mentioned: I find 
>> '\(...)' easy to read, fine to type, and consistent with other string 
>> escaping syntax.
>> 
>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> > I find that typing \(var) is very disruptive to my typing flow. The more I 
>> > code in Swift, the more I like it, but every time I'm coding and then have 
>> > to hiccup while typing \ then ( causes me to be annoyed. I know, it's 
>> > minor, but it isn't a key combination that flows quickly.
>> >
>> > I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps 
>> > @() to go along with other uses of @ throughout the language.
>> 
>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I 
>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third 
>> character (besides \ and ") to mean something special in a string literal, 
>> it reuses one of the existing ones. There's no need to escape a character 
>> you wouldn't otherwise have to touch, or to think of another character as 
>> "magical" in a string. It fits nicely with the rest of the syntax, with `\` 
>> indicating a special construct and then `()` delimiting an expression, just 
>> as they do elsewhere in the language. It's an elegant solution to a problem 
>> traditionally solved inelegantly. It's very Swifty in that way.
>> 
>> > A shifted key, like $ or @, followed by another shifted key like (, allows 
>> > for a much faster flow and they are much closer to the home keys than \ 
>> > which is nearly as far from home keys as possible (and awkward).
>> 
>> 
>> I don't have any trouble typing it personally. If you find yourself 
>> accidentally typing `\9` or `|(`, we could probably offer an error for the 
>> former or warning for the latter with a fix-it. But if you're complaining 
>> that it takes a tiny fraction of a second longer to type than `$(` would, 
>> then honestly, I just can't bring myself to care. Swift optimizes for code 
>> reading. If we wanted to optimize for code typing instead, we'd have a very 
>> different style.

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Xiaodi Wu via swift-evolution]

On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution <
swift-evolution@swift.org> wrote:

> Actually… we can go pretty scientific on this sort of thing and heat map
> keyboard usage to get a better picture of how “usable” this is.
>
> I pasted a file that contains seven \’s in it and heat mapped it at
> https://www.patrick-wied.at/projects/heatmap-keyboard/
>
> Even *with* several \’s throughout my source file the majority of my key
> presses take place much closer to the $ key than the \ key.
>
> I think we can all argue about what is clearer or not, but I think for the
> majority of us, the \ key is quite inconvenient compared to the keys around
> where we type the most.
>
> I also ran several of iOS 10’s sample code through the heat map and
> continue to get pretty similar results: the \ is much further from the
> hottest part of the keyboard than the ones closer to where your hand
> usually rests.
>
> Maybe this is flawed, but I think it is hard to argue that the \ is easy
> to type when there are far more usable alternatives.
>

I'm rather unpersuaded by this line of argument. The keyboard is only so
big; it's a stretch to say that any key is less than absolutely usable.
Moreover, \ is next the delete key, which I presume you use frequently and
find no difficulty in reaching.

You know what *is* unusable though? Try finding the $ key on an
international keyboard.


> Brandon
>
>
>
> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I also disagree for the same reasons that Gwynne and Brent mentioned: I
> find '\(...)' easy to read, fine to type, and consistent with other string
> escaping syntax.
>
> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > I find that typing \(var) is very disruptive to my typing flow. The
>> more I code in Swift, the more I like it, but every time I'm coding and
>> then have to hiccup while typing \ then ( causes me to be annoyed. I know,
>> it's minor, but it isn't a key combination that flows quickly.
>> >
>> > I would much rather have $() or perhaps ${} (like Groovy lang) or
>> perhaps @() to go along with other uses of @ throughout the language.
>>
>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I
>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third
>> character (besides \ and ") to mean something special in a string literal,
>> it reuses one of the existing ones. There's no need to escape a character
>> you wouldn't otherwise have to touch, or to think of another character as
>> "magical" in a string. It fits nicely with the rest of the syntax, with `\`
>> indicating a special construct and then `()` delimiting an expression, just
>> as they do elsewhere in the language. It's an elegant solution to a problem
>> traditionally solved inelegantly. It's very Swifty in that way.
>>
>> > A shifted key, like $ or @, followed by another shifted key like (,
>> allows for a much faster flow and they are much closer to the home keys
>> than \ which is nearly as far from home keys as possible (and awkward).
>>
>>
>> I don't have any trouble typing it personally. If you find yourself
>> accidentally typing `\9` or `|(`, we could probably offer an error for the
>> former or warning for the latter with a fix-it. But if you're complaining
>> that it takes a tiny fraction of a second longer to type than `$(` would,
>> then honestly, I just can't bring myself to care. Swift optimizes for code
>> reading. If we wanted to optimize for code typing instead, we'd have a very
>> different style.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> 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] Thoughts on replacing \() with $() or some other symbol

[David Hart via swift-evolution]

I’m not saying its necessarily *easy* to type, but I think its good enough to 
warrant the elegance of having only one escaping character instead of multiple.

> On 22 Jun 2016, at 01:08, Brandon Knope via swift-evolution 
>  wrote:
> 
> Actually… we can go pretty scientific on this sort of thing and heat map 
> keyboard usage to get a better picture of how “usable” this is.
> 
> I pasted a file that contains seven \’s in it and heat mapped it at 
> https://www.patrick-wied.at/projects/heatmap-keyboard/ 
> 
> 
> Even *with* several \’s throughout my source file the majority of my key 
> presses take place much closer to the $ key than the \ key.
> 
> I think we can all argue about what is clearer or not, but I think for the 
> majority of us, the \ key is quite inconvenient compared to the keys around 
> where we type the most.
> 
> I also ran several of iOS 10’s sample code through the heat map and continue 
> to get pretty similar results: the \ is much further from the hottest part of 
> the keyboard than the ones closer to where your hand usually rests.
> 
> Maybe this is flawed, but I think it is hard to argue that the \ is easy to 
> type when there are far more usable alternatives.
> 
> Brandon
> 
> 
> 
>> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution 
>> > wrote:
>> 
>> I also disagree for the same reasons that Gwynne and Brent mentioned: I find 
>> '\(...)' easy to read, fine to type, and consistent with other string 
>> escaping syntax.
>> 
>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> > I find that typing \(var) is very disruptive to my typing flow. The more I 
>> > code in Swift, the more I like it, but every time I'm coding and then have 
>> > to hiccup while typing \ then ( causes me to be annoyed. I know, it's 
>> > minor, but it isn't a key combination that flows quickly.
>> >
>> > I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps 
>> > @() to go along with other uses of @ throughout the language.
>> 
>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I 
>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third 
>> character (besides \ and ") to mean something special in a string literal, 
>> it reuses one of the existing ones. There's no need to escape a character 
>> you wouldn't otherwise have to touch, or to think of another character as 
>> "magical" in a string. It fits nicely with the rest of the syntax, with `\` 
>> indicating a special construct and then `()` delimiting an expression, just 
>> as they do elsewhere in the language. It's an elegant solution to a problem 
>> traditionally solved inelegantly. It's very Swifty in that way.
>> 
>> > A shifted key, like $ or @, followed by another shifted key like (, allows 
>> > for a much faster flow and they are much closer to the home keys than \ 
>> > which is nearly as far from home keys as possible (and awkward).
>> 
>> 
>> I don't have any trouble typing it personally. If you find yourself 
>> accidentally typing `\9` or `|(`, we could probably offer an error for the 
>> former or warning for the latter with a fix-it. But if you're complaining 
>> that it takes a tiny fraction of a second longer to type than `$(` would, 
>> then honestly, I just can't bring myself to care. Swift optimizes for code 
>> reading. If we wanted to optimize for code typing instead, we'd have a very 
>> different style.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[David Hart via swift-evolution]

>   * What is your evaluation of the proposal?

+1. This makes total sense. But I would recommend naming it “Never” for the 
same arguments as in the proposal.

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

Yes, it simplifies the language by replacing a rarely used attribute by an 
elegant solution from the type system. I also love how Never could be used with 
typed throws.

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

Yep: simplification and elegance.

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

No.

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

A good read.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Brandon Knope via swift-evolution]

Actually… we can go pretty scientific on this sort of thing and heat map 
keyboard usage to get a better picture of how “usable” this is.

I pasted a file that contains seven \’s in it and heat mapped it at 
https://www.patrick-wied.at/projects/heatmap-keyboard/

Even *with* several \’s throughout my source file the majority of my key 
presses take place much closer to the $ key than the \ key.

I think we can all argue about what is clearer or not, but I think for the 
majority of us, the \ key is quite inconvenient compared to the keys around 
where we type the most.

I also ran several of iOS 10’s sample code through the heat map and continue to 
get pretty similar results: the \ is much further from the hottest part of the 
keyboard than the ones closer to where your hand usually rests.

Maybe this is flawed, but I think it is hard to argue that the \ is easy to 
type when there are far more usable alternatives.

Brandon



> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution 
>  wrote:
> 
> I also disagree for the same reasons that Gwynne and Brent mentioned: I find 
> '\(...)' easy to read, fine to type, and consistent with other string 
> escaping syntax.
> 
> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution 
> > wrote:
> > I find that typing \(var) is very disruptive to my typing flow. The more I 
> > code in Swift, the more I like it, but every time I'm coding and then have 
> > to hiccup while typing \ then ( causes me to be annoyed. I know, it's 
> > minor, but it isn't a key combination that flows quickly.
> >
> > I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps 
> > @() to go along with other uses of @ throughout the language.
> 
> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I 
> immediately liked `\(…)`. It's parsimonious: Rather than taking a third 
> character (besides \ and ") to mean something special in a string literal, it 
> reuses one of the existing ones. There's no need to escape a character you 
> wouldn't otherwise have to touch, or to think of another character as 
> "magical" in a string. It fits nicely with the rest of the syntax, with `\` 
> indicating a special construct and then `()` delimiting an expression, just 
> as they do elsewhere in the language. It's an elegant solution to a problem 
> traditionally solved inelegantly. It's very Swifty in that way.
> 
> > A shifted key, like $ or @, followed by another shifted key like (, allows 
> > for a much faster flow and they are much closer to the home keys than \ 
> > which is nearly as far from home keys as possible (and awkward).
> 
> 
> I don't have any trouble typing it personally. If you find yourself 
> accidentally typing `\9` or `|(`, we could probably offer an error for the 
> former or warning for the latter with a fix-it. But if you're complaining 
> that it takes a tiny fraction of a second longer to type than `$(` would, 
> then honestly, I just can't bring myself to care. Swift optimizes for code 
> reading. If we wanted to optimize for code typing instead, we'd have a very 
> different style.
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 3:02 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> If I didn't think it would produce semantic confusion, these would be
> static members e.g. `Array.memoryAlignment`, and you'd have to “scan
> past” `Array`.  It's a perfectly natural way to express a property of a
> type.


I think

Array.memoryAlignment 

is quite different to scan than

MemoryLayout(Array).alignment

(And I obviously like the former a lot more if it wouldn't produce
semantic confusion -- I assume you mean in the compiler and not
the reader of the code). That said, I think

memoryAlignment(Array.self)

reads better than

MemoryLayout(Array).alignment

You don't have to brainparse(TM by Cognition Inc) two other things 
before arriving at alignment.  The MemoryLayout feels more prominent
than it should. The alignment feels less prominent than it should.

I recognize we disagree on this, and we're unlikely to convince each other 
on-list, which is why I tried hard to make sure that your alternative was 
properly presented in the proposal. If  I have made any errors in expressing 
your design, its intent, and rationale, please let me know and I will edit the 
proposal to fix.

-- E

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

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Kevin Nattinger via swift-evolution]

> On Jun 21, 2016, at 10:03 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0102: Remove @noreturn attribute and introduce an empty 
> NoReturn type" begins now and runs through June 27. The proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

-1. 
noreturn is logically and fundamentally an attribute of a function, not a 
return (pseudo-)type, and it should continue to be expressed that way. 
If the idea of `@noreturn foo() -> Int` being valid really bothers you so much, 
just forbid functions declared noreturn from having a specified return type 
(maybe even an explicit `()`/`Void`).


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

No.
There is no problem being solved. noreturn as an attribute is clear, 
precedented, and easily searchable. Furthermore, I feel the proposal doesn’t 
even fix most of the “issues” it brings up in the motivation section— `-> 
NoReturn throws` is no more clear than `@noreturn throws`, and `compose(exit, 
getExitCode)` is no more clear declared `-> NoReturn` than `@noreturn`.  And it 
introduces ambiguity of its own. If someone defines their own empty enum, does 
`func foo() -> MyEmptyEnum` get the same treatment as NoReturn? If not, why is 
it special cased? If so, 

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

No.
We want swift to be intuitive. IMO, `@noreturn` is way more intuitive than 
saying you’ll return something that you can’t actually follow through with. And 
 everywhere else such a contradiction would be a compiler error. 

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

It unnecessarily breaks from tradition. The C family uses noreturn attributes. 
I haven’t seen anyone bring up language where noreturn is achieved in this 
manner.

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

Followed the email chain, thoroughly read the proposal.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[David Hart via swift-evolution]

Entirely agree. \ makes total sense as the one-and-only escaping character. I 
also have no trouble typing it.

> On 21 Jun 2016, at 23:55, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I find that typing \(var) is very disruptive to my typing flow. The more I 
>> code in Swift, the more I like it, but every time I'm coding and then have 
>> to hiccup while typing \ then ( causes me to be annoyed. I know, it's minor, 
>> but it isn't a key combination that flows quickly.
>> 
>> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps 
>> @() to go along with other uses of @ throughout the language. 
> 
> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I 
> immediately liked `\(…)`. It's parsimonious: Rather than taking a third 
> character (besides \ and ") to mean something special in a string literal, it 
> reuses one of the existing ones. There's no need to escape a character you 
> wouldn't otherwise have to touch, or to think of another character as 
> "magical" in a string. It fits nicely with the rest of the syntax, with `\` 
> indicating a special construct and then `()` delimiting an expression, just 
> as they do elsewhere in the language. It's an elegant solution to a problem 
> traditionally solved inelegantly. It's very Swifty in that way.
> 
>> A shifted key, like $ or @, followed by another shifted key like (, allows 
>> for a much faster flow and they are much closer to the home keys than \ 
>> which is nearly as far from home keys as possible (and awkward). 
> 
> 
> I don't have any trouble typing it personally. If you find yourself 
> accidentally typing `\9` or `|(`, we could probably offer an error for the 
> former or warning for the latter with a fix-it. But if you're complaining 
> that it takes a tiny fraction of a second longer to type than `$(` would, 
> then honestly, I just can't bring myself to care. Swift optimizes for code 
> reading. If we wanted to optimize for code typing instead, we'd have a very 
> different style.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Make UUID conform to RawRepresentable

[Philippe Hausler via swift-evolution]

RawRepresentable is often used for open enums imported from c/objc so I am not 
certain that is the right semantics.

Sent from my iPhone

> On Jun 21, 2016, at 1:19 PM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
>> On 21 Jun 2016, at 01:53, Alsey Miller via swift-evolution 
>>  wrote:
>> 
>> I’m the developer of PureSwift/SwiftFoundation on GitHub, and I originally 
>> wrote that library after WWDC 2015 because I did not expect Apple to release 
>> an Open Source version of Foundation, and also because Foundation in Swift 
>> 2.2 was class based, and not struct based. Now in Swift 3 that is all 
>> changing (for the better), and I plan to deprecate my library, but there is 
>> one semantic that takes advantage of the Swift guidelines that the new Swift 
>> 3.0 Foundation in Xcode 8 doesn’t. UUID seems a natural candidate for 
>> conforming to RawRepresentable. Please check out the link below, and you can 
>> see how it naturally fits.
>> 
>> https://github.com/PureSwift/SwiftFoundation/blob/develop/Sources/SwiftFoundation/UUID.swift
> 
> Your library uses RawRepresentable for String conversion, but 
> LosslessStringConvertible (if SE-0089 is accepted) could also do this.
> 
> Then the RawRepresentable.RawValue could be `uuid_t` (equivalent to your 
> ByteValue tuple) instead.
> 
> NOTE: 
> 
> 
> -- Ben
> 
> ___
> 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] Thoughts on replacing \() with $() or some other symbol

[Jordan Rose via swift-evolution]

> On Jun 21, 2016, at 15:26, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Tue, Jun 21, 2016 at 5:10 PM, Daniel Resnick via swift-evolution 
> > wrote:
> I also disagree for the same reasons that Gwynne and Brent mentioned: I find 
> '\(...)' easy to read, fine to type, and consistent with other string 
> escaping syntax.
> 
> Those are persuasive arguments. Consistency with other string escaping syntax 
> is a huge plus. Moreover, now that I think about it, \r or \n isn't really a 
> bother to type. The \( combination takes a little getting used to, but it's 
> not absurdly terrible. I suppose we could consider \{} or even \[] instead of 
> \() to alleviate the reach.

Gwynne and Brent indeed hit on the logic for the original design: backslash is 
already an escape character in strings. The parentheses () over another kind of 
delimiter were originally to match calls (string interpolation once generated 
direct calls to String initializers), but even without that it’s still 
something that’s used with expressions, while curly braces {} are used for 
general code blocks and square brackets [] are used with collections.

I’m strongly in favor of keeping things the way they are, both because I like 
it a fair bit and because it’d be another source-breaking change that would be 
very hard to migrate.

Jordan

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

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

[Joe Groff via swift-evolution]

> On Jun 21, 2016, at 1:23 PM, Dave Abrahams  wrote:
> 
> 
> 
> 
> on Tue Jun 21 2016, Joe Groff 
>  wrote:
> 
>> Regarding the issue of existential metatypes with sizeof:
>> 
>> Pyry Jahkola points out one instance where the memorySize(type(of: …))
>> workaround won't work. When the value is an existential, it's illegal
>> to ask for the size of its dynamic type: the result can't be retrieved
>> at compile time:
>> 
>> // Swift 2.2, 64-bit
>> let i = 123
>> print(sizeofValue(i)) //=> 8
>> let c: CustomStringConvertible = i
>> print(sizeofValue(c)) //=> 40
>> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an 
>> argument list of type '(CustomStringCo
>> This could be enabled by having sizeof and friends formally take an
>> Any.Type instead of  T.Type. (This might need some tweaking of the
>> underlying builtins to be able to open existential metatypes, but it
>> seems implementable.)
> 
> Would it be as fully specializable down to a compile-time constant?

Seems like it ought to be. sizeof() is just a transparent wrapper around 
Builtin.sizeof IIRC, and we can control the codegen of the builtin.

-Joe

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Xiaodi Wu via swift-evolution]

On Tue, Jun 21, 2016 at 5:10 PM, Daniel Resnick via swift-evolution <
swift-evolution@swift.org> wrote:

> I also disagree for the same reasons that Gwynne and Brent mentioned: I
> find '\(...)' easy to read, fine to type, and consistent with other string
> escaping syntax.
>

Those are persuasive arguments. Consistency with other string escaping
syntax is a huge plus. Moreover, now that I think about it, \r or \n isn't
really a bother to type. The \( combination takes a little getting used to,
but it's not absurdly terrible. I suppose we could consider \{} or even \[]
instead of \() to alleviate the reach.



> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > I find that typing \(var) is very disruptive to my typing flow. The
>> more I code in Swift, the more I like it, but every time I'm coding and
>> then have to hiccup while typing \ then ( causes me to be annoyed. I know,
>> it's minor, but it isn't a key combination that flows quickly.
>> >
>> > I would much rather have $() or perhaps ${} (like Groovy lang) or
>> perhaps @() to go along with other uses of @ throughout the language.
>>
>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I
>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third
>> character (besides \ and ") to mean something special in a string literal,
>> it reuses one of the existing ones. There's no need to escape a character
>> you wouldn't otherwise have to touch, or to think of another character as
>> "magical" in a string. It fits nicely with the rest of the syntax, with `\`
>> indicating a special construct and then `()` delimiting an expression, just
>> as they do elsewhere in the language. It's an elegant solution to a problem
>> traditionally solved inelegantly. It's very Swifty in that way.
>>
>> > A shifted key, like $ or @, followed by another shifted key like (,
>> allows for a much faster flow and they are much closer to the home keys
>> than \ which is nearly as far from home keys as possible (and awkward).
>>
>>
>> I don't have any trouble typing it personally. If you find yourself
>> accidentally typing `\9` or `|(`, we could probably offer an error for the
>> former or warning for the latter with a fix-it. But if you're complaining
>> that it takes a tiny fraction of a second longer to type than `$(` would,
>> then honestly, I just can't bring myself to care. Swift optimizes for code
>> reading. If we wanted to optimize for code typing instead, we'd have a very
>> different style.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> 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] IUO in Swift 3.0

[Jonathan Cotton via swift-evolution]

I was also surprised this type still exists as I'd taken that the proposal was 
for the removal of IUO as an explicit type, but after some testing of IUO 
propagation behaviour in Swift 3.0, I'm happy to report the behaviour has been 
changed to meet the desired behaviour in the spec, specifically, I now don't 
need to define a separate interface signature to specifically expect type T!

> On 21 Jun 2016, at 21:22, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Just saw this article about IUO in Swift 3.0:
>> 
>> https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/
>> 
>> I was surprised that the IUO type still exists. From what I understood, 
>> SE-0054 gives a clear example that:
>> 
>> func f() -> Int! { return 3 } 
>> // f: () -> Int?, has IUO attribute
>> // ...
>> 
>> let x3: Int! = f() 
>> // succeeds; x3: Int? = .some(3), has IUO attribute
>> // ...
>> 
>> func g() -> Int! { return nil } 
>> // f: () -> Int?, has IUO attribute
>> // ...
>> 
>> let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute
>> 
>> x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 
>> playground show that they are still of type Int!. Did I miss something?
> 
> SE-0054 hasn't been fully implemented yet. The stricter implicit promotions 
> are mostly there, but the IUO type still exists.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Joe Groff 
 wrote:

> Regarding the issue of existential metatypes with sizeof:
>
> Pyry Jahkola points out one instance where the memorySize(type(of: …))
> workaround won't work. When the value is an existential, it's illegal
> to ask for the size of its dynamic type: the result can't be retrieved
> at compile time:
>
> // Swift 2.2, 64-bit
> let i = 123
> print(sizeofValue(i)) //=> 8
> let c: CustomStringConvertible = i
> print(sizeofValue(c)) //=> 40
> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an 
> argument list of type '(CustomStringCo
> This could be enabled by having sizeof and friends formally take an
> Any.Type instead of  T.Type. (This might need some tweaking of the
> underlying builtins to be able to open existential metatypes, but it
> seems implementable.)

Would it be as fully specializable down to a compile-time constant?

-- 
Dave

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Frederick Kellison-Linn via swift-evolution]

* What is your evaluation of the proposal?
-1. I don't believe that the '-> NoReturn' adequately expresses the behavior of a 
function.  I view the construction 'T -> U' as a contract which states 'give me a 
T and I'll give you a U'. This stops making sense when U is NoReturn: 'give me a T 
and I'll give you a NoReturn (note: I won't actually give you a NoReturn)'! This 
construction also moves the behavioral information about the function to the end of 
the signature, where it is more easily missed.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
I don't believe so. The main argument against @noreturn seems to be about 
complexity in the compiler, and an empty/bottom NoReturn type introduces 
complexity of its own with regards to subtyping, and special-casing the 
compiler to handle functions which return a particular type.

* Does this proposal fit well with the feel and direction of Swift?
Again, not IMO. Semantic modifications to function behavior in Swift are 
already well encompassed by attributes. These are a well established part of 
the language; if @noreturn were one of few attributes that were not wanted in 
the language, that would be a different matter, but attributes aren't going 
anywhere. Furthermore, I think that swift has mostly shied away from overly 
clever solutions in favor of clarity. I realize the desire in increasing the 
power of Swift's type system, but extending it to include properties which are 
arguably outside of the type system altogether doesn't seem like the right 
direction to go in.

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

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I read through the proposal and then the initial discussion on swift-evolution. 
Overall, I think that the @noreturn attribute better expresses that the 
behavior of the function is exceptional. NoReturn feels a bit too much like a 
clever hack to represent a type-that-is-not-a-type.

Freddy

On Jun 21, 2016, at 10:04 AM, Chris Lattner  wrote:

Hello Swift community,

The review of "SE-0102: Remove @noreturn attribute and introduce an empty NoReturn 
type" begins now and runs through June 27. The proposal is available here:

 
https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md

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

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

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

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

   * What is your evaluation of the proposal?
   * Is the problem being addressed significant enough to warrant a change to 
Swift?
     * Does this proposal fit well with the feel and direction of Swift?
     * If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
 * How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

More information about the Swift evolution process is available at

       https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Daniel Resnick via swift-evolution]

I also disagree for the same reasons that Gwynne and Brent mentioned: I
find '\(...)' easy to read, fine to type, and consistent with other string
escaping syntax.

On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > I find that typing \(var) is very disruptive to my typing flow. The more
> I code in Swift, the more I like it, but every time I'm coding and then
> have to hiccup while typing \ then ( causes me to be annoyed. I know, it's
> minor, but it isn't a key combination that flows quickly.
> >
> > I would much rather have $() or perhaps ${} (like Groovy lang) or
> perhaps @() to go along with other uses of @ throughout the language.
>
> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I
> immediately liked `\(…)`. It's parsimonious: Rather than taking a third
> character (besides \ and ") to mean something special in a string literal,
> it reuses one of the existing ones. There's no need to escape a character
> you wouldn't otherwise have to touch, or to think of another character as
> "magical" in a string. It fits nicely with the rest of the syntax, with `\`
> indicating a special construct and then `()` delimiting an expression, just
> as they do elsewhere in the language. It's an elegant solution to a problem
> traditionally solved inelegantly. It's very Swifty in that way.
>
> > A shifted key, like $ or @, followed by another shifted key like (,
> allows for a much faster flow and they are much closer to the home keys
> than \ which is nearly as far from home keys as possible (and awkward).
>
>
> I don't have any trouble typing it personally. If you find yourself
> accidentally typing `\9` or `|(`, we could probably offer an error for the
> former or warning for the latter with a fix-it. But if you're complaining
> that it takes a tiny fraction of a second longer to type than `$(` would,
> then honestly, I just can't bring myself to care. Swift optimizes for code
> reading. If we wanted to optimize for code typing instead, we'd have a very
> different style.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Michael Peternell via swift-evolution]

> Am 21.06.2016 um 19:03 schrieb Chris Lattner via swift-evolution 
> :
> 
> Hello Swift community,
> 
> The review of "SE-0102: Remove @noreturn attribute and introduce an empty 
> NoReturn type" begins now and runs through June 27. The proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?

-1
I like the common assumption that when a function returns a type T, it means 
that the function returns a value of type T. A function that does *not* return, 
does not return a value of type T, for any T. Specifically, it doesn't return a 
value that is included in the empty set. NoReturn looks like a hack to me, 
whereas @noreturn tells me unambiguously that the compiler understands the 
meaning of the word too. And I see no value in having a first class type name 
for the bottom type.
I usually like mathematics, and I like Haskell too, but this doesn't seem to 
fit well with any of these. @noreturn should stay separate from any return 
values. In most cases, a @noreturn function returns Void, but I see no value in 
enforcing this.
I would prefer to keep the status quo and reject the proposal completely.

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

No, there was no problem.

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

I don't think so.

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

No.

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

Read the proposal, participated in earlier discussion and I think I understand 
where it is coming from. It is mathematically consistent, but so is the current 
@noreturn implementation as well. The current implementation is also more 
intuitive IMHO.

-Michael

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

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[Dave Abrahams via swift-evolution]

on Mon Jun 20 2016, Brent Royal-Gordon  wrote:

>> A couple of weeks ago we started to notice that we had some poorly-named
>> closure parameters and argument labels in the standard library, so we
>> did a complete audit of the standard library's APIs and came up with a
>> preliminary proposal for changes, which we applied in a branch and you
>> can review in https://github.com/apple/swift/pull/2981.  Let's please
>> carry on further discussion here rather than in the pull request, though.
>
> In general, I like this; `orderingBy` is a particularly nice
> improvement over the old `isOrderedBefore` convention. 

I don't really love the use of “by”, FWIW, but I thought `orderingWith`
was more confusable (ordering A with B might swap A and B, whereas the
parameter is a closure).  It could be argued, though, that I am being
overly concerned with unlikely misinterpretations, at the cost of
“naturalness”—a known weakness of mine ;-).  Anyway, as ever I'm open to
discussion on this.

> A few specific comments about things I don't like:
>
> * In `map` and `flatMap`, I'm not sure how much `transform` buys us
>   over `elementTransform`.

I think you mean the converse.  And I agree that `elementTransform`
is probably not an improvement over `transform`.

> * In general, I'm not a fan of most of the changes away from `where`
> labels. 

The only such changes I can find are in
https://github.com/apple/swift/pull/2981/commits/3418eede88d724ad23731fe8f412f51e03cf5106

Note that part of this change was to make all filter closures
consistent; in the main `filter` API there was no label at all.
However, we felt that there's a real clarity problem with the polarity
of the argument (we talk about “filtering things out” but the closure
indicates which elements to keep).  And we couldn't find a “where”-based
name that began to clarify it.

I will argue that even changing to “suchThat,” as in the PR, does not
sufficiently clarify the closure's polarity, and the only true fix for
filter is to use a different base name (some have suggested “select,”
and I have other ideas), but that is out of scope for this particular
set of changes.  So if the community is happier with a “where” label
here I can live with it.  I do think “suchThat” is marginally clearer.

> Those are a nice, straightforward convention applied broadly across
> the Sequence APIs. (Yes, I criticized `where` as a method name in
> another thread, but I don't think `where` is a problem when there's a
> function base name to give it context.) When they don't work, that's
> usually because of a less-than-ideal base name. I'm not saying that
> *all* base names that aren't compatible with `where` should be
> changed, but rather that if `where` is not enough, that's an API
> smell.
>
> * In particular, `elementWhere` is not a good label for the same
> reason that `removeElement` is not a good name. Session 403 last week
> actually talked about this between roughly minutes 8 and 11. (I'm sure
> you know about its content; you probably saw it before we did.)

Yes I do, and I think you misinterpreted the message in that session.
There's nothing wrong with repeating type information when it's
necessary for clarity or fluency at the use-site.  In the case of
`contains(elementWhere:)`, it's there for fluency:

   customers.contains(where: isSingle)

doesn't read as well as:

   customers.contains(elementWhere: isSingle)

The point is not to imagine that every argument should be preceded by a
noun, and repetition of type information is often the result of trying
to do that.

> * I like `separatedWhere` on `split`, but I think the Equatable
> version needs a similar renaming. 

That's a nice thought; I think it's arguably out-of-scope here, though.

> Perhaps `separatedBy`?  `separatedOn`? The usual opposite of `where`,
> `of`, doesn't work here. (Alternatively, `separatedWhere` could be
> `separatorWhere` instead, but that's not quite as elegant.)

I'd want to consider variations of `separatingAt` or `onSeparator` or
`atSeparator` too... which makes me thing “separatedWhere” might not be
as good as “separatingWhere” for the closure version.

> * I'm very uncomfortable with the amount of weight
> `accumulatingResultBy` adds to `reduce`. `combinedBy` seems perfectly
> cromulent to me. I'm even more concerned by your suggestion in the
> pull request body of
> `accumulating(startingFrom:combiningBy:)`. `reduce` is a subtle and
> slightly confusing operation; adding more words to its call sites will
> not solve that problem. If you want to invent a new name from whole
> cloth, I would probably use something like `combining(with
> initialResult: T, by nextResult: (T, Element) -> T)`. (For that
> matter, while we're working in this area, `sequence(first:next:)`
> could use a similar coat of paint.)

As with `filter(suchThat:`, `reduce(accumulatingResultBy:` is attempting
to solve with an argument label what IMO is a grave weakness in clarity
of the 

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Brent Royal-Gordon via swift-evolution]

> I find that typing \(var) is very disruptive to my typing flow. The more I 
> code in Swift, the more I like it, but every time I'm coding and then have to 
> hiccup while typing \ then ( causes me to be annoyed. I know, it's minor, but 
> it isn't a key combination that flows quickly.
> 
> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps @() 
> to go along with other uses of @ throughout the language. 

Even though I'm used to Perl's and Ruby's interpolation syntaxes, I immediately 
liked `\(…)`. It's parsimonious: Rather than taking a third character (besides 
\ and ") to mean something special in a string literal, it reuses one of the 
existing ones. There's no need to escape a character you wouldn't otherwise 
have to touch, or to think of another character as "magical" in a string. It 
fits nicely with the rest of the syntax, with `\` indicating a special 
construct and then `()` delimiting an expression, just as they do elsewhere in 
the language. It's an elegant solution to a problem traditionally solved 
inelegantly. It's very Swifty in that way.

> A shifted key, like $ or @, followed by another shifted key like (, allows 
> for a much faster flow and they are much closer to the home keys than \ which 
> is nearly as far from home keys as possible (and awkward). 


I don't have any trouble typing it personally. If you find yourself 
accidentally typing `\9` or `|(`, we could probably offer an error for the 
former or warning for the latter with a fix-it. But if you're complaining that 
it takes a tiny fraction of a second longer to type than `$(` would, then 
honestly, I just can't bring myself to care. Swift optimizes for code reading. 
If we wanted to optimize for code typing instead, we'd have a very different 
style.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Tony Allevato via swift-evolution]

On Tue, Jun 21, 2016 at 10:04 AM Chris Lattner  wrote:

> Hello Swift community,
>
> The review of "SE-0102: Remove @noreturn attribute and introduce an empty
> NoReturn type" begins now and runs through June 27. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
>

+1. Encoding this behavior in the return type of a function is far more
natural than having an attribute that exists outside the type system. I
also don't think that it unduly restricts us from expanding its use into a
"true" bottom type in the future.

I prefer the name "Never" because it reads cleanly (func foo(...) -> Never
== "function foo takes ... as arguments and returns never"), and it works
well in some of the possible future scenarios described in the proposal.

While "Never" feels slightly less suitable as a true bottom type name,
other alternatives like "None" or "Nothing" feel too close to existing
Swift concepts, like the "none" case in Optional. You can still argue that
"Never" works here though, in the sense that you will "Never" have a value
of that type.



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

Yes. The benefits both in user case and in simplifying the language
implementation are strong.



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

Yes, this moves Swift in the direction of consistency that other proposals
have done.



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

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

Read the proposal and participated in some of the earlier discussions.


>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Gwynne Raskind via swift-evolution]

> On Jun 21, 2016, at 15:48, Jonathan Cotton via swift-evolution 
>  wrote:
> 
> I'd support $() as is in use by other languages, including Kotlin, as 
> mentioned it seems less disruptive and more inline with the tokenised 
> parameters that are already supported in closures.
> 
>> On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> I'm new to the list and I just searched through the archives as best I could 
>> to see if someone else had already brought this up, but I didn't find 
>> anything. Forgive me if this horse has been beaten.
>> 
>> I find that typing \(var) is very disruptive to my typing flow. The more I 
>> code in Swift, the more I like it, but every time I'm coding and then have 
>> to hiccup while typing \ then ( causes me to be annoyed. I know, it's minor, 
>> but it isn't a key combination that flows quickly.
>> 
>> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps 
>> @() to go along with other uses of @ throughout the language. 
>> 
>> A shifted key, like $ or @, followed by another shifted key like (, allows 
>> for a much faster flow and they are much closer to the home keys than \ 
>> which is nearly as far from home keys as possible (and awkward). 
>> 
>> Thoughts?
>> 
>> Kenny Wyland
>> InADayDevelopment.com 

I have to disagree - The \ syntax is consistent with other string escape 
sequences (\n etc.) and reads naturally to me in that regard. Additionally, the 
\ is very visually distinctive in a string, much moreso than the "traditional" 
$ variable marker. Almost every language I’ve seen using $ for interpolation in 
strings is doing so because it also uses it as a variable prefix in non-string 
contexts. To top it off, using $ instead would, for me, just add yet another 
language for which I have to remember "does the $ go inside or outside the name 
delimiter braces/brackets/whatever?", "is it parenthesis, braces, brackets, or 
some other delimiter for variable names?", "what kind of expressions can I use 
in this context?", "can I use interpolation without any delimiters for simple 
cases?", etc. See also PHP, Perl, ten flavors of shell scripts, JavaScript, 
JSP/ASP, XPath, and so forth. The \() syntax is unique to Swift and therefore 
very easy to remember.

I also don’t see that Swift carries an expectation of being able to use a 
syntax which is traditionally confined to interpreted/scripting languages, and 
even there $ is by no means ubiquitous. Here are just a few counterexamples 
among various languages:

- C (printf formats)
- C++ (stream modifiers)
- Objective-C (NSString formats)
- C# ($, but with the unusual syntax $"blah {foo} blah")
- Lua (printf formats and language hacks)
- Python (printf formats with trailing "% (tuple)" syntax)
- Ruby ("#{}")
- Java (printf formats)

There’s an obvious pattern in these example, which brings to something I 
_would_ like to see for string interpolation in Swift: Better control over the 
precise representation of the data. I’m sure the topic has been done to death 
many times before, but I haven’t found any solid information at a quick search, 
so I apologize if this is all old hat.

Anyway - Creating, configuring, and invoking various Formatter types in order 
to present data in the proper fashion is an option, and a preferable one when 
the data is intended for user consumption (especially to get the maximum 
support from localization). But for logging, debugging, parsing of textual 
formats, writing textual formats, etc., I almost always want a traditional 
C/POSIX/ISO representation as easily provided by printf()-style specifiers. 99% 
of the time when I want to do an number-to-string (integer or otherwise) 
conversion especially, I’m being specific about the appearance of the number.

For example, for a hex representation of sockaddr_in.sin_addr.s_addr, I would 
in other languages write "printf("0x%08x", address.sin_addr.s_addr);", or 
"%02hhu" times four to get dotted-decimal notation. (Ignoring for the moment 
the existence of inet_ntop() for the sake of the example :). In Swift, I 
currently have to make a call to printf(), fprintf(), dprintf(), 
NSString(format:), asprintf() (with a wrapper to deal with getting a 
Swift.String from allocated memory), etc. A configured NumberFormatter instance 
is a great deal more code - even NumberFormatter.localizedString(from: foo, 
number: .decimal) is very verbose, and that *still* doesn’t yield the same 
level of format control!).

And to top it off, these still carry the traditional problem of printf() 
formats - separation between the format specifier and the data that format 
applies to. I’m sure most of us have at one time or another written a printf() 
with enough arguments that it was easy to lose track of them and end up being 
very grateful for the existence of -Werror=format (and frustrated that 

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[David Waite via swift-evolution]

If such bike-shed repainting is under serious consideration, I’d request that 
the tint take into account the possibility of string formatter options being 
desired in the future. Outside of that, I’m just as happy with the current 
symbol as I would be with the proposals I’ve heard so far.

-DW

> On Jun 21, 2016, at 3:03 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Jun 21 2016, Kenny Wyland  > wrote:
> 
>> Hi all,
>> 
>> I'm new to the list and I just searched through the archives as best I
>> could to see if someone else had already brought this up, but I didn't find
>> anything. Forgive me if this horse has been beaten.
>> 
>> I find that typing \(var) is very disruptive to my typing flow. The more I
>> code in Swift, the more I like it, but every time I'm coding and then have
>> to hiccup while typing \ then ( causes me to be annoyed. I know, it's
>> minor, but it isn't a key combination that flows quickly.
>> 
>> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps
>> @() to go along with other uses of @ throughout the language.
>> 
>> A shifted key, like $ or @, followed by another shifted key like (, allows
>> for a much faster flow and they are much closer to the home keys than \
>> which is nearly as far from home keys as possible (and awkward).
> 
> I'm forced to agree that \ is quite awkward for something that may be
> used so pervasively, and $ would likely meet more peoples' expectations.
> 
> -- 
> Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Brandon Knope via swift-evolution]

I agree big time. It is pretty awkward to type and I completely understand the 
angst when having to type it!

$() seems like the better option, though maybe not as nice looking as \() 
(maybe it is on second thought?) it is much easier to type!

Brandon 
 
> On Jun 21, 2016, at 5:22 PM, Saagar Jha via swift-evolution 
>  wrote:
> 
> %, at least to me, suggests distant evaluation; i.e. parameter passing at the 
> end. $ seems more like an in-place evaluation, like how bash does it.
> 
>> On Tue, Jun 21, 2016 at 2:14 PM Xiaodi Wu via swift-evolution 
>>  wrote:
>> That said, I think it's nice that \, #, $, and @ are all used in unique 
>> scenarios. What about going a little classical with %?
>>> On Tue, Jun 21, 2016 at 16:10 Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> on Tue Jun 21 2016, Kenny Wyland  wrote:
>>> 
>>> > Hi all,
>>> >
>>> > I'm new to the list and I just searched through the archives as best I
>>> > could to see if someone else had already brought this up, but I didn't 
>>> > find
>>> > anything. Forgive me if this horse has been beaten.
>>> >
>>> > I find that typing \(var) is very disruptive to my typing flow. The more I
>>> > code in Swift, the more I like it, but every time I'm coding and then have
>>> > to hiccup while typing \ then ( causes me to be annoyed. I know, it's
>>> > minor, but it isn't a key combination that flows quickly.
>>> >
>>> > I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps
>>> > @() to go along with other uses of @ throughout the language.
>>> >
>>> > A shifted key, like $ or @, followed by another shifted key like (, allows
>>> > for a much faster flow and they are much closer to the home keys than \
>>> > which is nearly as far from home keys as possible (and awkward).
>>> 
>>> I'm forced to agree that \ is quite awkward for something that may be
>>> used so pervasively, and $ would likely meet more peoples' expectations.
>>> 
>>> --
>>> Dave
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -- 
> -Saagar Jha
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Charlie Monroe via swift-evolution]

>   * What is your evaluation of the proposal?

-1. I am for introducting a bottom type, but when it will be of more use and 
can be more universally designed. To me it feels like a hot-fix for something 
that isn't broken rather than a step forward for the language itself.

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

No.

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

Not yet. Introducing a bottom type is a good idea, but I feel that Swift isn't 
there yet to design it well and universally.

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

Scala has Nothing and it's a true bottom type. In regards to this proposal, 
Scala's solution is superior.

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

Read of the proposal + discussion.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Kurt Werle via swift-evolution]

I really don't like \.  I'd prefer just about any of the shift keys
(!@#$%^&).

That said, I would shut up and cope if xCode did the right thing when you
were typing a \ inside "'s and just filled in the () and placed the cursor
in the right spot.  I guess that would upset folks that type a lot of
\otherstuff in "'s, but I could live with that.

On Tue, Jun 21, 2016 at 2:22 PM, Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> %, at least to me, suggests distant evaluation; i.e. parameter passing at
> the end. $ seems more like an in-place evaluation, like how bash does it.
>
> On Tue, Jun 21, 2016 at 2:14 PM Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> That said, I think it's nice that \, #, $, and @ are all used in unique
>> scenarios. What about going a little classical with %?
>> On Tue, Jun 21, 2016 at 16:10 Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> on Tue Jun 21 2016, Kenny Wyland  wrote:
>>>
>>> > Hi all,
>>> >
>>> > I'm new to the list and I just searched through the archives as best I
>>> > could to see if someone else had already brought this up, but I didn't
>>> find
>>> > anything. Forgive me if this horse has been beaten.
>>> >
>>> > I find that typing \(var) is very disruptive to my typing flow. The
>>> more I
>>> > code in Swift, the more I like it, but every time I'm coding and then
>>> have
>>> > to hiccup while typing \ then ( causes me to be annoyed. I know, it's
>>> > minor, but it isn't a key combination that flows quickly.
>>> >
>>> > I would much rather have $() or perhaps ${} (like Groovy lang) or
>>> perhaps
>>> > @() to go along with other uses of @ throughout the language.
>>> >
>>> > A shifted key, like $ or @, followed by another shifted key like (,
>>> allows
>>> > for a much faster flow and they are much closer to the home keys than \
>>> > which is nearly as far from home keys as possible (and awkward).
>>>
>>> I'm forced to agree that \ is quite awkward for something that may be
>>> used so pervasively, and $ would likely meet more peoples' expectations.
>>>
>>> --
>>> Dave
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> -Saagar Jha
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
k...@circlew.org
http://www.CircleW.org/kurt/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] IUO in Swift 3.0

[David Hart via swift-evolution]

Is there a bug tracking the remaining part of the implementation?
Shouldn’t the proposal still be under “Not yet implemented” as its not 
completely implemented?

David.

> On 21 Jun 2016, at 22:22, Joe Groff  wrote:
> 
>> 
>> On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Just saw this article about IUO in Swift 3.0:
>> 
>> https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/
>> 
>> I was surprised that the IUO type still exists. From what I understood, 
>> SE-0054 gives a clear example that:
>> 
>> func f() -> Int! { return 3 } 
>> // f: () -> Int?, has IUO attribute
>> // ...
>> 
>> let x3: Int! = f() 
>> // succeeds; x3: Int? = .some(3), has IUO attribute
>> // ...
>> 
>> func g() -> Int! { return nil } 
>> // f: () -> Int?, has IUO attribute
>> // ...
>> 
>> let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute
>> 
>> x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 
>> playground show that they are still of type Int!. Did I miss something?
> 
> SE-0054 hasn't been fully implemented yet. The stricter implicit promotions 
> are mostly there, but the IUO type still exists.
> 
> -Joe

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Brandon Knope via swift-evolution]

I have to say, this might be the most swifty of the swift proposals. 

There's something about it that's elegant and beautiful, so big +1 from me. 

I do think Never makes more sense, but I understand the clarity that NoReturn 
brings. 

For a feature that most probably won't even use, maybe we could get away with 
it being Never...

Brandon 

> On Jun 21, 2016, at 1:03 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0102: Remove @noreturn attribute and introduce an empty 
> NoReturn type" begins now and runs through June 27. The proposal is available 
> here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?
>* Is the problem being addressed significant enough to warrant a change to 
> Swift?
>* Does this proposal fit well with the feel and direction of Swift?
>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matt Wright via swift-evolution]

> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution 
>  wrote:
> 
> SE-0088 was accepted with revisions a month ago. However, some of the APIs 
> just don’t feel right to me. I’ve only used DispatchQueue and DispatchSource 
> so far, so I will only comment on those.
> 
> DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
> --
> The lack of verb in the base name bothers me. The API Design Guidelines say 
> “methods with side-effects should read as imperative verb phrases”. You could 
> argue that the argument label “execute” serves as the verb. However, .async 
> and .sync are most commonly used with trailing closures where the argument 
> label is not present.
> 
> This issue was brought up during the review, but I did not see it being 
> addressed. Why not name the methods something like .executeAsync(_:) and 
> .executeSync(_:)?
> 
> 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.

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

> 
> DispatchSource factory methods
> --
> e.g. DispatchSource.read(fileDescriptor:queue:). The API Design Guidelines 
> mandate that factory methods begin with the prefix “make”. Indeed, 
> DispatchSource.read might mislead people to think that a read will be 
> performed by this method. A better name would be 
> .makeReadSource(fileDescriptor:queue:).

Agreed, these should probably be brought into line with that guideline.

> And why are these factory methods on DispatchSource instead of initializers 
> on the subclasses? ReadDispatchSource.init(fileDescriptor:queue:) would be 
> way clearer.

The source types are not subclasses, due to implementation details they are 
protocols.

> ___
> 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] [SE-0088] Dispatch API names

[Matt Wright via swift-evolution]

> On Jun 20, 2016, at 7:12 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> 
> On Mon, Jun 20, 2016 at 9:05 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> > DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
> > --
> > The lack of verb in the base name bothers me. The API Design Guidelines say 
> > “methods with side-effects should read as imperative verb phrases”. You 
> > could argue that the argument label “execute” serves as the verb. However, 
> > .async and .sync are most commonly used with trailing closures where the 
> > argument label is not present.
> >
> > This issue was brought up during the review, but I did not see it being 
> > addressed. Why not name the methods something like .executeAsync(_:) and 
> > .executeSync(_:)?
> 
> That feels a little redundant to me. It's worth remembering that the API 
> Guidelines are a means of creating clear APIs, not an end in themselves. It's 
> okay to deviate a little if you get a better result.
> 
> The guideline that methods should "read as imperative verb phrases" applies 
> to the full name, labels and arguments and all, and not just the base name. 
> You'll recall that the original proposal had .asynchronously(execute:), which 
> is very much an imperative phrase. `.async(execute:)` was substituted by 
> popular demand, with "async" being regarded as a term-of-art exception.

Right, the naming here strayed from the guidelines here under the term-of-art 
exception. None of the various alternatives really fit amazingly well, the 
async{,hronous} part of the API name communicates an important facet of what 
the call does. In that it goes away and executes the closure “somewhere else”. 
I feel this particular point is lost in example such as perform{andWait}. 
`.asynchronously` was an attempt to move towards the guidelines but it still 
missed that mark. I believe it’s still clearer to have `.async` as an exception.

> 
> However, I could see us borrowing (and slightly modifying) terminology from 
> Core Data:
> 
> queue.perform { … }
> queue.performAndWait { … }
> 
> Compared to the status quo, this is clearer, a better fit for the guidelines, 
> and better at penalizing the disfavored API.
> 
> > 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:_:).
> 
> Yeah, I gave a talk about the renaming on Saturday and somebody noted that 
> `when` reads poorly here. Fortunately, `queue.perform(after: .now() + 0.5)` 
> reads pretty well too. :^)
> 
> Or just `queue.after(_:execute:)`, i.e. "after [this time], execute [that 
> routine].”

.after is already going to need some tweaking as I don’t believe the current 
incarnation is sufficiently named to avoid being ambiguous in the common case. 
Though, removing the label will also not help in that regard. I agree, there is 
probably merit in the idea of moving after to being an optional argument on 
`.async`.

> 
> --
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Thoughts on replacing \() with $() or some other symbol

[Saagar Jha via swift-evolution]

%, at least to me, suggests distant evaluation; i.e. parameter passing at
the end. $ seems more like an in-place evaluation, like how bash does it.

On Tue, Jun 21, 2016 at 2:14 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> That said, I think it's nice that \, #, $, and @ are all used in unique
> scenarios. What about going a little classical with %?
> On Tue, Jun 21, 2016 at 16:10 Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> on Tue Jun 21 2016, Kenny Wyland  wrote:
>>
>> > Hi all,
>> >
>> > I'm new to the list and I just searched through the archives as best I
>> > could to see if someone else had already brought this up, but I didn't
>> find
>> > anything. Forgive me if this horse has been beaten.
>> >
>> > I find that typing \(var) is very disruptive to my typing flow. The
>> more I
>> > code in Swift, the more I like it, but every time I'm coding and then
>> have
>> > to hiccup while typing \ then ( causes me to be annoyed. I know, it's
>> > minor, but it isn't a key combination that flows quickly.
>> >
>> > I would much rather have $() or perhaps ${} (like Groovy lang) or
>> perhaps
>> > @() to go along with other uses of @ throughout the language.
>> >
>> > A shifted key, like $ or @, followed by another shifted key like (,
>> allows
>> > for a much faster flow and they are much closer to the home keys than \
>> > which is nearly as far from home keys as possible (and awkward).
>>
>> I'm forced to agree that \ is quite awkward for something that may be
>> used so pervasively, and $ would likely meet more peoples' expectations.
>>
>> --
>> Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Xiaodi Wu via swift-evolution]

That said, I think it's nice that \, #, $, and @ are all used in unique
scenarios. What about going a little classical with %?
On Tue, Jun 21, 2016 at 16:10 Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Tue Jun 21 2016, Kenny Wyland  wrote:
>
> > Hi all,
> >
> > I'm new to the list and I just searched through the archives as best I
> > could to see if someone else had already brought this up, but I didn't
> find
> > anything. Forgive me if this horse has been beaten.
> >
> > I find that typing \(var) is very disruptive to my typing flow. The more
> I
> > code in Swift, the more I like it, but every time I'm coding and then
> have
> > to hiccup while typing \ then ( causes me to be annoyed. I know, it's
> > minor, but it isn't a key combination that flows quickly.
> >
> > I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps
> > @() to go along with other uses of @ throughout the language.
> >
> > A shifted key, like $ or @, followed by another shifted key like (,
> allows
> > for a much faster flow and they are much closer to the home keys than \
> > which is nearly as far from home keys as possible (and awkward).
>
> I'm forced to agree that \ is quite awkward for something that may be
> used so pervasively, and $ would likely meet more peoples' expectations.
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 2:36 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Tue Jun 21 2016, Erica Sadun > > wrote:
>> 
>
 On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution
  wrote:
 This could be enabled by having sizeof and friends formally take an
 Any.Type instead of  T.Type. (This might need some tweaking of
 the underlying builtins to be able to open existential metatypes,
 but it seems implementable.)
>>> 
>>> While I'm not a huge fan of Dave A's generic struct approach (for
>>> reasons detailed in the proposal), 
>> 
>> Some of the examples used to justify avoiding that approach look
>> wrong or overly complicated to me.  Am I missing something?
>> 
>>let errnoSize = MemoryLayout.init(t: errno).size
>> 
>>_class_getInstancePositiveExtentSize(bufferClass) ==
>>MemoryLayout<_HeapObject.self>.size
>> 
>> wouldn't that be:
>> 
>>let errnoSize = MemoryLayout(errno).size
>> 
>>_class_getInstancePositiveExtentSize(bufferClass) == 
>>MemoryLayout<_HeapObject>.size
>> 
>> ? 
>> 
>> Once you fix those issues, I don't find my proposal to hurt
>> readability at all.  One has to put those examples into their actual
>> contexts rather than packing them all next to one another, to evaluate
>> it fairly.
>> 
>> Finally, I still object to doubling the API surface area just so you can
>> pass values instead of types to these functions.  Having three global
>> functions is acceptable, but six is too many, and arguably, having a
>> single type would be better.
>
> * I sourced my examples from the stdlib. That one's from ManagedBuffer.swift.
>   Only qualification was that I was looking for examples of sizeof.

I understand that, but I don't see how it's relevant.  My point was that
these don't appear in code stacked one on top of another like that.

> * In regard to offering both of and ofValue, I agree: I'd rather offer
> half the surface area, especially since Joe says the main issue is
> technically avoidable.
>
> * I don't like having to scan past the MemoryLayout and the type in question 
> to
> get to the member name that defines what property is requested. You have to 
> read it back
> to front. I find that to be a human factors limitation that makes it
> less desirable to use.

The “type in question” is very much relevant, just as in
`customers.count`, `customers` is relevant.  

If I didn't think it would produce semantic confusion, these would be
static members e.g. `Array.memoryAlignment`, and you'd have to “scan
past” `Array`.  It's a perfectly natural way to express a property of a
type.

> * At the same time, what I do like about the struct is that it's
> extensible without introducing standalone functions (and shrinks the
> number of functions that exist in the stdlib), and that the properties
> express intrinsic characteristics of the memory layout of a given
> type. The functions are measure-y. The properties are
> characteristic-y.

It even directly supports the -Value variants without expanding the
global API surface area, per

   MemoryLayout(errno).size

however, I don't think this is a good idea because of the potential for
confusion in cases like this:

   MemoryLayout(Int.self).size

-- 
Dave

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Kenny Wyland  wrote:

> Hi all,
>
> I'm new to the list and I just searched through the archives as best I
> could to see if someone else had already brought this up, but I didn't find
> anything. Forgive me if this horse has been beaten.
>
> I find that typing \(var) is very disruptive to my typing flow. The more I
> code in Swift, the more I like it, but every time I'm coding and then have
> to hiccup while typing \ then ( causes me to be annoyed. I know, it's
> minor, but it isn't a key combination that flows quickly.
>
> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps
> @() to go along with other uses of @ throughout the language.
>
> A shifted key, like $ or @, followed by another shifted key like (, allows
> for a much faster flow and they are much closer to the home keys than \
> which is nearly as far from home keys as possible (and awkward).

I'm forced to agree that \ is quite awkward for something that may be
used so pervasively, and $ would likely meet more peoples' expectations.

-- 
Dave

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

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, "Vladimir.S via swift-evolution" 
 wrote:

> On 21.06.2016 0:56, Brent Royal-Gordon via swift-evolution wrote:
 And as I said, if we feel `filter` is unsalvageable, the alternate
 Smalltalk-lineage `select` is clearer.
>>>
>>> Than “where?”
>>
>> No, than "filter". "filter" is the most common name, but "select" is
>
> Why not x.select(where: isPrime) ? IMO this is more clear than
> x.select(filter: isPrime) and looks similar to `where` in other parts
> of language.

I have some reasons worthy of consideration, but would prefer to
postpone this discussion until after we deal with
http://mid.gmane.org/m27fdjzh72.fsf%40fripp.apple.com

-- 
Dave

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Jonathan Cotton via swift-evolution]

I'd support $() as is in use by other languages, including Kotlin, as mentioned 
it seems less disruptive and more inline with the tokenised parameters that are 
already supported in closures.

> On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I'm new to the list and I just searched through the archives as best I could 
> to see if someone else had already brought this up, but I didn't find 
> anything. Forgive me if this horse has been beaten.
> 
> I find that typing \(var) is very disruptive to my typing flow. The more I 
> code in Swift, the more I like it, but every time I'm coding and then have to 
> hiccup while typing \ then ( causes me to be annoyed. I know, it's minor, but 
> it isn't a key combination that flows quickly.
> 
> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps @() 
> to go along with other uses of @ throughout the language. 
> 
> A shifted key, like $ or @, followed by another shifted key like (, allows 
> for a much faster flow and they are much closer to the home keys than \ which 
> is nearly as far from home keys as possible (and awkward). 
> 
> Thoughts?
> 
> Kenny Wyland
> InADayDevelopment.com
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 2:36 PM, Dave Abrahams  wrote:
> 
> 
> on Tue Jun 21 2016, Erica Sadun  > wrote:
> 
>>> On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution 
>>>  wrote:
>>> This could be enabled by having sizeof and friends formally take an
>>> Any.Type instead of  T.Type. (This might need some tweaking of
>>> the underlying builtins to be able to open existential metatypes,
>>> but it seems implementable.)
>> 
>> While I'm not a huge fan of Dave A's generic struct approach (for
>> reasons detailed in the proposal), 
> 
> Some of the examples used to justify avoiding that approach look
> wrong or overly complicated to me.  Am I missing something?
> 
>let errnoSize = MemoryLayout.init(t: errno).size
> 
>_class_getInstancePositiveExtentSize(bufferClass) ==
>MemoryLayout<_HeapObject.self>.size
> 
> wouldn't that be:
> 
>let errnoSize = MemoryLayout(errno).size
> 
>_class_getInstancePositiveExtentSize(bufferClass) == 
>MemoryLayout<_HeapObject>.size
> 
> ? 
> 
> Once you fix those issues, I don't find my proposal to hurt
> readability at all.  One has to put those examples into their actual
> contexts rather than packing them all next to one another, to evaluate
> it fairly.
> 
> Finally, I still object to doubling the API surface area just so you can
> pass values instead of types to these functions.  Having three global
> functions is acceptable, but six is too many, and arguably, having a
> single type would be better.

* I sourced my examples from the stdlib. That one's from ManagedBuffer.swift.
Only qualification was that I was looking for examples of sizeof.

* In regard to offering both of and ofValue, I agree: I'd rather offer half the 
surface area,
especially since Joe says the main issue is technically avoidable.

* I don't like having to scan past the MemoryLayout and the type in question to
get to the member name that defines what property is requested. You have to 
read it back
to front. I find that to be a human factors limitation that makes it less 
desirable to use.

* At the same time, what I do like about the struct is that it's extensible 
without introducing
standalone functions (and shrinks the number of functions that exist in the 
stdlib), and that 
the properties express intrinsic characteristics of the memory layout of a 
given type. The
functions are measure-y. The properties are characteristic-y.

-- E

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

[swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Kenny Wyland via swift-evolution]

Hi all,

I'm new to the list and I just searched through the archives as best I
could to see if someone else had already brought this up, but I didn't find
anything. Forgive me if this horse has been beaten.

I find that typing \(var) is very disruptive to my typing flow. The more I
code in Swift, the more I like it, but every time I'm coding and then have
to hiccup while typing \ then ( causes me to be annoyed. I know, it's
minor, but it isn't a key combination that flows quickly.

I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps
@() to go along with other uses of @ throughout the language.

A shifted key, like $ or @, followed by another shifted key like (, allows
for a much faster flow and they are much closer to the home keys than \
which is nearly as far from home keys as possible (and awkward).

Thoughts?

Kenny Wyland
InADayDevelopment.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] IUO in Swift 3.0

[Jonathan Cotton via swift-evolution]

I was also surprised this type still exists as I'd taken that the proposal was 
for the removal of IUO as an explicit type, but after some testing of IUO 
propagation behaviour in Swift 3.0, I'm happy to report the behaviour has been 
changed to meet the desired behaviour in the spec, specifically, I now don't 
need to define a separate interface signature to specifically expect type T!

> On 21 Jun 2016, at 21:22, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Just saw this article about IUO in Swift 3.0:
>> 
>> https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/
>> 
>> I was surprised that the IUO type still exists. From what I understood, 
>> SE-0054 gives a clear example that:
>> 
>> func f() -> Int! { return 3 } 
>> // f: () -> Int?, has IUO attribute
>> // ...
>> 
>> let x3: Int! = f() 
>> // succeeds; x3: Int? = .some(3), has IUO attribute
>> // ...
>> 
>> func g() -> Int! { return nil } 
>> // f: () -> Int?, has IUO attribute
>> // ...
>> 
>> let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute
>> 
>> x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 
>> playground show that they are still of type Int!. Did I miss something?
> 
> SE-0054 hasn't been fully implemented yet. The stricter implicit promotions 
> are mostly there, but the IUO type still exists.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

on Tue Jun 21 2016, Erica Sadun  wrote:

>> On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> Regarding the issue of existential metatypes with sizeof:
>> 
>> Pyry Jahkola points out one instance where the memorySize(type(of:
>
>> …)) workaround won't work. When the value is an existential, it's
>> illegal to ask for the size of its dynamic type: the result can't be
>> retrieved at compile time:
>> 
>> let i = 123
>> let c: CustomStringConvertible = i
>> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an 
>> argument list of type '(CustomStringCo
>> This could be enabled by having sizeof and friends formally take an
>> Any.Type instead of  T.Type. (This might need some tweaking of
>> the underlying builtins to be able to open existential metatypes,
>> but it seems implementable.)
>
> While I'm not a huge fan of Dave A's generic struct approach (for
> reasons detailed in the proposal), 

Some of the examples used to justify avoiding that approach look
wrong or overly complicated to me.  Am I missing something?

let errnoSize = MemoryLayout.init(t: errno).size

_class_getInstancePositiveExtentSize(bufferClass) ==
MemoryLayout<_HeapObject.self>.size

wouldn't that be:

let errnoSize = MemoryLayout(errno).size

_class_getInstancePositiveExtentSize(bufferClass) == 
MemoryLayout<_HeapObject>.size

? 

Once you fix those issues, I don't find my proposal to hurt
readability at all.  One has to put those examples into their actual
contexts rather than packing them all next to one another, to evaluate
it fairly.

Finally, I still object to doubling the API surface area just so you can
pass values instead of types to these functions.  Having three global
functions is acceptable, but six is too many, and arguably, having a
single type would be better.

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

Re: [swift-evolution] IUO in Swift 3.0

[Joe Groff via swift-evolution]

> On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution 
>  wrote:
> 
> Just saw this article about IUO in Swift 3.0:
> 
> https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/
> 
> I was surprised that the IUO type still exists. From what I understood, 
> SE-0054 gives a clear example that:
> 
> func f() -> Int! { return 3 } 
> // f: () -> Int?, has IUO attribute
> // ...
> 
> let x3: Int! = f() 
> // succeeds; x3: Int? = .some(3), has IUO attribute
> // ...
> 
> func g() -> Int! { return nil } 
> // f: () -> Int?, has IUO attribute
> // ...
> 
> let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute
> 
> x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 
> playground show that they are still of type Int!. Did I miss something?

SE-0054 hasn't been fully implemented yet. The stricter implicit promotions are 
mostly there, but the IUO type still exists.

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

Re: [swift-evolution] Make UUID conform to RawRepresentable

[Ben Rimmington via swift-evolution]

> On 21 Jun 2016, at 01:53, Alsey Miller via swift-evolution 
>  wrote:
> 
> I’m the developer of PureSwift/SwiftFoundation on GitHub, and I originally 
> wrote that library after WWDC 2015 because I did not expect Apple to release 
> an Open Source version of Foundation, and also because Foundation in Swift 
> 2.2 was class based, and not struct based. Now in Swift 3 that is all 
> changing (for the better), and I plan to deprecate my library, but there is 
> one semantic that takes advantage of the Swift guidelines that the new Swift 
> 3.0 Foundation in Xcode 8 doesn’t. UUID seems a natural candidate for 
> conforming to RawRepresentable. Please check out the link below, and you can 
> see how it naturally fits.
> 
> https://github.com/PureSwift/SwiftFoundation/blob/develop/Sources/SwiftFoundation/UUID.swift

Your library uses RawRepresentable for String conversion, but 
LosslessStringConvertible (if SE-0089 is accepted) could also do this.

Then the RawRepresentable.RawValue could be `uuid_t` (equivalent to your 
ByteValue tuple) instead.

NOTE: 


-- Ben

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

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

[Brandon Knope via swift-evolution]

I'm not convinced that perform is clearer than async.

performAndWait *is* clearer than sync but only in context: you wouldn't know 
perform was async until you read it or noticed the difference with 
performAndWait. Nothing about *perform* on its own conveys that it's 
asynchronous. 

Brandon 

Sent from my iPad

On Jun 20, 2016, at 10:05 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
>> --
>> The lack of verb in the base name bothers me. The API Design Guidelines say 
>> “methods with side-effects should read as imperative verb phrases”. You 
>> could argue that the argument label “execute” serves as the verb. However, 
>> .async and .sync are most commonly used with trailing closures where the 
>> argument label is not present.
>> 
>> This issue was brought up during the review, but I did not see it being 
>> addressed. Why not name the methods something like .executeAsync(_:) and 
>> .executeSync(_:)?
> 
> That feels a little redundant to me. It's worth remembering that the API 
> Guidelines are a means of creating clear APIs, not an end in themselves. It's 
> okay to deviate a little if you get a better result.
> 
> However, I could see us borrowing (and slightly modifying) terminology from 
> Core Data:
> 
>queue.perform { … }
>queue.performAndWait { … }
> 
> Compared to the status quo, this is clearer, a better fit for the guidelines, 
> and better at penalizing the disfavored API.
> 
>> 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:_:).
> 
> Yeah, I gave a talk about the renaming on Saturday and somebody noted that 
> `when` reads poorly here. Fortunately, `queue.perform(after: .now() + 0.5)` 
> reads pretty well too. :^)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] IUO in Swift 3.0

[David Hart via swift-evolution]

Just saw this article about IUO in Swift 3.0:

https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/

I was surprised that the IUO type still exists. From what I understood, SE-0054 

 gives a clear example that:

func f() -> Int! { return 3 } // f: () -> Int?, has IUO attribute
// ...
let x3: Int! = f() // succeeds; x3: Int? = .some(3), has IUO attribute
// ...
func g() -> Int! { return nil } // f: () -> Int?, has IUO attribute
// ...
let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute

x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 
playground show that they are still of type Int!. Did I miss something?

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

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Anton Zhilin via swift-evolution]

Although quite an obvious thing, I think import and export rules should be 
written in the proposal.

Function with `noreturn` attribute returning type T will be imported to 
Swift as a function returning empty type.

Function returning empty type will be exported from Swift as a `noreturn` 
function returning `void`.

Also, throwing and rethrowing functions returning NoReturn CAN actually 
return if they throw. It is equivalent to returning Either.

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

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

[Scott James Remnant via swift-evolution]

I’ve given this a pretty thorough couple of readings, and experimented with the 
different options in my own code.

Global functions in Swift are a rare thing, in general the language prefers not 
to have them, so where we do have them I feel it’s important to get them right. 
Addressing them is, to me, an significant improvement to Swift and the proposal 
makes good steps towards that.

I do have some comments.

It is clear to me that the purpose of functions that return details about the 
size in memory of a type, the alignment in memory of a type, and the distance 
between memory of two values of a given type, are consistently within the realm 
of dealing with types. For example, the “what is distance between memory of a 
value” makes no sense as a question, the only way to make that question make 
sense is to instead say “what is the distance between memory of two values of 
the type of a value.” Likewise “what is the size in memory of the type of a 
value,” and “what is the alignment in memory of the type of a value.”

Allowing these functions to operate on values is really just a shortcut, these 
functions should naturally operate on types.

To that end, I would prefer that the “ofValue” variations be removed, and 
SE-0096 to be preserve as-is.

The proposal brings up the issue that you cannot ask for the size of an 
existential type, but is that actually an issue? The purpose of these functions 
is to permit memory allocation, low-level memory manipulation, etc. Is there 
ever a situation where it is valid to do this on an existential type? Isn’t the 
very error here a sign that the type you’re attempting to manipulate isn’t one 
that you should be performing low-level memory manipulation for?

Scott

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

Re: [swift-evolution] [Review] SE-0102: Remove noreturn attribute and introduce an empty NoReturn type

[Anton Zhilin via swift-evolution]

>   * What is your evaluation of the proposal?

+1, but I prefer Never (or other "generic" names), because that allows to 
use this standard empty type for other purposes, such as Optional, 
Either, throws Never.

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

I think yes. The proposal suggests a nice syntactic enhancement, 
seamlessly integrating noreturn functions into the type system.

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

Unified and minimalistic way of doing things - I think yes.

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

It is equivalent to Void type in Haskell, or Nothing in Scala.

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

Between a quick reading and an in-depth study.

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

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

[Xiaodi Wu via swift-evolution]

On Tue, Jun 21, 2016 at 1:16 PM, Joe Groff  wrote:

>
> > On Jun 21, 2016, at 8:47 AM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Jun 20, 2016, at 7:07 PM, Xiaodi Wu  wrote:
> >> On Mon, Jun 20, 2016 at 8:58 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>> IIRC, some languages require zero-width joiners (though not zero-width
> spaces, which are distinct) to properly encode some of their characters.
> I'd be very leery of having Swift land on a model where identifiers can be
> used with some languages and not others; that smacks of ethnocentrism.
> >>
> >> None of those languages require zero-width characters between two Latin
> letters, or between a Latin letter and an Arabic numeral, or at the end of
> a word.  Since standard / system APIs will (barring some radical shift) use
> those code points exclusively, it's justifiable to give them some special
> attention.
> >>
> >> Although the practical implementation may need to be more limited in
> scope, the general principle doesn't need to privilege Latin letters and
> Arabic numerals. If, in any context, the presence or absence of a
> zero-width glyph cannot possibly be distinguished by a human reading the
> text, then the compiler should also be indifferent to its presence or
> absence (or, alternatively, its presence should be a compile-time error).
> >
> > Sure, that's obvious.  Jordan was observing that the simplest way to
> enforce that, banning such characters from identifiers completely, would
> still interfere with some languages, and I was pointing out that just doing
> enough to protect English would get most of the practical value because it
> would protect every use of the system and standard library.  A program
> would then only become attackable in this specific way for its own
> identifiers using non-Latin characters.
> >
> > All that said, I'm not convinced that this is worthwhile; the
> identifier-similarity problem in Unicode is much broader than just
> invisible characters.  In fact, Swift still doesn't canonicalize
> identifiers, so canonically equivalent compositions of the same glyph will
> actually produce different names.  So unless we're going to fix that and
> then ban all sorts of things that are known to generally be represented
> with a confusable glyph in a typical fixed-width font (like the
> mathematical alphabets), this is just a problem that will always exist in
> some form.
>
> Any discussion about this ought to start from UAX #31, the Unicode
> consortium's recommendations on identifiers in programming languages:
>
> http://unicode.org/reports/tr31/
>
> Section 2.3 specifically calls out the situations in which ZWJ and ZWNJ
> need to be allowed. The document also describes a stability policy for
> handling new Unicode versions, other confusability issues, and many of the
> other problems with adopting Unicode in a programming language's syntax.
>

That's a fantastic document--a very edifying read. Given Swift's robust
support for Unicode in its core libraries, it's kind of surprising to me
that identifiers aren't canonicalized at compile time. From a quick first
read, faithful adoption of UAX #31 recommendations would address most if
not all of the confusability and zero-width security issues raised in this
conversation.


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

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

[Erica Sadun via swift-evolution]

> On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Regarding the issue of existential metatypes with sizeof:
> 
> Pyry Jahkola points out one instance where the memorySize(type(of: …)) 
> workaround won't work. When the value is an existential, it's illegal to ask 
> for the size of its dynamic type: the result can't be retrieved at compile 
> time:
> 
> let i = 123
> let c: CustomStringConvertible = i
> print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an 
> argument list of type '(CustomStringCo
> This could be enabled by having sizeof and friends formally take an Any.Type 
> instead of  T.Type. (This might need some tweaking of the underlying 
> builtins to be able to open existential metatypes, but it seems 
> implementable.)

While I'm not a huge fan of Dave A's generic struct approach (for reasons 
detailed in the proposal), this could resolve one major issue I currently have 
with his alternative.

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

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

[Brent Royal-Gordon via swift-evolution]

> FWIW  `Where` is used as method also in c#
> 
> Example:
> IEnumerable numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n => 
> n);

C# Where is part of LINQ; even when called as a method instead of as special 
syntax, it still has lazy, declarative behavior.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [Discussion] func/closure parameters and tuples

[Vladimir.S via swift-evolution]

I wanted to ask if the below behavior of compiler/parser is bug or it is 
'feature' and 'by design' and we will not change this :


1. I was not expecting this will compile :

let ft1 : (Int,Int) -> Void = { x in print(x.0, x.1)}

ft1(1, 2)

the type of ft1 is definitely not the same as closure


2. The same. But this crashes compiler at compile time(if I understand 
correctly) :


let ft2 : (Int,Int) -> Void = { x in print(x) }

ft2(1, 2)

--
Unhandled conversion from exploded tuple
...
...
1.	While emitting reabstraction thunk in SIL function 
@_TTRXFo_iP___XFo_dSidSi__:0: error: unable to execute command: 
Aborted
:0: error: compile command failed due to signal (use -v to see 
invocation)

--


3. Was expecting closure will require a single argument, which is tuple; 
but it accepts even just x, y


typealias IntInt = (Int,Int)

func foo(block: (IntInt) -> Void) {
let z : IntInt = (1,2)
block(z)
}

foo { x in print(x)} // ok
foo { x, y in print(x,y)}
foo { (x, y) in print(x, y)}

I'm not sending two values to closure, I send one instance which is tuple.


Shouldn't we add consistency in Swift regarding allowed argumets of closure 
if tuple is required as parameter?

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

Re: [swift-evolution] [Pitch] Detecting and working with Optionals from Any

[Joe Groff via swift-evolution]

'as?' should already do this. If you have an Any that contains an Optional 
and cast 'any as? T', you'll get the value inside the Optional if there is one, 
or the cast will fail if the optional is nil or the type doesn't match.

-Joe

> On Jun 20, 2016, at 11:00 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> I've recently written a CoreData editor on iOS which automatically generates 
> UI based on the model which is described using classes such as 
> PrimitiveProperty, etc. Since it automatically sets the value on the entity, 
> it needs to convert the value to AnyObject in order to pass it to 
> setValue(_:forKey:), so it needs to be able to detect whether the value is 
> Optional and in case it is, either transform the non-nil value to AnyObject 
> (String -> NSString, Array -> NSArray, ...). Which is currently really hard 
> to achieve: 
> 
> var obj: IndexPath? = IndexPath()
> let anyValue: Any = obj
> anyValue.dynamicType /// Optional.Type
> 
> /// Using only anyValue, determine if it's Optional and retrieve its value if 
> /// non-nil as AnyObject.
> func isOptional(anyValue: Any) -> Bool {
> // Error: Cannot downcast from 'Any' (aka 'protocol<>') to a more 
> // optional type 'Optional<_>'
> return anyValue is Optional
> return anyValue as? Optional != nil
> ...
> }
> 
> Unless there are major reasons why it's not exposed, I'd propose introducing 
> a new function isOptional(anyValue: Any) -> Bool, which would simply call 
> Builtin.isOptional just like _isOptional does in Builtin.swift. (which pretty 
> much is just taking the current _isOptional, removing underscore and marking 
> it public).
> 
> However, this still doesn't help with the issue of retrieving the value of 
> the Optional. You now know the value in `anyValue` is Optional, but there is 
> no good way to cast it to e.g. Optional. Here we're getting into a 
> vicious cycle that Any can be an Optional which is Any.
> 
> My second part of the proposal introduces another function:
> 
> func asOptional(anyValue: Any) -> Optional?
> 
> Which will:
> - return nil if !isOptional(anyValue)
> - return a non-nil value only if `anyValue` contains in fact an Optional of 
> type T.
> 
> Usage:
> 
> if let anyObjOptional: AnyObject? = asOptional(anyValue: anyValue) {
> if let anyObj = anyObjOptional {
> // anyObj is now the actual content of the optional.
> }
> }
> 
> As a sidenote, this is my current workaround:
> 
> private protocol _XUOptional {
> var objectValue: AnyObject? { get }
> }
> 
> extension Optional: _XUOptional {
> var objectValue: AnyObject? {
> switch self {
> case .None:
> return nil
> case .Some(_):
> return self! as? AnyObject
> }
> }
> }
> 
> if let optional = anyValue as? _XUOptional {
> let object = optional.objectValue
> /// ...
> }
> 
> 
> 
> ___
> 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] Prohibit invisible characters in identifier names

[Joe Groff via swift-evolution]

> On Jun 21, 2016, at 8:47 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 20, 2016, at 7:07 PM, Xiaodi Wu  wrote:
>> On Mon, Jun 20, 2016 at 8:58 PM, John McCall via swift-evolution 
>>  wrote:
>>> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> IIRC, some languages require zero-width joiners (though not zero-width 
>>> spaces, which are distinct) to properly encode some of their characters. 
>>> I'd be very leery of having Swift land on a model where identifiers can be 
>>> used with some languages and not others; that smacks of ethnocentrism.
>> 
>> None of those languages require zero-width characters between two Latin 
>> letters, or between a Latin letter and an Arabic numeral, or at the end of a 
>> word.  Since standard / system APIs will (barring some radical shift) use 
>> those code points exclusively, it's justifiable to give them some special 
>> attention.
>> 
>> Although the practical implementation may need to be more limited in scope, 
>> the general principle doesn't need to privilege Latin letters and Arabic 
>> numerals. If, in any context, the presence or absence of a zero-width glyph 
>> cannot possibly be distinguished by a human reading the text, then the 
>> compiler should also be indifferent to its presence or absence (or, 
>> alternatively, its presence should be a compile-time error).
> 
> Sure, that's obvious.  Jordan was observing that the simplest way to enforce 
> that, banning such characters from identifiers completely, would still 
> interfere with some languages, and I was pointing out that just doing enough 
> to protect English would get most of the practical value because it would 
> protect every use of the system and standard library.  A program would then 
> only become attackable in this specific way for its own identifiers using 
> non-Latin characters.
> 
> All that said, I'm not convinced that this is worthwhile; the 
> identifier-similarity problem in Unicode is much broader than just invisible 
> characters.  In fact, Swift still doesn't canonicalize identifiers, so 
> canonically equivalent compositions of the same glyph will actually produce 
> different names.  So unless we're going to fix that and then ban all sorts of 
> things that are known to generally be represented with a confusable glyph in 
> a typical fixed-width font (like the mathematical alphabets), this is just a 
> problem that will always exist in some form.

Any discussion about this ought to start from UAX #31, the Unicode consortium's 
recommendations on identifiers in programming languages:

http://unicode.org/reports/tr31/

Section 2.3 specifically calls out the situations in which ZWJ and ZWNJ need to 
be allowed. The document also describes a stability policy for handling new 
Unicode versions, other confusability issues, and many of the other problems 
with adopting Unicode in a programming language's syntax.

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

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Ben Rimmington via swift-evolution]

Alternative names:

func infiniteLoop() -> _ { // Use an underscore instead?
while true {}
}

func infiniteLoop() -> Unreachable {
while true {}
}

func infiniteLoop() -> Unreachable {
while true {}
}

Issues:

* Clang and Swift 2.2 allow non-returning functions to have a non-void return 
type.

* [LibraryEvolution.rst] @noreturn is a versioned attribute, so how will this 
proposal affect that design?



-- Ben

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

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

[Leonardo Pessoa via swift-evolution]

On 21 June 2016 at 14:03, Chris Lattner via swift-evolution
 wrote:
> Hello Swift community,
>
> The review of "SE-0101: Rename sizeof and related functions to comply with 
> API Guidelines" begins now and runs through June 27. The proposal is 
> available here:
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md
>
> * What is your evaluation of the proposal?

After a carefull review of the proposal, I will be obligated to
decline it. After studying the proposal I ended up thinking I was
writing more code to get the data and in comparison with dynamicType
-> type(of:) it lead me to think at first the proposal would suggest
renaming size* functions to size(of*:) and so forth, which would seem
to go more towards the compared proposal (SE-0096). This idea doesn't
even made into the alternatives considered and I think it would making
reading and understanding the code much clearer than the proposed
nested function calls.

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

I'm not sure. Given the reasoning I'd say yes but given proposal
SE-0096 I'd say yes only if the new function names were to be
size(of*:), stride(of*:) and align(of*:) and thus not depending of the
nested result of type(of*:).

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

I don't think so. As I said, when I finished reading the proposal, I
ended up thinking I was writing more code in the new version and it
didn't seem very clear to me what was the size I was getting.
Moreover, it seems I'll always have to invoke these functions to the
result of type(of*:) which would be unnecessary redundant code.

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

Many languages (like C/C++, C#, D) have both sizeof and typeof and in
most these two functions have similar names and syntaxes. In this case
I believe making them different makes it hard to discover those
functions exist and relate their purpose.

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

A quick study was enough for me.

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

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

[John McCall via swift-evolution]

> On Jun 20, 2016, at 11:24 AM, Anton Zhilin via swift-evolution 
>  wrote:
> Trent Nadeau via swift-evolution  writes:
> 
>> https://github.com/tanadeau/swift-evolution/blob/make-noescape-
> default/proposals/-make-noescape-default.md
> 
> -1 from me.
> 
> 1. One must break API and ABI compatibility to add @escaping to an 
> existing function
> 2. @nonescaping case is actually quite as common as @escaping
> 3. Swift's lifetime system is not powerful enough, I'll explain below
> 
> Lazy map and filter will be marked as @escaping. Now consider the 
> following code:
> 
> func sum(_ array: [T], transform: (T) -> Int) -> Int {
>return array.lazy.map(func).reduce(0, combine: +)
> }
> 
> `transform` will be marked as @escaping, despite that `transform` never 
> actually escapes `sum`.

This is a really good point.  In the short term, we can address this with an 
unsafe
nonescaping-to-escaping construct, but we'll need a more complete answer 
eventually.

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

[swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0102: Remove @noreturn attribute and introduce an empty 
NoReturn type" begins now and runs through June 27. The proposal is available 
here:


https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md

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

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

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

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

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

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0101: Rename sizeof and related functions to comply with API 
Guidelines" begins now and runs through June 27. The proposal is available here:


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

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

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

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

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

Re: [swift-evolution] specialize a generic type in a method

[Vladimir.S via swift-evolution]

On 21.06.2016 18:59, Charlie Monroe wrote:

This may change a lot if once existentials proposal gets approved and 
implemented...



On Jun 21, 2016, at 5:20 PM, Vladimir.S  wrote:

On 20.06.2016 21:38, Charlie Monroe wrote:

Something like this should work:

protocol P1 {
associatedtype T
func foo(t: T)
func bar(t: U)
}



Seems like your suggestion will not work. Doug Gregor : "This should be 
ill-formed. "bar" isn't actually a generic function. If we want this 
behavior, we should explicitly support it with "where" clauses on 
non-generic declarations." (https://bugs.swift.org/browse/SR-1849)


Checking if there is another solution for this.



Thank you. Strange, but also can't check this code - compiler crashes on it.

IMO it will be good if we can write just

func bar(t: T & Equatable)




On Jun 20, 2016, at 8:07 PM, Vladimir.S  wrote:

Thank you for reply. Yes, seems this could be solved by extension. No other 
solutions?

But how should I be if I need such a protocol?

protocol P1 {
  associatedtype T
  func foo(t: T)
  func bar(t: T) // where T:Equatable  ??
}

I.e. I need to specify T & Equatable for bar in requirements

On 20.06.2016 20:03, Charlie Monroe wrote:

This is IMHO better solved via an extension - it even makes more sense to put 
together methods whose use is limited only to certain generics constraint:

extension Foo where I: Equatable {

func bar(i: I) {
///
}

}



On Jun 20, 2016, at 6:57 PM, Vladimir.S via swift-evolution 
 wrote:

Should we be able to specialize a generic type in a method, if that generic 
type declared in type's definition like here? :

struct Foo {
 func bar(i: I) where I: Equatable { } // should this work?
}

As I understand, for concrete instance of foo: Foo, if X is not Equatable, 
then compiler should prevent us from calling foo.bar(x)

Or, probably, the better way to express this could be :

 func bar(i: I & Equatable) { }
or
 func bar(i: Any) { }

Can't check if it possible now because my compiler crashes because of 'where 
I:Equatable' text (submitted to bugs.swift.org)
___
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] Prohibit invisible characters in identifier names

[John McCall via swift-evolution]

> On Jun 20, 2016, at 7:07 PM, Xiaodi Wu  wrote:
> On Mon, Jun 20, 2016 at 8:58 PM, John McCall via swift-evolution 
> > wrote:
>> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> IIRC, some languages require zero-width joiners (though not zero-width 
>> spaces, which are distinct) to properly encode some of their characters. I'd 
>> be very leery of having Swift land on a model where identifiers can be used 
>> with some languages and not others; that smacks of ethnocentrism.
> 
> None of those languages require zero-width characters between two Latin 
> letters, or between a Latin letter and an Arabic numeral, or at the end of a 
> word.  Since standard / system APIs will (barring some radical shift) use 
> those code points exclusively, it's justifiable to give them some special 
> attention.
> 
> Although the practical implementation may need to be more limited in scope, 
> the general principle doesn't need to privilege Latin letters and Arabic 
> numerals. If, in any context, the presence or absence of a zero-width glyph 
> cannot possibly be distinguished by a human reading the text, then the 
> compiler should also be indifferent to its presence or absence (or, 
> alternatively, its presence should be a compile-time error).

Sure, that's obvious.  Jordan was observing that the simplest way to enforce 
that, banning such characters from identifiers completely, would still 
interfere with some languages, and I was pointing out that just doing enough to 
protect English would get most of the practical value because it would protect 
every use of the system and standard library.  A program would then only become 
attackable in this specific way for its own identifiers using non-Latin 
characters.

All that said, I'm not convinced that this is worthwhile; the 
identifier-similarity problem in Unicode is much broader than just invisible 
characters.  In fact, Swift still doesn't canonicalize identifiers, so 
canonically equivalent compositions of the same glyph will actually produce 
different names.  So unless we're going to fix that and then ban all sorts of 
things that are known to generally be represented with a confusable glyph in a 
typical fixed-width font (like the mathematical alphabets), this is just a 
problem that will always exist in some form.

John.

> 
>  
> John.
> 
>> 
>> Jordan
>> 
>> 
>>> On Jun 20, 2016, at 10:51, João Pinheiro via swift-evolution 
>>> > wrote:
>>> 
>>> Recently there has been a screenshot going around Twitter about C++ 
>>> allowing zero-width spaces in variable names. Swift also suffers from this 
>>> problem which can be abused to create ambiguous, misleading, and 
>>> potentially obfuscate nefarious code.
>>> 
>>> I would like to propose a change to prohibit the use of invisible 
>>> characters in identifier names.
>>> 
>>> I'm including an example of problematic code at the bottom of this email.
>>> 
>>> Sincerely,
>>> João Pinheiro
>>> 
>>> 
>>> /* The output for this code is:
>>> A
>>> B
>>> C
>>> 1
>>> 2
>>> 3
>>> */
>>> 
>>> func test() { print("A") }
>>> func t​est() { print("B") }
>>> func te​st() { print("C") }
>>> 
>>> let abc = 1
>>> let a​bc = 2
>>> let ab​c = 3
>>> 
>>> test()
>>> t​est()
>>> te​st()
>>> 
>>> print(abc)
>>> print(a​bc)
>>> print(ab​c)
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

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

Re: [swift-evolution] [Idea] Allowing definition of custom behaviors for `as` casting

[Tony Allevato via swift-evolution]

What benefit would this provide that writing them as initializers already
doesn't? Writing the first two lines this way seems much clearer from a
call-site point of view:

let user1 = User(json: ["firstname": "Yaman", "lastname": "JAIOUCH"])
let user2 = User(string: "Yaman JAIOUCH")

That aside, placing the "as" methods on the destination type makes it look
to me like you're allowing casts *from* User *to* AnyObject/String and not
the other way around.

On Tue, Jun 21, 2016 at 8:27 AM Yaman JAIOUCH via swift-evolution <
swift-evolution@swift.org> wrote:

> What you think about having the possibility to define custom behavior
> while casting with `as` keyword ?
> It could be quite handy to use while keeping a good level of readability.
>
> Something like this :
>
> struct User {
> let firstname: String
> let lastname: String
>
> as(json: AnyObject) -> User? {
> guard let json = json as? [String: AnyObject], let firstname =
> json["firstname"] as? String, let lastname = json["lastname"] else {
> return nil
> }
>
> return User(firstname: firstname, lastname: lastname)
> }
>
> as(string: String) -> User? {
> let components = string.componentsSeparatedByString(" ")
> guard components.count == 2 else { return nil }
>
> return User(firstname: components[0], lastname: components[1])
> }
> }
>
> let user1 = ["firstname": "Yaman", "lastname": "JAIOUCH"] as? User //
> returns valid user
> let user2 = "Yaman JAIOUCH" as? User // returns valid user
> let user3 = 24 as? User // returns nil
> let user4 = NSDate() as! User // crash as usual
> ___
> 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] [Idea] Allowing definition of custom behaviors for `as` casting

[Yaman JAIOUCH via swift-evolution]

What you think about having the possibility to define custom behavior while 
casting with `as` keyword ?
It could be quite handy to use while keeping a good level of readability. 

Something like this :

struct User {
let firstname: String
let lastname: String

as(json: AnyObject) -> User? {
guard let json = json as? [String: AnyObject], let firstname = 
json["firstname"] as? String, let lastname = json["lastname"] else {
return nil
}

return User(firstname: firstname, lastname: lastname)
}

as(string: String) -> User? {
let components = string.componentsSeparatedByString(" ")
guard components.count == 2 else { return nil }

return User(firstname: components[0], lastname: components[1])
}
}

let user1 = ["firstname": "Yaman", "lastname": "JAIOUCH"] as? User // returns 
valid user
let user2 = "Yaman JAIOUCH" as? User // returns valid user
let user3 = 24 as? User // returns nil
let user4 = NSDate() as! User // crash as usual
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] specialize a generic type in a method

[Vladimir.S via swift-evolution]

On 20.06.2016 21:38, Charlie Monroe wrote:

Something like this should work:

protocol P1 {
associatedtype T
func foo(t: T)
func bar(t: U)
}



Thank you. Strange, but also can't check this code - compiler crashes on it.

IMO it will be good if we can write just

func bar(t: T & Equatable)




On Jun 20, 2016, at 8:07 PM, Vladimir.S  wrote:

Thank you for reply. Yes, seems this could be solved by extension. No other 
solutions?

But how should I be if I need such a protocol?

protocol P1 {
   associatedtype T
   func foo(t: T)
   func bar(t: T) // where T:Equatable  ??
}

I.e. I need to specify T & Equatable for bar in requirements

On 20.06.2016 20:03, Charlie Monroe wrote:

This is IMHO better solved via an extension - it even makes more sense to put 
together methods whose use is limited only to certain generics constraint:

extension Foo where I: Equatable {

func bar(i: I) {
///
}

}



On Jun 20, 2016, at 6:57 PM, Vladimir.S via swift-evolution 
 wrote:

Should we be able to specialize a generic type in a method, if that generic 
type declared in type's definition like here? :

struct Foo {
  func bar(i: I) where I: Equatable { } // should this work?
}

As I understand, for concrete instance of foo: Foo, if X is not Equatable, 
then compiler should prevent us from calling foo.bar(x)

Or, probably, the better way to express this could be :

  func bar(i: I & Equatable) { }
or
  func bar(i: Any) { }

Can't check if it possible now because my compiler crashes because of 'where 
I:Equatable' text (submitted to bugs.swift.org)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution







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

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

[Vladimir.S via swift-evolution]

On 21.06.2016 0:56, Brent Royal-Gordon via swift-evolution wrote:

And as I said, if we feel `filter` is unsalvageable, the alternate
Smalltalk-lineage `select` is clearer.


Than “where?”


No, than "filter". "filter" is the most common name, but "select" is


Why not x.select(where: isPrime) ? IMO this is more clear than
x.select(filter: isPrime) and looks similar to `where` in other parts of 
language.



also fairly popular, and doesn't have the same ambiguity issues as
"filter". "where" is slightly clearer than "filter", but it finds little
precedent in other languages (the only other use I'm aware of is in SQL
and LINQ, which are declarative), ignores the normal grammar rules for a


FWIW  `Where` is used as method also in c#

Example:
IEnumerable numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n 
=> n);



method ("where" is an adverb, not a noun or verb), and is already a
language keyword which has been overloaded with several slightly
different semantics, including list filtering in the `for` loop.


– There's very significant brevity issues here, e.g.
hyperbolicArcTangent() vs atanh().


Sure, but `mappingAndFlattening(to:)` would have brevity issues as
well. (You didn't think the API Guidelines merely meant "add -ed or
-ing to everything", did you?)


That would, IMO, be:

x.flatMapping(fourCopies)


Why? If we're leaving the terms of art behind, we probably ought to
consider that the base name `flatMap` is rather opaque to new users;
I've seen people in my NSCoder group struggle with it. For that matter,
`map` and `reduce` aren't the best names either.

I can understand wanting to keep terms of art even if they're a little
opaque. I can understand wanting to invent new, clear terms. I cannot
understand wanting to make minor cosmetic changes to the terms of art
while still keeping the parts that make them opaque. You lose many of
the benefits of a term of art *and* most of the benefits of a new term.

It's a bit like painting a single wall in a room: You can match the
existing color exactly and have it look seamless, or you can choose an
obviously different color and make a statement, but choosing a slightly
different shade of the existing color does neither of those things.


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

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

[Vladimir.S via swift-evolution]

On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote:



On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution
 wrote:


Perhaps stupid but: why was Swift designed to accept most Unicode
characters in identifier names? Wouldn’t it be simpler to go back to
a model where only standard ascii characters are accepted in
identifier names?


I assume it has something to do with the fact that 94.6% of the
world's population speak a first language which is not English. That
outweighs the inconvenience for Anglo developers, IMHO.


Yes, but the SDKs (frameworks, system libraries) are all in English,
including Swift standard library. I remember a few languages attempting
localized versions for kids to study better, failing terribly because
you learned something that had a very very limited use.


Support Charlie's opinion. For me (as non-native English speaker) non-ASCII 
characters in identifiers had no sense, even when I start to tech the 
programming when I was a child. Expressions composed from identifiers 
written in my native language is not near correct sentences.


Even more, we still have all other parts of language in English - 
for-while-guard-let-var-func etc..




When it comes to maintaining code, using localized identifier names is a
bad practice since anyone outside that country coming to the code can't
really use it. I personally can't imagine coming to maintain Swift code
with identifiers in Chinese, Japanese, Arabic, ...

While the feature of non-ASCII characters being allowed as identifiers
(which was held up high with Apple giving emoji examples) may seem cool,
I can only see this helpful in the future, given a different keyboard
layout (as someone has pointed out some time ago here), to introduce
one-character operators that would be otherwise impossible. But if
someone came to me with a code where a variable would be an emoji of a
dog, he'd get fired on the spot.


Yes, but I don't believe Apple will accept limiting of character set for 
identifiers to ASCII *after* these presentations with emoji of a dog ;-)




I'd personally vote to keep the zero-width-joiner characters forbidden
within the code outside of string literals (where they may make sense).
I agree that this can be easily solved by linters, but: I think this
particular set of characters should be restricted by the language
itself, since it's something easily omittable during code review and
given the upcoming package manager, this can lead to a hard-to-find
malware being distributed among developers who include these packages
within their projects - since you usually do not run a linter on a 3rd
party code.


I also think the main problem that could be caused by such tricks with 
zero-width-joiner or right-to-left-markers is injecting some malware code 
into sources in github, in package manager *or* even just in  code snippet 
on web page(so you copy-pasted it to your source). Right now I don't know 
exact method to implement such malware code, but I believe this 
vulnerability could be used some day.


Btw, regarding the package manager. Will we have any protection from 
Typosquatting ? 
http://incolumitas.com/2016/06/08/typosquatting-package-managers/#typosquatting-package-managers




As for the confusables - this depends a lot on the rendering and what
font you have set. I've tried  훎 → v with current Xcode and it looks
really different, mostly when you use a fixed-space font which usually
doesn't have non-ASCII characters which are then rendered using a
different font, making the distinction easy to spot.


In Russian we have these chars :
у к е г х а р о с ь
which are similar to english:
y k e r x a p o c b

So you most likely can't differ `рос` and `poc` , `хае` and `xae` etc

I don't think compiler should somehow decide if one non-English letter is 
looks like another English letter. But don't see any other method to 
protect myself other than using lints/checking tools for 3rd party code also.






Honestly, this seems to me like a concern for linters and security
auditing tools, not for the compiler. Swift identifiers are
case-sensitive; I see no reason they shouldn't be script-sensitive or
zero-width-joiner-sensitive. (Though basic Unicode normalization seems
like a good idea, since differently-normalized strings are `==`
anyway.)

-- Brent Royal-Gordon Architechies

___ swift-evolution
mailing list swift-evolution@swift.org
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