Re: [swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

[Chris Lattner via swift-evolution]

> On Jun 18, 2016, at 10:14 PM, Brent Royal-Gordon  
> wrote:
> 
>> swift-evolution isn’t the right process for proposing changes to Apple 
>> frameworks, but you raise good points, and I really value the feedback.  
>> 
>> If you file a radar with bugreporter.apple.com and let us know the radar #, 
>> we will be happy to escalate this with the team in question.  Thank you!
> 
> Oh, I've got a list of radars to file that's as long as my arm.
> 
> To clarify: Radar is the best place to file imperfect APIs in random 
> frameworks. Where is the best place to bring up:
> 
> 1. Migrator issues?

swift-users or swift-dev (if you’re trying to improve the migrator and have 
questions about it).

> 
> 2. Foundation issues (with the new value types)?
> 3. Foundation issues caused by evolution-proposed features behaving in ways 
> that are problematic for certain uses Foundation puts them to? (Specifically, 
> symbols marked with NSNotificationName get imported as constants on 
> Notification.Name by default due to the design of SE-0033; you'd probably 
> prefer they be prefix-matched and inserted into the type they belong to.)

I’d ask the folks on swift-corelibs-dev what they prefer.

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

Re: [swift-evolution] libdispatch renaming feedback

[Matt Wright via swift-evolution]

> On Jun 15, 2016, at 11:14 AM, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> Here’s some feedback after translating some Dispatch-heavy code for the new 
> Dispatch module.
> 
> 1. I like the result. Thanks for the effort!
> 
> 2. Omissions
> 
> - Can't initialize a new queue or obtain a global queue using a DispatchQoS 
> instance. [SR-1770]
> 
> One thing I have previously done was the following:
> 
> let anotherQueue: dispatch_queue_t = 
> let matchedQueue = 
> dispatch_get_global_queue(dispatch_queue_get_qos_class(anotherQueue, nil), 0)
> 
> There is no longer a way to do this.

Thanks for the feedback. I’ll take a look at getting something in that can do 
this.

> 
> Given that all the methods that enqueue blocks for execution have DispatchQoS 
> parameters, this must be an oversight (I didn’t notice it when reviewing the 
> proposal).
> 
> The following should exist:
> extension DispatchQueue {
>  init(qos: DispatchQoS, attributes: DispatchQueueAttributes)
>  class func global(qos: DispatchQoS, attributes: 
> DispatchQueue.GlobalAttributes) -> DispatchQueue
> }
> extension DispatchQueueAttributes {
>  // replacing dispatch_queue_attr_make_with_qos_class:
>  init(qos: DispatchQoS, attributes: DispatchQueueAttributes)
> }
> 
> - DispatchTime should be Comparable [SR-1771]

I’m curious why you need to compare DispatchTime values but if you can do this 
via rawValue it seems like it should be Comparable, even if I can’t bring to 
mind an immediately useful use-case.

> - qos_class_self() and qos_class_main() do not translate to DispatchQoS 
> [SR-1769]

SR-1769 has already been brought to my attention! I think that more or less 
covers all the comments you had about qos_class_t <-> DispatchQoS.

> 
> Since qos_class_t presumably isn’t disappearing (it’s used by Darwin 
> pthreads), the following are needed:
> 
> extension DispatchQoS {
>  static func current() -> DispatchQoS // equivalent to qos_class_self()
>  static var main: DispatchQoS // equivalent to qos_class_main()
>  init(qos: qos_class_t) // perhaps with a relativePriority?
> }
> 
> 3. Oddities
> 
> - DispatchQueueAttributes is top-level, while DispatchQueue.GlobalAttributes 
> is not.

I can’t immediately recall why I made this top-level but there was a technical 
problem with moving it into DispatchQueue. Perhaps that no longer exist, I’ll 
try again.

> 
> DispatchQueue.Attributes would look better to my eyes.
> 
> - Similarly, DispatchWorkItemFlags is top-level; it could perhaps be 
> DispatchWorkItem.Flags
> 
> - QualityOfService and DispatchQoS.QoSClass seem redundant. One of these 
> could probably go.
> (QualityOfService is defined under Foundation.NSObjCRuntime and is an enum 
> with rawValue)

There are backwards compatibility issues with combining 
Foundation.QualityOfService and DispatchQoS.QoSClass. For now they need to 
remain separate.

> 
> 
> 4. Bad translations or fixits
> 
> - dispatch_get_global_queue(qos_class_self(), 0) gets an invalid suggestion 
> (then again there is a void there, as noted above)
> 
> - dispatch_block_create does not have a fixit pointing to the new 
> DispatchWorkItem type.
> 
> 
> Cheers,
> Guillaume Lessard
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

[Brent Royal-Gordon via swift-evolution]

> swift-evolution isn’t the right process for proposing changes to Apple 
> frameworks, but you raise good points, and I really value the feedback.  
> 
> If you file a radar with bugreporter.apple.com and let us know the radar #, 
> we will be happy to escalate this with the team in question.  Thank you!

Oh, I've got a list of radars to file that's as long as my arm.

To clarify: Radar is the best place to file imperfect APIs in random 
frameworks. Where is the best place to bring up:

1. Migrator issues?

2. Foundation issues (with the new value types)?

3. Foundation issues caused by evolution-proposed features behaving in ways 
that are problematic for certain uses Foundation puts them to? (Specifically, 
symbols marked with NSNotificationName get imported as constants on 
Notification.Name by default due to the design of SE-0033; you'd probably 
prefer they be prefix-matched and inserted into the type they belong to.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

[Chris Lattner via swift-evolution]

> On Jun 10, 2016, at 5:47 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> Hello swift-evolutioneers,
>> 
>> Here's an idea. It's technically additive, but it's small and I think it 
>> fits in well with Swift 3's goals, one of which is to establish API 
>> conventions.
>> 
>> Right now, you can declare a function, type member, etc and mark it using 
>> "@available(*, unavailable, renamed:"someNewName()")". Doing so causes a 
>> compile-time error if the user tries to use that member, and if you provide 
>> the new name a fix-it is even generated telling you to use the new name.
>> 
>> However, you can (and still need to) provide an implementation (e.g. 
>> function body). You can just stick a fatalError() inside and be done with 
>> it, but my question is, is an impl even necessary?
>> 
>> My pitch is very simple: the declaration of any member marked with 
>> @available(*, unavailable), or in other words marked as unavailable 
>> regardless of platform or version, should be allowed to omit the 
>> implementation.
>> 
>> So, instead of:
>> 
>> @available(*, unavailable, renamed:"someNewAPI()")
>> public func someOldAPI() -> Int { fatalError() }
>> 
>> You can just have:
>> 
>> @available(*, unavailable, renamed:"someNewAPI()")
>> public func someOldAPI() -> Int
>> 
>> The intent is, in my opinion, clearer for the latter and it feels less 
>> kludgy.
>> 
>> What do people think? Are there any potential barriers (implementation or 
>> semantics) that would preclude this?
> 
> I actually just consider it a bug that you're require to implement an 
> always-unavailable function.  We can take it through evolution anyway, though.

I agree with John on both parts: it’s a bug, but considering it in evolution 
makes sense.

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

Re: [swift-evolution] Why hard-code octet-sized bytes?

[Chris Lattner via swift-evolution]

> On Jun 17, 2016, at 1:01 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> When I first looked into Swift, I noticed that the base type was called 
> “UInt8” (and “Int8”) and not something like “Byte.”  I know modern computers 
> have followed the bog standard 8/16/32(/64) architecture for decades, but why 
> hard code it into the language/library?  Why should 36-bit processors with 
> 9-bit bytes, or processors that start at 16 bits, be excluded right off the 
> bat?  Did you guys see a problem with how (Objective-)C(++) had to define its 
> base types in a mushy way to accommodate the possibility non-octet bytes?

Given that there are no 9-bit byte targets supported by Swift (or LLVM), it 
would be impossible to test that configuration, and it is well known that 
untested code doesn’t work.  As such, introducing a Byte type which is 
potentially not 8 bits in size would only add cognitive overload.  Any promised 
portability benefit would simply mislead people.

-Chris 

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

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

[Chris Lattner via swift-evolution]

> On Jun 16, 2016, at 12:44 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> Sorry, didn't have time to actually submit the proposal, but it at least gave 
> me some time to think it through a few more times.
> 
> After reconsiderations, I suggest the following:
> 
> - deprecation of interpolation of optionals.
> - extending the Optional type by:
>   - var detailedDescription: String - which will return the same value as 
> until now: "nil" for nil and "Optional(value)" for .some(_). This is due to 
> .description and .debugDescription's documentation discouraging direct 
> invocation.
> 
>   - func descriptionWithDefaultValue(_ defaultValue: String = "nil") -> 
> String - which would return either the description of the value, or 
> `defaultValue`.
> 
> So, when the compiler runs into interpolation of an Optional, it issues a 
> warning with a fix-it, that by default calls .descriptionWithDefaultValue() 
> on the optional.

I think that this is overcomplicating the issue.  I’d suggest that someone just 
implement a simple compiler patch (which doesn’t need an evolution proposal):

1. Produce a warning when a string interpolation includes a 
non-redundantly-parenthesized optional, saying that this is probably a bug.
2. Attach two notes (with fixits) to the warning:
2a. a note that adds redundant parens around the parameter, silencing the 
warning.
2b. a note that fixits the issue with a “!” or "?? <#placeholder#>"

I agree that this should be fixed.

-Chris

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

Re: [swift-evolution] [Pitch] remove(at: Set)

[Dmitri Gribenko via swift-evolution]

On Sat, Jun 18, 2016 at 9:09 PM, Karl via swift-evolution
 wrote:
> So like most good pitches, this one comes about because of a bug I recently 
> fixed which seems common and subtle enough that I think it would be nice to 
> include in the standard library.
>
> Removing a collection of elements at once from a collection. You might want 
> to do this in some kind of advanced filtering code. In my case, our code was 
> merging adjacent elements in-place, and storing a list of indexes that were 
> no longer required because they were now part of a merged element, and then 
> we cleaned up the duplicates by removing those indexes.
>
> A näive implementation might look like this:
>
> for index in indexesToRemove {
> myArray.remove(at: index)
> }
>
> However, as the array is mutated, those indexes won’t make sense any more. 
> You’ll end up with invalid results - for example, if you have the array 
> [0,1,2] and indexesToRemove is [0,1], your resulting array will actually be 
> [1] (not [2], as expected). Actually removing a batch of indexes is subtly 
> more complex. Here’s my generic implementation:
>
> extension RangeReplaceableCollection where Index:Hashable, 
> Self:BidirectionalIndexable {
>
> mutating func remove(at indexes: Set) {

Hi Karl,

This sounds like a good idea to me.  You can make this method even
more useful by making it generic over collections of appropriate
indices.  Then you can drop the Hashable requirement for indices.

> var removed : IndexDistance = 0
> for idx in indexes.sorted() {
> remove(at: index(idx, offsetBy: -removed))
> removed = removed.advanced(by: 1)

This implementation will not work correctly for all collections, since
removing an element at the beginning of the collection invalidates the
indices pointing at the tail.  Adjusting the index by "-removed" won't
help, the indices are invalidated already.  (Consider what happens in
a UnicodeScalar String view where indices have to jump over variable
number of code units in the underlying storage.)

You can make it correct (and work even faster, in O(n)) by walking
from the start, and moving the elements into place, and then
truncating the collection.  You will need to require
MutableCollection.

You can make a variant that works for collections that are not
MutableCollections, but then the runtime will be O(n^2).  You will
need to remove elements one by one walking from the end and shifting
the tail of the collection.

Dmitri

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

Re: [swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

[Chris Lattner via swift-evolution]

> On Jun 16, 2016, at 3:57 PM, David Hart via swift-evolution 
>  wrote:
> 
> I’ve only started using the transformed APIs from Apple frameworks that were 
> auto-modified and I’ve found a few cases where the automatic translation 
> doesn’t seem to follow the Swift Design Guidelines. I don’t know how much can 
> be fixed manually, but if it can, it would be forth congregating as a 
> community to prepare a massive list of proportions before the new APIs are 
> set in stone in the fall.

Hi David,

swift-evolution isn’t the right process for proposing changes to Apple 
frameworks, but you raise good points, and I really value the feedback.  

If you file a radar with bugreporter.apple.com  
and let us know the radar #, we will be happy to escalate this with the team in 
question.  Thank you!

-Chris

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

Re: [swift-evolution] generic typealias inside generic type

[Chris Lattner via swift-evolution]

> On Jun 17, 2016, at 11:06 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Please consider this code:
> 
> struct Foo {
>typealias Group = (key:Key, group:[Value])
> 
>func bar(u: U, v: V) -> Foo> {
>return Foo>()
>}
> }
> 
> It will not compile:
> cannot specialize non-generic type '(key: Key, group: [Value])'
> 
> But this will work as expected:
> 
> typealias Group = (key:Key, group:[Value])
> 
> struct Foo {
>func bar(u: U, v: V) -> Foo> {
>return Foo>()
>}
> }
> 
> Shouldn't we be able to work with Group typealias inside Foo without 
> problems as it has no any relationship to generic type T ? Or I'm missing 
> something?

Yes, this should work, it is a bug in the compiler.

-Chris

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

[swift-evolution] [Pitch] remove(at: Set)

[Karl via swift-evolution]

So like most good pitches, this one comes about because of a bug I recently 
fixed which seems common and subtle enough that I think it would be nice to 
include in the standard library.

Removing a collection of elements at once from a collection. You might want to 
do this in some kind of advanced filtering code. In my case, our code was 
merging adjacent elements in-place, and storing a list of indexes that were no 
longer required because they were now part of a merged element, and then we 
cleaned up the duplicates by removing those indexes.

A näive implementation might look like this:

for index in indexesToRemove {
myArray.remove(at: index)
}

However, as the array is mutated, those indexes won’t make sense any more. 
You’ll end up with invalid results - for example, if you have the array [0,1,2] 
and indexesToRemove is [0,1], your resulting array will actually be [1] (not 
[2], as expected). Actually removing a batch of indexes is subtly more complex. 
Here’s my generic implementation:

extension RangeReplaceableCollection where Index:Hashable, 
Self:BidirectionalIndexable {

mutating func remove(at indexes: Set) {
var removed : IndexDistance = 0
for idx in indexes.sorted() {
remove(at: index(idx, offsetBy: -removed))
removed = removed.advanced(by: 1)
}
}
}

I think it would be nice to have this in the standard library. I think it’s a 
reasonably common problem and it’d be nice to make it easier for people.

Karl


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

Re: [swift-evolution] [Pitch] String prefix operator

[Gwynne Raskind via swift-evolution]

Hi everyone, this is my first post to swift-evolution, so I apologize in 
advance if I violate any rules of list etiquette, and thanks for reading!

> On Jun 18, 2016, at 17:44, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Jun 18, 2016 at 4:50 PM, Michael Peternell via swift-evolution 
> > wrote:
> 
> > Am 17.06.2016 um 07:45 schrieb Charlie Monroe via swift-evolution 
> > >:
> >
> > Motivational example:
> >
> > var urlString = self.urlString
> > if urlString.hasPrefix("//") {
> >   urlString = "http:" + urlString // urlString needs to be typed twice
> > }
> >
> > While there is currently an easy way to append string using +=, there is no 
> > shortcut for prefixing a string. What I propose is adding a =+ operator for 
> > prefixing the string:
> >
> > urlString =+ "http:"
> >
> > Would anyone else find it useful?
> 
> No. What I would find useful though, is to recognize that addition is not 
> string concatenation. There is a strong convention in mathematics that the 
> "+" symbol should only be used for operations that are commutative. String 
> concatenation is not commutative. (There are more conventions regarding "+", 
> but all of them are respected by numbers, vectors, complex numbers, 
> quaternions, or matrices - just to name a few.)
> 
> I would like to have a different operator for string concatenation.
> 
> I don't see how this would measurably improve Swift code. IIUC, much of the 
> problem with `+` and strings arises from implicit conversions that don't 
> happen in Swift. It's not even possible to write a generic algorithm that 
> accidentally confuses arithmetic `+` and string concatenation `+`, since you 
> would have to retroactively conform strings and numeric types to a 
> nonsensical protocol of your own making.

I agree there’s no issue with type confusion, but I do agree with Michael that 
there’s a conceptual issue with using + for strings. I would certainly favor 
something that makes it more obvious visually that strings are the operands. An 
extreme example of where it might be a problem would be a construct like `"2" + 
"3"` (freely admitted to be a pathological case) - I’d have to look twice to 
recognize that the result was "23", not "5". My personal favorite for alternate 
string concat operators is Lua’s ".." syntax, though there are other options as 
well, especially in Swift. (Speaking for myself, I’d much rather be reminded of 
Lua than PHP’s single-dot or VB’s ampersand :).

That having been said, the way things are now works and I don’t see the 
conceptual confusion being an immediate issue; if there are other arguments in 
favor of changing it, I’d speak out more strongly for it, but taking it as an 
entirely independent proposal, I'd wonder if it’s worth the break with previous 
versions in the near future.

With respect to the original suggestion for an operator to prefix a string, I 
don’t see that as useful enough in the general case to warrant being in the 
stdlib (relative to how much authority I have to say anything about the stdlib 
at all! :), especially given that it’s very easy to write your own. I agree 
that writing a variable name twice is annoying, but given Swift’s 
predisposition towards let vs. var variables wherever possible, it shouldn’t be 
that common an issue in my (thus far somewhat limited) experience.

> Maybe "~~" or "++"? Now that the prefix and postfix operators for numbers 
> ("++" and "--") are removed from Swift 3, "++" could be used for string 
> concatenation.
> 
> -Michael

-- Gwynne Raskind

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

Re: [swift-evolution] Allow a typealias to be named after the corresponding type

[Tim Vermeulen via swift-evolution]

This doesn’t work if `DataStructureKit` and `BinarySearchTree` have the same 
name.

> > public struct BinarySearchTree{
> > typealias Node = Node
> > var root: Node?
> > }
> > 
> > private class Node{ }
> > 
> > This code currently doesn’t compile because the Node typealias circularly 
> > references itself. I’d like this syntax to just work, because this are the 
> > alternatives:
> > - rename the typealias to something like `TheNode`
> > - rename the Node class
> > - don’t use a typealias at all
> - fully qualify the class name with the name of the module:
> 
> typealias Node = DataStructureKit.Node
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] String prefix operator

[Xiaodi Wu via swift-evolution]

On Sat, Jun 18, 2016 at 4:50 PM, Michael Peternell via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Am 17.06.2016 um 07:45 schrieb Charlie Monroe via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Motivational example:
> >
> > var urlString = self.urlString
> > if urlString.hasPrefix("//") {
> >   urlString = "http:" + urlString // urlString needs to be typed
> twice
> > }
> >
> > While there is currently an easy way to append string using +=, there is
> no shortcut for prefixing a string. What I propose is adding a =+ operator
> for prefixing the string:
> >
> > urlString =+ "http:"
> >
> > Would anyone else find it useful?
>
> No. What I would find useful though, is to recognize that addition is not
> string concatenation. There is a strong convention in mathematics that the
> "+" symbol should only be used for operations that are commutative. String
> concatenation is not commutative. (There are more conventions regarding
> "+", but all of them are respected by numbers, vectors, complex numbers,
> quaternions, or matrices - just to name a few.)
>
> I would like to have a different operator for string concatenation.


I don't see how this would measurably improve Swift code. IIUC, much of the
problem with `+` and strings arises from implicit conversions that don't
happen in Swift. It's not even possible to write a generic algorithm that
accidentally confuses arithmetic `+` and string concatenation `+`, since
you would have to retroactively conform strings and numeric types to a
nonsensical protocol of your own making.


> Maybe "~~" or "++"? Now that the prefix and postfix operators for numbers
> ("++" and "--") are removed from Swift 3, "++" could be used for string
> concatenation.
>
> -Michael
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] String prefix operator

[Michael Peternell via swift-evolution]

> Am 17.06.2016 um 07:45 schrieb Charlie Monroe via swift-evolution 
> :
> 
> Motivational example:
> 
> var urlString = self.urlString
> if urlString.hasPrefix("//") {
>   urlString = "http:" + urlString // urlString needs to be typed twice
> }
> 
> While there is currently an easy way to append string using +=, there is no 
> shortcut for prefixing a string. What I propose is adding a =+ operator for 
> prefixing the string:
> 
> urlString =+ "http:"
> 
> Would anyone else find it useful?

No. What I would find useful though, is to recognize that addition is not 
string concatenation. There is a strong convention in mathematics that the "+" 
symbol should only be used for operations that are commutative. String 
concatenation is not commutative. (There are more conventions regarding "+", 
but all of them are respected by numbers, vectors, complex numbers, 
quaternions, or matrices - just to name a few.)

I would like to have a different operator for string concatenation. Maybe "~~" 
or "++"? Now that the prefix and postfix operators for numbers ("++" and "--") 
are removed from Swift 3, "++" could be used for string concatenation.

-Michael

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

Re: [swift-evolution] Bitshift operators

[Ben Rimmington via swift-evolution]

> On 18 Jun 2016, at 02:25, Dave Abrahams via swift-evolution 
>  wrote:
> 
> on Fri Jun 17 2016, Ben Rimmington  wrote:
> 
>> 
>> 
>>> **In initializers that perform full-width type conversions, omit the
>>> first argument label**, e.g. `Int64(someUInt32)`
>> 
>> OptionSet could add `init(_ rawValue: RawValue)` to reduce boilerplate:
>> 
>>  struct FooOptions: OptionSet {
>>  let rawValue: Int
>> 
>>  static let bar = Self(0b01)
>>  static let baz = Self(0b10)
>>  }
> 
> Great idea; please submit a proposal!
> 
> -- 
> -Dave

On second thoughts, perhaps the current design is better. OptionSet changes the 
failable initializer (inherited from RawRepresentable) into a *nonfailable* 
initializer. But if we used `init(_ rawValue: RawValue)` in OptionSet, it would 
also still have the failable initializer (which could maybe have a default 
implementation).

The original FooOptions example is missing some required boilerplate: 
`init(rawValue: Int) { self.rawValue = rawValue }`. In the future, a *macro* 
could be used to hide the RawRepresentable requirements of option sets, making 
them as easy to read/write as enum cases.

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

Re: [swift-evolution] Suppress unused result warnings on try? if attempted statement does not return

[Alex Hoppen via swift-evolution]

I discussed the same issue in a WWDC lab with Doug yesterday and we came to the 
conclusion that warnings about unused return values of type Optional were 
a bug. The basic line of argumentation was that if you have

class Foo {
  func bar() {}
}

then

foo?.bar() returns Optional but does not warn about an unused result, 
which is totally expected behaviour.

It feels inconsistent that this behaviour differs if the return value of 
Optional is used in a more complicated expression, e.g.

true ? foo?.bar() : foo?.bar()

Hence we decided that Optional simply shouldn't generate any warnings 
about unused results. Note that this does not prevent the user of such an API 
to still check the result, if he wants to do so.

Implementation of this change is pending in this PR: 
https://github.com/apple/swift/pull/3057 
.

– Alex


> On 17 Jun 2016, at 18:26, James Froggatt via swift-evolution 
>  wrote:
> 
> More generally, this is the issue of whether the automatic discardability of 
> Void should be extended to Optional. This could also apply to the 
> result of optional chaining.
> 
> EG:
> observer?.update() //returns ()?
> 
> compared to:
> if let unwrapped = observer {
>unwrapped.update() //returns ()
> }
> 
> Since ()? (or Void?) is almost certainly a side-effect of optional chaining 
> of some form, I'd be in favour of this extension to the rule.
> 
> 
> 
> As an interesting side note, the counter-point to this change I can think of 
> is one of symmetry, potentially relevant in some high-level generic code. 
> Failable functions often follow the pattern of returning an Optional, which 
> is nil on failure. Extending this rule to, for example, an in-place load() 
> function, one may consider returning ()? to indicate whether the function was 
> successful. This would be deliberate use of Optional<()>, and so it would 
> make sense not to make this particular result discardable, which would be 
> impossible with this change.
> 
> The precedent of languages without optionals and a real Void/Unit type has 
> been established, which is to return a Bool value to indicate success, and if 
> this weren't such a fundamental expectation, it's arguable ()? may actually 
> be clearer in these cases: load() -> Bool could be read as a function which 
> loads a Bool value, whereas load() -> ()? is unambiguous.
> 
> While this is unlikely to become an established convention, I love that Swift 
> is able to make such ideas possible. :)
> Just the simple things which do away with implementation-driven corner cases 
> in favour of a reliable, clear set of rules, really make the language more 
> powerful.
> 
>  Begin Message  
> Group: gmane.comp.lang.swift.evolution 
> MsgID:  
> 
> I propose that the compiler warnings for unused results are removed from try? 
> if the statement being ‘tried’ does not return itself. This is inline with 
> how try works and although try? does have a possible return value itself 
> (nil) the warning isn’t adding/helping any if the result is either going to 
> be nil or void.
> 
> When try? is used in this way, it is essentially the caller saying they don’t 
> care if the operation fails and any consequences of that failure will be 
> handled later on.
> 
> I have a slightly contrived example here on gist of where this could be 
> useful https://gist.github.com/joncottonskyuk/abc6caad8be137193d4e1e58cc8d2e06
> 
> basically, in the person model, I don’t always care if the emailAddress is 
> set, but in some cases I do, to differentiate between the two use cases, the 
> caller can choose to use either try when they do care and want to handle the 
> specific error, or try? if they don’t care about the failure and just want to 
> carry on with the usual execution path.
> 
> The alternative is to just leave this as it is and the caller must then use _ 
> = try? … to suppress the warnings. However, whilst _ = is very useful for 
> suppressing this warning in most cases, as it shows intent for future 
> maintainers of the code, in this case I don’t think it really adds any value. 
> If the statement being attempted does not return itself then you are left 
> with no choice but to assign to nothing to suppress the warning as opposed to 
> assigning to some local reference and then just throwing that away.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> - End Message - 
> 
> 
> 
> From James F
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Bitshift operators

[Dave Abrahams via swift-evolution]

on Fri Jun 17 2016, Ben Rimmington  wrote:

> 
>
>> **In initializers that perform full-width type conversions, omit the
>> first argument label**, e.g. `Int64(someUInt32)`
>
> OptionSet could add `init(_ rawValue: RawValue)` to reduce boilerplate:
>
>   struct FooOptions: OptionSet {
>   let rawValue: Int
>
>   static let bar = Self(0b01)
>   static let baz = Self(0b10)
>   }

Great idea; please submit a proposal!

-- 
-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-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Thorsten Seitz via swift-evolution]

> Am 17.06.2016 um 16:11 schrieb Douglas Gregor :
> 
> 
>> On Jun 16, 2016, at 9:46 AM, Thorsten Seitz via swift-evolution 
>> > wrote:
>> 
>>> 
>>> Am 16.06.2016 um 17:36 schrieb Paul Cantrell >> >:
>>> 
 On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution 
 > wrote:
 
 Protocols are a mechanism for deriving types from each other whereas 
 generics are a way to parameterize types. My point was that Swift's other 
 way to parameterize types, namely by associated types, is very similar to 
 generics with wildcards when looking a the existentials of such protocols.
>>> 
>>> This has been a point of confusion for me as well. I keep hearing that 
>>> associated types are different from generic protocols, but this seems like 
>>> a distinction without a difference.
>>> 
>>> Suppose Swift allowed generic protocols. How would a hypothetical 
>>> Collection be different in practice from the proposed existential 
>>> Any?
>>> 
>>> Yes, in the realm of type theory and compiler internals they might 
>>> represented differently, sure. But in practice, in terms of what code can 
>>> actually do? I know of only two differences:
>>> 
>>> 1. A type can only conform to any given protocol with one set of type 
>>> parameters. (Nothing can be both Collection and Collection.)
>>> 
>>> 2. When a type conforms to Collection, it declares “associatedtype Foo” 
>>> instead of “: Collection”, and Foo can be inferred by the compiler in 
>>> some circumstances. That’s handy, but it’s a syntactic difference.
>> 
>> That syntactic difference is *very* handy IMO for the following reason: with 
>> generics I have to repeat all types over and over again which gets ugly when 
>> I have levels of nesting where type parameters are constrained by other 
>> generics, which requires adding their parameters to the parameter list. 
>> Essentially the nested parameters have to be fully flattened because each 
>> type parameter has to be explicitly specified.
>> 
>> I’ll try to show that with a simplified example:
>> 
>> // with associated types
>> 
>> protocol Edge {
>> associatedtype VertexType
>> 
>> var source: VertexType { get }
>> var target: VertexType { get }
>> }
>> 
>> protocol Graph {
>> associatedtype EdgeType : Edge
>> 
>> var vertices: [EdgeType.VertexType] { get }
>> var edges: [EdgeType] { get }
>> 
>> func outEdges(vertex: EdgeType.VertexType) -> [EdgeType]
>> }
>> 
>> protocol GraphIterator {
>> associatedtype GraphType : Graph
>> 
>> var graph: GraphType { get }
>> 
>> var startVertex: GraphType.VertexType { get }
>> 
>> func enter(vertex: GraphType.VertexType)
>> func propagate(along edge: GraphType.EdgeType)
>> func finish(vertex: GraphType.VertexType)
>> }
>> 
>> 
>> // with generics
>> 
>> class Edge {
>> var source: VertexType
>> var target: VertexType
>> }
>> 
>> class Graph {
>> 
>> var vertices: [VertexType]
>> var edges: [EdgeType]
>> 
>> func outEdges(vertex: VertexType) -> [EdgeType]
>> 
>> }
>> 
>> class GraphIterator> Graph> {
>> 
>> var graph: GraphType
>> 
>> var startVertex: VertexType
>> 
>> func enter(vertex: VertexType)
>> func propagate(along edge: EdgeType)
>> func finish(vertex: VertexType)
>> }
>> 
>> Note, how the parameter list for GraphIterator exploded, because I had to 
>> list each level of nested types down to the VertexType, whereas
>> in the associated types example the GraphIterator simply declares an 
>> associated type conforming to the topmost type of my nesting, the Graph.
>> 
>> 
>>> 
>>> Is there a deeper difference I’m missing?
>> 
>> Maybe Dave can chime in here?
> 
> You can recover an associated type (say, X.Element) by just having the type 
> “X”, but this is not true for a type parameter. That doesn’t matter when you 
> have (or want to specify) that type… for example, your comment that 
> Collection and Any would basically be 
> the same thing.
> 
> However, with generalized/enhanced existentials you would be able to write
> 
>   var heterogeneousArrayOfCollections: [Collection]
>   heterogeneousArrayOfCollections.append([1, 2 3])
>   heterogeneousArrayOfCollections.append([“Hello” : 1, “Swift” : 2])
> 
> You can’t do that with generic protocols, because there is no common element 
> type:
> 
>   var heterogeneousArrayOfCollections: [Collection]
> 
> One could perhaps try to rely on subtyping of collections for this specific 
> case
> 
>   var heterogeneousArrayOfCollections: [Collection]
>   heterogeneousArrayOfCollections.append([1, 2 3])
>   heterogeneousArrayOfCollections.append([“Hello” : 1, “Swift” : 

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

[Patrick Pijnappel via swift-evolution]

>
> Sure, but `mappingAndFlattening(to:)` would have brevity issues as well.


My point was that if you want to transform sin() -> sine() you'd be pretty
much forced to also do atanh() -> hyperbolicArcTangent(). However the
proposed transformation is for flatMap() to flatMapped(), which doesn't
have any brevity issues and is still very close to the exact term of art.

Higher-order functions are not a specialized feature that only the
> functional eggheads use. Outside of a few small pockets—one of which is
> native Apple apps—they are a pervasive feature of modern programming
> environments. They are the rule, not the exception.


They do have significant usage, but the term of art will not be an
"ingrained term" for any of the following:
– Users new to programming.
– Users from languages that do not have these functions, or include them
under a different name.
– Users from languages that do have these functions under these names, but
haven't used them so regularly as to become an ingrained term. Which I'd
estimate is a large group: Personally I've used most of the mainstream
languages on your list, some for a very long time, without using these
functions very much at all.

Nevertheless I'm also definitely in favor of keeping *the terms of art as
stems (*i.e. not moving to different words altogether) so we retain 90% of
the benefits, but just slightly modifying them.


On Sat, Jun 18, 2016 at 4:13 AM, Brent Royal-Gordon 
wrote:

> > – What sin(x) should do is unambiguous, unlike array.filter { ... }.
>
> A decent argument label, like `including` or even `to`, would fix the name
> `filter`. And as I said, if we feel `filter` is unsalvageable, the
> alternate Smalltalk-lineage `select` is clearer.
>
> > – 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?)
>
> > – The relevant metric of the strength of a term of art would be for how
> many users it already is a very much ingrained term (i.e. not how long it
> has been around). For sin() this is the case for pretty much anyone who has
> done high-school math. Conversely, map/filter/reduce will only be
> significantly ingrained for experienced users of languages that are
> functionally-centered enough to regularly use these, which is a much
> smaller percentage (though not insignificant).
>
> I think "languages that are functionally-centered enough to regularly use
> these" makes this set of languages sound rather smaller than it really is.
> The languages with C in their names—C, C++, Objective-C, and C#—are almost
> the only ones in modern use which *don't* include higher-order functions.
> Few people would regard Perl, Javascript, Java, Python, or Ruby as
> "functional" languages, but all of them support `map`. If you look at
> RedMonk's list of 21 popular languages <
> http://fossbytes.com/21-top-programming-languages-on-github-and-stack-overflowjanuary-2016/
> >:
>
> * 1 (CSS) has no real concept of lists or list operations.
> * 2 (shell and C) do not have closures.
> * 1 (Go) could support `map`, but K still think it's 1973.
> * 1 (Objective-C) could support `map`, but...well, if the Foundation guys
> want to tell us why they don't, they know where to find us.
> * 16 have a version of `map`:
> * 1 (Matlab) has vectorization features which act like an implicit
> `map`.
> * 2 (C# and Visual Basic) have a `select` operation from LINQ
> * 3 (C++, R, and Groovy) have other names for `map`
> * 10 (Javascript, Java, PHP, Python, Ruby, Perl, Scala, Go,
> Haskell, Swift, and Clojure) call it `map`.
>
> Of 16 languages with `map`, Scala, Haskell, Clojure, and maybe R and
> Matlab would typically be considered functional, and all of those are in
> the bottom half of the list. The other 11 languages with a version of `map`
> are all mainstream multi-paradigm languages of the sort people coming to
> Swift might be familiar with.
>
> In short: Higher-order functions are not a specialized feature that only
> the functional eggheads use. Outside of a few small pockets—one of which is
> native Apple apps—they are a pervasive feature of modern programming
> environments. They are the rule, not the exception.
>
> >> Let me turn your question around: What concrete benefits do we gain
> from modifying terms which are extremely widely recognized? It is not
> consistent, but is there any reason to believe that causes actual
> confusion? If not, then why fix what isn't broken?
> >
> > The benefits of renaming:
> > – It makes learning easier as it establishes a consistent way to read
> Swift methods right from the start.
> > – It would help users in intuitively learning consistent naming for
> their own methods, even if they haven't read the API guidelines.
>
> These are basically two ways of stating the same point,