Re: [swift-evolution] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 8, 2017, at 8:44 PM, Taylor Swift  wrote:
> 
> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot find 
> such a function anywhere in the API. There is copyBytes(from:) 
> ,
>  but the documentation is messed up and mentions a nonexistent count: 
> argument over and over again. The documentation also doesn’t mention what 
> happens if there is a length mismatch, so users are effectively relying on an 
> implementation detail. I don’t know how to best resolve this.

We currently have `UnsafeMutableRawBufferPointer.copyBytes(from:)`. I don’t 
think your proposal changes that. The current docs refer to the `source` 
parameter, which is correct. Docs refer to the parameter name, not the label 
name. So `source.count` is the size of the input. I was pointing out that it 
has the semantics: `debugAssert(source.count <= self.count)`.

Your proposal changes `UnsafeRawPointer.copyBytes(from:count:)` to 
`UnsafeRawPointer.copy(from:bytes:)`. Originally we wanted to those API names 
to match, but I’m fine with your change. What is more important is that the 
semantics are the same as `copyBytes(from:)`. Furthermore, any new methods that 
you add that copy into a raw buffer (e.g. initializeMemory(as:from:count:)) 
should have similar behavior.

—

Another thing. The initialization methods that you’re adding to 
`UnsafeRawPointer` and `UnsafeRawBufferPointer` should return typed 
`UnsafePointer` and `UnsafeBufferPointer` respectively.

Thanks,

-Andy

> On Tue, Aug 8, 2017 at 11:33 PM, Andrew Trick  > wrote:
> 
>> On Aug 8, 2017, at 8:29 PM, Taylor Swift > > wrote:
>> 
>> 
>> 
>> On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick > > wrote:
>> 
>>> On Aug 8, 2017, at 6:51 PM, Taylor Swift >> > wrote:
>>> 
>>> 
>>> 
>>> On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick >> > wrote:
>>> 
 > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
 
 Well, I think it's somewhat ridiculous for users to write this every time 
 they allocate a buffer:
 
 `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: 
 MemoryLayout.alignment)`
 
 If anyone reading the code is unsure about the Swift API's alignment
 guarantee, it's trivial to check the API docs.
 
 You could introduce a clearly documented default `alignedTo`
 argument. The reason I didn't do that is that the runtime won't
 respect it anyway. But I think it would be fair to go ahead with the
 API and file a bug against the runtime.
 
 Default argument of MemoryLayout.alignment is the way to go but as 
 you said i don’t know if that is actually allowed/works. An alternative is 
 to have two allocate methods each, one that takes an alignment argument 
 and one that doesn’t (and aligns to pointer alignment) but that feels 
 inelegant. Default arguments would be better.
>>> 
>>> Default argument makes sense to me too. Then the raw buffer pointer and 
>>> regular raw pointer APIs can be consistent with each other.
>>> 
>>> Runtime bug: https://bugs.swift.org/browse/SR-5664 
>>> 
>>> 
>>> yikes i was not aware of this. I don’t think it’s bad enough to warrant 
>>> dropping the argument like with deallocate(capacity:) but I can imagine bad 
>>> things happening to code that crams extra inhabitants into pointers.
>> 
>> If we ever need to do pointer adjustment during deallocation to accommodate 
>> alignment, then I think the Swift runtime can track that. I see no reason to 
>> muddy the UnsafeRawPointer API with it. So, I agree with your proposed 
>> change to drop `alignedTo` there.
>> 
>> -Andy
>> 
>> oh lol I was talking about assuming the pointer returned by 
>> allocate(bytes:alignedTo:) is a multiple of alignedTo. Some code might be 
>> relying on the last few bits of the pointer being zero; i.e. sticking bit 
>> flags there like how some implementations store the red/black color 
>> information in a red-black tree node.
> 
> Oh, sure. But I think it will be easy to fix the runtime. We could probably 
> do it before the proposal is accepted if necessary.
> -Andy
> 
> 

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

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

[Rob Mayoff via swift-evolution]

On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users <
swift-us...@swift.org> wrote:

>
>
> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Yes, exactly. An Array is a struct wrapper for a reference type
>> representing storage. Mutating functions first check if they own the only
>> reference to the storage using isKnownUniquelyReferenced
>> .
>> If not, they make a fresh copy before applying the mutating operation.
>>
>> There's no difference for `let` arrays. Access control is enforced at
>> compile-time through Array's design: the compiler will prevent you from
>> calling `mutating` functions on `let` structs, and Array is careful to not
>> expose functionality that could modify its storage outside of `mutating`
>> functions.
>>
>> There is no secret. Anyone could implement the same thing only using
>> publicly available and documented compiler features. In fact, it's been
>> done already for some very powerful collections
>> .
>>
>
> This isn’t entirely true. That BTree module readme seems to contain a lot
> of unsubstantiated hyperbole. It’s possible to implement a classic
> red-black tree in Swift that performs better than a sorted Array, down to
> about *n* = 1,500 items, not *n* = *100,000* items as it claims.
> (Actually, heap allocators these days are good enough that performance is
> on par with Array all the way down to *n* = 1.) Red-Black trees are slow
> when *distributed* as packages because of the crossmodule optimization
> boundary. (This also means the BTree module is much slower than Array for
> most reasonable *n*.) It’s possible to write modules using compiler
> attributes that mitigate this slowdown (reclaiming over 50% of lost
> performance) but it’s hacky and forces you to design your libraries like
> the standard library (meaning: ugly underscored properties everywhere and
> everything is public). And these features aren’t “publicly available” or
> documented at all.
>

This seems harsh. I didn't notice Félix making any claims about BTree's
performance. The necessary API for implementing COW is indisputably public
and documented:

https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

[Yuta Koshizawa via swift-evolution]

2017-08-09 12:23 GMT+09:00 Xiaodi Wu :

>
For consistency, the name for this function would be `isSuperset(of:)`, and
it would be equally interesting to have `isStrictSuperset(of:)`,
`isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all
currently available for types that conform to `SetAlgebra`.


Thank you for your feedback. It certainly seems better to rename `contains`
to `isSuperset(of:)`. Also I'll try to implement `isStrictSuperset(of:)`
and so on.

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

Re: [swift-evolution] Swift 5: start your engines

[Chris Lattner via swift-evolution]

> On Aug 8, 2017, at 8:19 PM, Susan Cheng via swift-evolution 
>  wrote:
> 
> is it accept proposal for coroutine?
> Just like the one i had proposed before: 
> https://github.com/apple/swift-evolution/pull/73 
> 
Hi Susan,

I’d love to see progress on this specific topic, with specific application to 
async/await.  I have a much more detailed proposal in the works, I’ll share it 
when it is ready.

-Chris

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

Re: [swift-evolution] Enums and Source Compatibility

[Charlie Monroe via swift-evolution]

While I agree with the entire idea and would actually use behavior like this in 
a few instances, I feel that in most cases, you would simply put 

default:
fatalError()

The huge downside of this is that you no longer get warned by the compiler that 
you are missing a case that was added - a common thing I personally do (and I 
have a feeling I'm not alone) - add an enum case, build the app, see what broke 
and fix it - as you get warnings/errors about the switch not being exhaustive. 
You find this out during runtime (if you're lucky), otherwise your end user.

As you've noted all enums from ObjC would need to be marked with an annotation 
marking if they are closed - which given the way nullability is still missing 
in many frameworks out there, I think would take years.

I'd personally expand this proposal by introducing switch! (with the 
exclamation mark) which would allow to treat open enums as closed. Example:

// Imported from ObjC
open enum NSAlert.Style { ... }

switch! alert.style {
case .warning:
// ...
case .informational:
// ...
case .critical:
// ...
}

The force-switch would implicitely create the default label crashing, logging 
the rawValue of the enum.

Thoughts?

> On Aug 9, 2017, at 12:28 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an 
> issue that's been around for a while: the source compatibility of enums. 
> Today, it's an error to switch over an enum without handling all the cases, 
> but this breaks down in a number of ways:
> 
> - A C enum may have "private cases" that aren't defined inside the original 
> enum declaration, and there's no way to detect these in a switch without 
> dropping down to the rawValue.
> - For the same reason, the compiler-synthesized 'init(rawValue:)' on an 
> imported enum never produces 'nil', because who knows how anyone's using C 
> enums anyway?
> - Adding a new case to a Swift enum in a library breaks any client code that 
> was trying to switch over it.
> 
> (This list might sound familiar, and that's because it's from a message of 
> mine on a thread started by Matthew Johnson back in February called "[Pitch] 
> consistent public access modifiers". Most of the rest of this email is going 
> to go the same way, because we still need to make progress here.)
> 
> At the same time, we really like our exhaustive switches, especially over 
> enums we define ourselves. And there's a performance side to this whole thing 
> too; if all cases of an enum are known, it can be passed around much more 
> efficiently than if it might suddenly grow a new case containing a struct 
> with 5000 Strings in it.
> 
> 
> Behavior
> 
> I think there's certain behavior that is probably not terribly controversial:
> 
> - When enums are imported from Apple frameworks, they should always require a 
> default case, except for a few exceptions like NSRectEdge. (It's Apple's job 
> to handle this and get it right, but if we get it wrong with an imported enum 
> there's still the workaround of dropping down to the raw value.)
> - When I define Swift enums in the current framework, there's obviously no 
> compatibility issues; we should allow exhaustive switches.
> 
> Everything else falls somewhere in the middle, both for enums defined in 
> Objective-C:
> 
> - If I define an Objective-C enum in the current framework, should it allow 
> exhaustive switching, because there are no compatibility issues, or not, 
> because there could still be private cases defined in a .m file?
> - If there's an Objective-C enum in another framework (that I built locally 
> with Xcode, Carthage, CocoaPods, SwiftPM, etc.), should it allow exhaustive 
> switching, because there are no binary compatibility issues, or not, because 
> there may be source compatibility issues? We'd really like adding a new enum 
> case to not be a breaking change even at the source level.
> - If there's an Objective-C enum coming in through a bridging header, should 
> it allow exhaustive switching, because I might have defined it myself, or 
> not, because it might be non-modular content I've used the bridging header to 
> import?
> 
> And in Swift:
> 
> - If there's a Swift enum in another framework I built locally, should it 
> allow exhaustive switching, because there are no binary compatibility issues, 
> or not, because there may be source compatibility issues? Again, we'd really 
> like adding a new enum case to not be a breaking change even at the source 
> level.
> 
> Let's now flip this to the other side of the equation. I've been talking 
> about us disallowing exhaustive switching, i.e. "if the enum might grow new 
> cases you must have a 'default' in a switch". In previous (in-person) 
> discussions about this feature, it's been pointed out that the code in an 
> otherwise-fully-covered switch is, by definition, unreachable, and therefore 
> untestable. This also 

Re: [swift-evolution] How does "Sequence.joined" work?

[Taylor Swift via swift-evolution]

On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <
swift-evolution@swift.org> wrote:

> Yes, exactly. An Array is a struct wrapper for a reference type
> representing storage. Mutating functions first check if they own the only
> reference to the storage using isKnownUniquelyReferenced
> .
> If not, they make a fresh copy before applying the mutating operation.
>
> There's no difference for `let` arrays. Access control is enforced at
> compile-time through Array's design: the compiler will prevent you from
> calling `mutating` functions on `let` structs, and Array is careful to not
> expose functionality that could modify its storage outside of `mutating`
> functions.
>
> There is no secret. Anyone could implement the same thing only using
> publicly available and documented compiler features. In fact, it's been
> done already for some very powerful collections
> .
>

This isn’t entirely true. That BTree module readme seems to contain a lot
of unsubstantiated hyperbole. It’s possible to implement a classic
red-black tree in Swift that performs better than a sorted Array, down to
about *n* = 1,500 items, not *n* = *100,000* items as it claims. (Actually,
heap allocators these days are good enough that performance is on par with
Array all the way down to *n* = 1.) Red-Black trees are slow when
*distributed* as packages because of the crossmodule optimization boundary.
(This also means the BTree module is much slower than Array for most
reasonable *n*.) It’s possible to write modules using compiler attributes
that mitigate this slowdown (reclaiming over 50% of lost performance) but
it’s hacky and forces you to design your libraries like the standard
library (meaning: ugly underscored properties everywhere and everything is
public). And these features aren’t “publicly available” or documented at
all.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] How does "Sequence.joined" work?

[Félix Cloutier via swift-evolution]

Yes, exactly. An Array is a struct wrapper for a reference type representing 
storage. Mutating functions first check if they own the only reference to the 
storage using isKnownUniquelyReferenced 
.
 If not, they make a fresh copy before applying the mutating operation.

There's no difference for `let` arrays. Access control is enforced at 
compile-time through Array's design: the compiler will prevent you from calling 
`mutating` functions on `let` structs, and Array is careful to not expose 
functionality that could modify its storage outside of `mutating` functions.

There is no secret. Anyone could implement the same thing only using publicly 
available and documented compiler features. In fact, it's been done already for 
some very powerful collections .

> Le 8 août 2017 à 15:45, Geordie Jay  a écrit :
> 
> 
> Daryle Walker via swift-evolution  > schrieb am Di. 8. Aug. 2017 um 21:25:
>> On Aug 8, 2017, at 12:35 AM, Félix Cloutier > > wrote:
>> 
>> All this means is that `joined()` does not create an array that contains the 
>> new result. It's only as magic as the COW semantics on arrays.
> 
> So you’re saying the COW semantics for Array and other standard library types 
> have secret references/pointers that work even for “let”-mode objects, and 
> the Sequence variants the various forms of “joined” need use a 
> Sequence/Collection of those secret references?
> 
> I know nothing about this specific type under the hood and your question 
> stumped me when I first saw it as well, so take this with a grain of salt:
> 
> I think it's basically just storing the arrays internally (as let) and when 
> you iterate through the collection it just goes through the subsequences one 
> by one, when the last index of the first is reached it begins with the next 
> subsequence.
> 
> As for how it avoids creating new storage, simple. As someone else mentioned, 
> this is no more magic than Copy On Write for normal arrays.
> 
> let a = [1,2,3]
> let b = a // this doesn't produce a copy of the underlying buffer.. I.e. 
> value semantics but only one buffer needed
> 
> ^^^ This is the take-home message. And your intuition about COW is correct: 
> its internal storage is a reference type containing a buffer pointer. When 
> (and only when) a mutation occurs, the buffer is copied and the new storage 
> becomes the backing for the resulting struct. Any existing copies remain 
> unchanged (and truly immutable) because they keep their original storage.
> 
> https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift
>  
> 
> 
> 
> So with that understanding of COW, it becomes easy to imagine all sorts of 
> containers that don't require additional storage for their contents:
> 
> struct JoinedSequenceOfThreeArrays {
>   let array1: [T]
>   let array2: [T]
>   let array3: [T]
> }
> 
> // still only one array buffer storage is required for all of this:
> let c = JoinedSequenceOfThreeArrays(array1: a, array2: a, array3: b)
> 
> Does that make sense?
> 
> Geordie
> 
> 
>>> Le 7 août 2017 à 21:12, Daryle Walker via swift-evolution 
>>> > a écrit :
>>> 
>>> I was looking at random items at SwiftDoc.org , and 
>>> noticed the “FlattenBidirectionalCollection” structure. It helps implement 
>>> some versions of “joined” from Sequence (probably when the Sequence is also 
>>> a BidirectionalCollection). The directions for the type state that “joined” 
>>> does not create new storage. Then wouldn’t it have to refer to the source 
>>> objects by reference? How; especially how does it work without requiring a 
>>> “&” with “inout” or how it works with “let”-mode objects? Or am I 
>>> misunderstanding how it works behind the covers?
>>> 
>>> (If there is a secret sauce to have one object refer to another without 
>>> “&”/“inout”/“UnsafeWhateverPointer”, I like to know. It may help with 
>>> implementing an idea. The idea involves extending the language, so 
>>> “compiler magic” that the user can’t access is OK; I’d just claim to use 
>>> the same sauce in my proposal.)
> 
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT 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

[swift-evolution] ExpressibleByStringInterpolation

[Brent Royal-Gordon via swift-evolution]

I had a proposal for replacing/reintroducing `ExpressibleByStringInterpolation` 
(which is currently deprecated pending a redesign), but it landed too late in 
the Swift 4 cycle to be considered. The PR is here: 
https://github.com/apple/swift-evolution/pull/659

I think it squares up relatively well against the Swift 5 standards:

* It addresses ABI stability and strings, which are both Swift 5 themes.

* It includes an implementation, but it definitely needs a rebase, probably 
needs someone more experienced than me to examine it with a fine-toothed comb, 
and might need a significant redesign.

* I believe it includes tests.

* I don't think it's been run against the source compatibility suite. (Is there 
a way for random outside developers to do that?)

So what's the next step at this point?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 8, 2017, at 8:29 PM, Taylor Swift  wrote:
> 
> 
> 
> On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick  > wrote:
> 
>> On Aug 8, 2017, at 6:51 PM, Taylor Swift > > wrote:
>> 
>> 
>> 
>> On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick > > wrote:
>> 
>>> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
>>> 
>>> Well, I think it's somewhat ridiculous for users to write this every time 
>>> they allocate a buffer:
>>> 
>>> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: 
>>> MemoryLayout.alignment)`
>>> 
>>> If anyone reading the code is unsure about the Swift API's alignment
>>> guarantee, it's trivial to check the API docs.
>>> 
>>> You could introduce a clearly documented default `alignedTo`
>>> argument. The reason I didn't do that is that the runtime won't
>>> respect it anyway. But I think it would be fair to go ahead with the
>>> API and file a bug against the runtime.
>>> 
>>> Default argument of MemoryLayout.alignment is the way to go but as you 
>>> said i don’t know if that is actually allowed/works. An alternative is to 
>>> have two allocate methods each, one that takes an alignment argument and 
>>> one that doesn’t (and aligns to pointer alignment) but that feels 
>>> inelegant. Default arguments would be better.
>> 
>> Default argument makes sense to me too. Then the raw buffer pointer and 
>> regular raw pointer APIs can be consistent with each other.
>> 
>> Runtime bug: https://bugs.swift.org/browse/SR-5664 
>> 
>> 
>> yikes i was not aware of this. I don’t think it’s bad enough to warrant 
>> dropping the argument like with deallocate(capacity:) but I can imagine bad 
>> things happening to code that crams extra inhabitants into pointers.
> 
> If we ever need to do pointer adjustment during deallocation to accommodate 
> alignment, then I think the Swift runtime can track that. I see no reason to 
> muddy the UnsafeRawPointer API with it. So, I agree with your proposed change 
> to drop `alignedTo` there.
> 
> -Andy
> 
> oh lol I was talking about assuming the pointer returned by 
> allocate(bytes:alignedTo:) is a multiple of alignedTo. Some code might be 
> relying on the last few bits of the pointer being zero; i.e. sticking bit 
> flags there like how some implementations store the red/black color 
> information in a red-black tree node.

Oh, sure. But I think it will be easy to fix the runtime. We could probably do 
it before the proposal is accepted if necessary.
-Andy

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

Re: [swift-evolution] SE-184 Improved Pointers

[Taylor Swift via swift-evolution]

On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick  wrote:

>
> On Aug 8, 2017, at 6:51 PM, Taylor Swift  wrote:
>
>
>
> On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick  wrote:
>
>>
>> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
>>>
>>> Well, I think it's somewhat ridiculous for users to write this every
>>> time they allocate a buffer:
>>>
>>> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo:
>>> MemoryLayout.alignment)`
>>>
>>> If anyone reading the code is unsure about the Swift API's alignment
>>> guarantee, it's trivial to check the API docs.
>>>
>>> You could introduce a clearly documented default `alignedTo`
>>> argument. The reason I didn't do that is that the runtime won't
>>> respect it anyway. But I think it would be fair to go ahead with the
>>> API and file a bug against the runtime.
>>>
>>
>> Default argument of MemoryLayout.alignment is the way to go but as
>> you said i don’t know if that is actually allowed/works. An alternative is
>> to have two allocate methods each, one that takes an alignment argument and
>> one that doesn’t (and aligns to pointer alignment) but that feels
>> inelegant. Default arguments would be better.
>>
>>
>> Default argument makes sense to me too. Then the raw buffer pointer and
>> regular raw pointer APIs can be consistent with each other.
>>
>> Runtime bug: https://bugs.swift.org/browse/SR-5664
>>
>>
> yikes i was not aware of this. I don’t think it’s bad enough to warrant
> dropping the argument like with deallocate(capacity:) but I can imagine
> bad things happening to code that crams extra inhabitants into pointers.
>
>
> If we ever need to do pointer adjustment during deallocation to
> accommodate alignment, then I think the Swift runtime can track that. I see
> no reason to muddy the UnsafeRawPointer API with it. So, I agree with your
> proposed change to drop `alignedTo` there.
>
> -Andy
>

oh lol I was talking about assuming the pointer returned by
allocate(bytes:alignedTo:) is a multiple of alignedTo. Some code might be
relying on the last few bits of the pointer being zero; i.e. sticking bit
flags there like how some implementations store the red/black color
information in a red-black tree node.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 8, 2017, at 6:51 PM, Taylor Swift  wrote:
> 
> 
> 
> On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick  > wrote:
> 
>> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
>> 
>> Well, I think it's somewhat ridiculous for users to write this every time 
>> they allocate a buffer:
>> 
>> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: 
>> MemoryLayout.alignment)`
>> 
>> If anyone reading the code is unsure about the Swift API's alignment
>> guarantee, it's trivial to check the API docs.
>> 
>> You could introduce a clearly documented default `alignedTo`
>> argument. The reason I didn't do that is that the runtime won't
>> respect it anyway. But I think it would be fair to go ahead with the
>> API and file a bug against the runtime.
>> 
>> Default argument of MemoryLayout.alignment is the way to go but as you 
>> said i don’t know if that is actually allowed/works. An alternative is to 
>> have two allocate methods each, one that takes an alignment argument and one 
>> that doesn’t (and aligns to pointer alignment) but that feels inelegant. 
>> Default arguments would be better.
> 
> Default argument makes sense to me too. Then the raw buffer pointer and 
> regular raw pointer APIs can be consistent with each other.
> 
> Runtime bug: https://bugs.swift.org/browse/SR-5664 
> 
> 
> yikes i was not aware of this. I don’t think it’s bad enough to warrant 
> dropping the argument like with deallocate(capacity:) but I can imagine bad 
> things happening to code that crams extra inhabitants into pointers.

If we ever need to do pointer adjustment during deallocation to accommodate 
alignment, then I think the Swift runtime can track that. I see no reason to 
muddy the UnsafeRawPointer API with it. So, I agree with your proposed change 
to drop `alignedTo` there.

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

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

[Xiaodi Wu via swift-evolution]

For consistency, the name for this function would be `isSuperset(of:)`, and
it would be equally interesting to have `isStrictSuperset(of:)`,
`isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all
currently available for types that conform to `SetAlgebra`.

On Tue, Aug 8, 2017 at 9:40 PM, Yuta Koshizawa via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi,
>
> Recently I needed to implement `contains` methods to check if a range
> contains another range. I think those are basic operations and suitable for
> the standard library.
>
> Although it may seem easy to implement such `contains` methods whenever we
> need them, their precise specifications are too complicated to do so.
>
> e.g.
>
> let a: ClosedRange = 2...7
> a.contains(3...5) // `true`
> a.contains(3...7) // also `true`
> a.contains(3..<8) // still `true` because all values contained in `3..<8`
> are also in `a`
> a.contains(3..<9) // `false`
>
> let b: ClosedRange = 2...7
> b.contains(3...5) // `true`
> b.contains(3...7) // `true`
> b.contains(3..<8) // `false` because { x | 7.0 < x < 8.0 } is not
> contained in `a`
>
> let c: Range = 2..<7
> c.contains(3...5) // `true`
> c.contains(3..<7) // `true`
> c.contains(3...7) // `false` because 7.0 is not contained in `a`
>
> My experimental implementation is here:
> https://github.com/koher/range-contains
> (Currently does not support one-sided ranges)
>
> What are your thoughts about them?
>
> --
> Yuta
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 5: start your engines

[Susan Cheng via swift-evolution]

is it accept proposal for coroutine?
Just like the one i had proposed before:
https://github.com/apple/swift-evolution/pull/73

2017-08-09 0:23 GMT+08:00 Ted Kremenek via swift-evolution <
swift-evolution@swift.org>:

> Hi everyone,
>
> The proposal phase for Swift 4 is now officially over, and the release is
> now in endgame engineering convergence for an expected release later this
> year.  Swift 4 has turned out to be one of the highest quality,
> well-rounded releases of Swift, and I am grateful to everyone in the
> community who made this release come together!
>
> Now it is time to turn our attention to Swift 5.  I have just posted
> updates to the README.md file on the swift-evolution repository, which
> outlines the core themes and focus areas for Swift 5:
>
>   https://github.com/apple/swift-evolution
>
> and a more persistent URL (invariant to future README.md changes):
>
>   https://github.com/apple/swift-evolution/blob/
> 9cc90f33b6659adeaf92355c359e34e6fed73254/README.md
>
> I am not going to repeat all of that information here, but I wanted to
> highlight a few important things.
>
> ## ABI Stability
>
> First, ABI stability is the center focus of Swift 5 — and we will pivot
> much of our prioritization of efforts for Swift 5 around it.  With Swift 4,
> ABI stability was a strong goal.  In Swift 5, it is a *requirement* of the
> release.  Whatever ABI we have at the end of Swift 5 is the ABI that we
> will have.  ABI stability is an important inflection point for the maturity
> of the language, and it cannot be delayed any longer.
>
> Please note that there is a difference between ABI stability and module
> stability.   If you are not aware of the difference — which is rather
> important — please read the first few paragraphs of the ABI stability
> manifesto:
>
>   https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md
>
> Module stability is a stretch goal for Swift 5, but even without module
> stability we can still achieve the primary value of ABI stability.
>
> ##  Other focus areas (including laying the groundwork for concurrency)
>
> There are several other areas mentioned for Swift 5 which I won’t repeat
> here, but there is a general theme of refining and broadening out the core
> ergonomics of the language and standard library.
>
> One of those that I wanted to highlight is laying the groundwork for
> concurrency.  It is a non-goal of Swift 5 to roll out a full new
> concurrency model.  That is simply too large an effort to do alongside ABI
> stability.  However, it is important that we start making progress on
> discussing the directions for concurrency and laying some of the
> groundwork.  This may take the form of specific enhancements to the
> language that get implemented, depending on where the discussions for
> concurrency lead and how they align with the priorities for delivering ABI
> stability in Swift 5.
>
> ## Changes to the language evolution process
>
> Last, I want to highlight important changes to the evolution process:
>
>   https://github.com/apple/swift-evolution#evolution-process-for-swift-5
> 
>
> With Swift 4, the release period was divided up into “stage 1” and “stage
> 2” for setting guidelines for the kind of evolution proposals that were in
> scope for the release.  This was needed to establish focus — especially
> after the churn we saw during Swift 3 — on some core themes that were
> aligned with converging the language towards source & ABI stability.  One
> downside is that “stage 2” opened up discussion for potentially disruptive
> changes fairly late in the release.  Further, some proposals — such as
> SE-0155 — came in so late that there was little runway to actually
> implement them for Swift 4, let alone evaluate their impact in practice on
> real projects.  Related, there has been some desire  for a while to be able
> to better evaluate the impact of proposals on real code before they are
> locked into the release, and the best way to do that is to actually have an
> implementation that vets out the design in a proposal.
>
> With Swift 5, the focus on ABI stability will predominate priorities for
> both design and implementation work, but the Core Team did not want that
> focus to stifle all discussion on potential enhancements to the language
> that were not fundamentally tied to that primary goal.  After reflecting on
> the evolution process during both the Swift 3 and Swift 4 releases, the
> Core Team felt that we could strike a balance with not diluting attention
> from ABI stability while still enabling a broader range of proposals
> compared to Swift 4 by **requiring that all proposals have an
> implementation** before they are officially reviewed by the Core Team.  An
> implementation can come long after an idea has been pitched and after a
> proposal has been written.  However, before a pull request for an evolution
> proposal will be 

[swift-evolution] [Pitch] range.contains(anotherRange)

[Yuta Koshizawa via swift-evolution]

Hi,

Recently I needed to implement `contains` methods to check if a range
contains another range. I think those are basic operations and suitable for
the standard library.

Although it may seem easy to implement such `contains` methods whenever we
need them, their precise specifications are too complicated to do so.

e.g.

let a: ClosedRange = 2...7
a.contains(3...5) // `true`
a.contains(3...7) // also `true`
a.contains(3..<8) // still `true` because all values contained in `3..<8`
are also in `a`
a.contains(3..<9) // `false`

let b: ClosedRange = 2...7
b.contains(3...5) // `true`
b.contains(3...7) // `true`
b.contains(3..<8) // `false` because { x | 7.0 < x < 8.0 } is not contained
in `a`

let c: Range = 2..<7
c.contains(3...5) // `true`
c.contains(3..<7) // `true`
c.contains(3...7) // `false` because 7.0 is not contained in `a`

My experimental implementation is here:
https://github.com/koher/range-contains
(Currently does not support one-sided ranges)

What are your thoughts about them?

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

Re: [swift-evolution] SE-184 Improved Pointers

[Taylor Swift via swift-evolution]

On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick  wrote:

>
> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
>>
>> Well, I think it's somewhat ridiculous for users to write this every time
>> they allocate a buffer:
>>
>> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo:
>> MemoryLayout.alignment)`
>>
>> If anyone reading the code is unsure about the Swift API's alignment
>> guarantee, it's trivial to check the API docs.
>>
>> You could introduce a clearly documented default `alignedTo`
>> argument. The reason I didn't do that is that the runtime won't
>> respect it anyway. But I think it would be fair to go ahead with the
>> API and file a bug against the runtime.
>>
>
> Default argument of MemoryLayout.alignment is the way to go but as
> you said i don’t know if that is actually allowed/works. An alternative is
> to have two allocate methods each, one that takes an alignment argument and
> one that doesn’t (and aligns to pointer alignment) but that feels
> inelegant. Default arguments would be better.
>
>
> Default argument makes sense to me too. Then the raw buffer pointer and
> regular raw pointer APIs can be consistent with each other.
>
> Runtime bug: https://bugs.swift.org/browse/SR-5664
>
>
yikes i was not aware of this. I don’t think it’s bad enough to warrant
dropping the argument like with deallocate(capacity:) but I can imagine bad
things happening to code that crams extra inhabitants into pointers.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 8, 2017, at 5:49 PM, Taylor Swift  wrote:
> 
> 
> 
> On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick  > wrote:
> 
>> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution 
>> > wrote:
>> 
>> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is 
>> ready for community review, and I encourage everyone to look it over and 
>> provide feedback. Thank you!
>> >  
>> >
> 
> 
> Excellent. Thanks for patiently iterating on this. I know it's time consuming.
> 
> > add a default value of 1 to all size parameters on
> > UnsafeMutablePointer and applicable size parameters on
> > UnsafeMutableRawPointer
> 
> I'm generally ok with this if you have seen the benefit of it in real
> code. However, I do not think any `repeating:` methods should have a
> default count.
> 
> Actually, i believe initialize(to:count:) is currently the one method that 
> already has a default count. That’s probably because the standard library 
> calls this method with a count argument of 1 more than any other memorystate 
> method. I don’t know if this decision was only made for the sake of the 
> stdlib or if it had an API justification.

Right you are. I had just noticed that none of the other `repeating` APIs had a 
default. But if this default argument simplifies real code patterns then I’m 
fine with it.

> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
> 
> Well, I think it's somewhat ridiculous for users to write this every time 
> they allocate a buffer:
> 
> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: 
> MemoryLayout.alignment)`
> 
> If anyone reading the code is unsure about the Swift API's alignment
> guarantee, it's trivial to check the API docs.
> 
> You could introduce a clearly documented default `alignedTo`
> argument. The reason I didn't do that is that the runtime won't
> respect it anyway. But I think it would be fair to go ahead with the
> API and file a bug against the runtime.
> 
> Default argument of MemoryLayout.alignment is the way to go but as you 
> said i don’t know if that is actually allowed/works. An alternative is to 
> have two allocate methods each, one that takes an alignment argument and one 
> that doesn’t (and aligns to pointer alignment) but that feels inelegant. 
> Default arguments would be better.

Default argument makes sense to me too. Then the raw buffer pointer and regular 
raw pointer APIs can be consistent with each other.

Runtime bug: https://bugs.swift.org/browse/SR-5664

> > and initializeMemory(as:at:repeating:count:),
> > initializeMemory(as:from:count:)
> > moveInitializeMemory(as:from:count:), and
> > bindMemory(to:count:) to UnsafeMutableRawBufferPointer
> 
> I think you should move the raw pointer changes to a separate bullet point.
> 
> Presumably the raw buffer capacity must match or exceed count * stride?
> 
> -Andy
> 
> The reason the raw buffer pointers don’t fill in their own size is the 
> destination type might not line up with the raw buffer size, and then there’s 
> questions of rounding and whatnot. bindMemory(to:count:) would also have to 
> perform integer division or some other defined behavior. Though if people 
> think computing the strided count inside the buffer pointer method is the 
> right way to go, I’m open to that.

No, I think your API is fine. I just wanted to clarify that we will trap if the 
raw buffer is too small to fit the requested elements.

-Andy

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

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

[Taylor Swift via swift-evolution]

Real Swift code uses very very few “unicode” operators, so I would heavily
tilt the division towards making most characters identifiers. While I don’t
want to talk about specific characters, I often wish I could name variables
`∇f` or `∂u∂v`, while no sane API designer would ever use `∇` or `∂` as
operators, even though they are considered “mathematical”. I think the bar
for making a character an operator should be higher: no character should be
classified as an operator if it can appear in language as part of an
identifier.

On Tue, Aug 8, 2017 at 2:10 PM, Nevin Brackett-Rozinsky via swift-evolution
 wrote:

> Is this proposal still on track, or are there other plans to address the
> issue of operator and identifier characters in Swift?
>
> Nevin
>
>
> On Fri, Feb 17, 2017 at 12:50 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised
>> proposal in draft form.
>>
>> It proposes a source-breaking change for *rationalizing* which
>> characters are permitted in identifiers and which in operators. It's
>> justified for this phase of Swift 4 because:
>>
>> - Existing grammar, in permitting invisible characters without
>> security-minded restrictions, can be *actively harmful.*
>> - A rationalized approach is *superior* to the current approach: by
>> referencing Unicode standards, Swift should be able to evolve in a
>> backwards-compatible way alongside Unicode, and will benefit from the
>> significant expertise of others outside the Swift community with respect to
>> Unicode best practices.
>> - The vast majority of existing code (including all of the standard
>> library) should *require no migration* work at all
>>
>> *What's changed* since the last time:
>>
>> - In an earlier draft, we proposed some radical changes to align with
>> available Unicode standards; in particular, since emoji represent a
>> difficult issue, and no recommendations about "operator identifiers" have
>> surfaced from Unicode, we proposed temporarily stripping them out. This was 
>> *very
>> poorly received*. This revision uses Unicode categories to identify
>> nearly all emoji and classify them as identifier characters (while
>> excluding those that depict operators such as !), and it uses Unicode
>> categories to identify over 900 operators that nearly all pass the
>> subjective test of "operator-likeness."
>>
>> What this proposal *does not attempt* to do:
>>
>> - This document *does not* seek to stake out new ground as to what
>> characters should be *added* to the set of valid identifiers and
>> operators. Such additions to the grammar are properly separate discussions.
>> This proposal is only an attempt at systemization and rationalization. Only
>> one character is incidentally added to the list of valid characters (`\`),
>> and it is on the basis of an explicit table in Unicode Technical Report 25
>> regarding ASCII characters that are "mathematical."
>>
>> What feedback would be* most helpful*:
>>
>> - "Hey, this approach is so much more *clumsy* than my superior, more
>> elegant category-based approach to identifying [operators/emoji], which is
>> [insert here]."
>> - "Hey, I disagree with the detailed design because it's got a *major
>> security hole*, which is [insert here]."
>> - "Hey, your proposal would break my *real-world* Swift code, which
>> requires that character [X] be an [identifier/operator]."
>>
>> What would be *less helpful*:
>>
>> - "Hey, let's talk about how [specific character] should be an
>> [identifier/operator]. We should add that character to the list of
>> [identifiers/operators]. In fact, let's discuss [list] characters one by
>> one."
>>
>> Acknowledgments:
>> Thanks to co-authors of the previous take for their support for
>> resurrecting this issue. Any brilliant ideas are undoubtedly theirs, and
>> any botched efforts are certainly mine. Thanks also to Nevin
>> Brackett-Rozinsky for helpful feedback.
>>
>> Link:
>> https://gist.github.com/xwu/d2c2bb7097b0b5a4e9985aae737a2651
>>
>> ___
>> 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] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution 
>  wrote:
> 
> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is 
> ready for community review, and I encourage everyone to look it over and 
> provide feedback. Thank you!
>   
> >


Excellent. Thanks for patiently iterating on this. I know it's time consuming.

> This differs from the previous draft of this proposal, in that this
> expansion is more additive and less source-breaking, preserving the
> much of the sized API present on UnsafeMutablePointer.

Yay!

> For the binary operations assign(from:), moveAssign(from:),
> moveInitialize(from:), and initialize(from:), it is assumed that the
> other buffer pointer contains at least as many elements as self does.

Uh-oh! This should be consistent with
UnsafeRawBufferPointer.copy(from:bytes:) (the raw version of
assign/initialize(from:)). There we assume no data is dropped and
allow an uninitalized buffer tail. What was your rationale for the
opposite choice and how can we reconcile these APIs?

> add a default value of 1 to all size parameters on
> UnsafeMutablePointer and applicable size parameters on
> UnsafeMutableRawPointer

I'm generally ok with this if you have seen the benefit of it in real
code. However, I do not think any `repeating:` methods should have a
default count.

> avoids the contradictory and inconsistent use of count to represent a byte 
> quantity

Background: Whether you consider an API consistent depends on how you
prioritize the guidelines. Here you've taken guidelines that I started
to use for new raw pointer APIs and given them higher priority than
other guidelines, in this case having the `count` initializer label match
the name of the public property being initialized. I think your change
is an improvement, but there was nothing accidental about the previous
API.

> UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)

Well, I think it's somewhat ridiculous for users to write this every time they 
allocate a buffer:

`UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: 
MemoryLayout.alignment)`

If anyone reading the code is unsure about the Swift API's alignment
guarantee, it's trivial to check the API docs.

You could introduce a clearly documented default `alignedTo`
argument. The reason I didn't do that is that the runtime won't
respect it anyway. But I think it would be fair to go ahead with the
API and file a bug against the runtime.

> and initializeMemory(as:at:repeating:count:),
> initializeMemory(as:from:count:)
> moveInitializeMemory(as:from:count:), and
> bindMemory(to:count:) to UnsafeMutableRawBufferPointer

I think you should move the raw pointer changes to a separate bullet point.

Presumably the raw buffer capacity must match or exceed count * stride?

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

Re: [swift-evolution] How does "Sequence.joined" work?

[Geordie Jay via swift-evolution]

Daryle Walker via swift-evolution  schrieb am
Di. 8. Aug. 2017 um 21:25:

> On Aug 8, 2017, at 12:35 AM, Félix Cloutier 
> wrote:
>
> All this means is that `joined()` does not create an array that contains
> the new result. It's only as magic as the COW semantics on arrays.
>
>
> So you’re saying the COW semantics for Array and other standard library
> types have secret references/pointers that work even for “let”-mode
> objects, and the Sequence variants the various forms of “joined” need use a
> Sequence/Collection of those secret references?
>

I know nothing about this specific type under the hood and your question
stumped me when I first saw it as well, so take this with a grain of salt:

I think it's basically just storing the arrays internally (as let) and when
you iterate through the collection it just goes through the subsequences
one by one, when the last index of the first is reached it begins with the
next subsequence.

As for how it avoids creating new storage, simple. As someone else
mentioned, this is no more magic than Copy On Write for normal arrays.

let a = [1,2,3]
let b = a // this doesn't produce a copy of the underlying buffer.. I.e.
value semantics but only one buffer needed

^^^ This is the take-home message. And your intuition about COW is correct:
its internal storage is a reference type containing a buffer pointer. When
(and only when) a mutation occurs, the buffer is copied and the new storage
becomes the backing for the resulting struct. Any existing copies remain
unchanged (and truly immutable) because they keep their original storage.

https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift


So with that understanding of COW, it becomes easy to imagine all sorts of
containers that don't require additional storage for their contents:

struct JoinedSequenceOfThreeArrays {
  let array1: [T]
  let array2: [T]
  let array3: [T]
}

// still only one array buffer storage is required for all of this:
let c = JoinedSequenceOfThreeArrays(array1: a, array2: a, array3: b)

Does that make sense?

Geordie


> Le 7 août 2017 à 21:12, Daryle Walker via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I was looking at random items at SwiftDoc.org , and
> noticed the “FlattenBidirectionalCollection” structure. It helps implement
> some versions of “joined” from Sequence (probably when the Sequence is also
> a BidirectionalCollection). The directions for the type state that “joined”
> does not create new storage. Then wouldn’t it have to refer to the source
> objects by reference? How; especially how does it work without requiring a
> “&” with “inout” or how it works with “let”-mode objects? Or am I
> misunderstanding how it works behind the covers?
>
> (If there is a secret sauce to have one object refer to another without
> “&”/“inout”/“UnsafeWhateverPointer”, I like to know. It may help with
> implementing an idea. The idea involves extending the language, so
> “compiler magic” that the user can’t access is OK; I’d just claim to use
> the same sauce in my proposal.)
>
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT 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] Swift 5: start your engines

[Chris Lattner via swift-evolution]

> On Aug 8, 2017, at 3:06 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
>> I imagine that the core team will assist in providing implementations for 
>> proposals that are crucial to the progress of the language and/or highly 
>> popular — regardless of whether the proposal was authored by the core team 
>> or a community member.
>> 
>> From what I know of the team, they’re not going to let a good idea languish 
>> just because of the name that’s in the author field. I’m sure they _are_ 
>> going to strategically prioritize what gets attention, and that’s not a bad 
>> thing.
> 
> Perhaps I'm being overly optimistic but I see this change as enhancing 
> collaboration between idea-level and code-level evolution. Requiring a 
> preliminary implementation:

This change is also intended to strengthen the community in two other ways:

1) a person or organization sufficiently motivated and able to push an effort 
forward can now do it, even if it is outside the scope of Apple’s current 
priorities.

2) it encourages more folks to get involved in implementation tasks, by 
providing an incentive to do so.

Hopefully both of these will lead to a broader and stronger Swift community.

-Chris


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

Re: [swift-evolution] SE-184 Improved Pointers

[Xiaodi Wu via swift-evolution]

This is an excellent document that demonstrates great care and attention.
It addresses pain points discovered through real-world use by a minimum of
well-justified API changes.

The motivating example is compelling, and my only suggestion there is to
show a before-and-after comparison of how the proposed changes will look.

The specific API changes have clearly been refined so many times that I’m
not sure I have much to add. Overall they improve consistency and represent
an improvement.

Bravo!


On Tue, Aug 8, 2017 at 11:53 Taylor Swift via swift-evolution <
swift-evolution@swift.org> wrote:

> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers
> is ready for community review, and I encourage everyone to look it over and
> provide feedback. Thank you!
> <
> https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md
> >
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 5: start your engines

[Erica Sadun via swift-evolution]

> On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> Perhaps I am too optimistic, and core team members correct me if I am 
> speaking out of turn here, but…
> 
> I imagine that the core team will assist in providing implementations for 
> proposals that are crucial to the progress of the language and/or highly 
> popular — regardless of whether the proposal was authored by the core team or 
> a community member.
> 
> From what I know of the team, they’re not going to let a good idea languish 
> just because of the name that’s in the author field. I’m sure they _are_ 
> going to strategically prioritize what gets attention, and that’s not a bad 
> thing.
> 
> Cheers,
> 
> Paul

Perhaps I'm being overly optimistic but I see this change as enhancing 
collaboration between idea-level and code-level evolution. Requiring a 
preliminary implementation:

Ensures a proof of concept that the proposed change (like expanding `Self` to 
classes) is realistic and possible.
Ensures that the Swift codebase impact can be measured at the time the proposal 
is evaluated.
Encourages multi-author proposal teams, comprised of people who understand code 
impact as well those who can express the importance of the language expression 
from a user side. 
Provides real world "road testing" of proposed toolchain enhancements, letting 
the changes be "tuned" before proposal. This minimizes adoption regrets, 
because the beta toolchain can be used with real code. (As with the tuples and 
closures)
Upfront costs *will* be higher. Not only do you have to believe that a change 
is good, you must develop a working group that includes coders to create a 
prototype without any guarantee that the change will pass muster. 

Finding those coders and convincing them this will be a great change means that 
proposals will naturally skew towards Apple-driven rather than wider 
community-driven. However it does not exclude the latter, especially for 
passionate proposals that can find the coders to champion them.

-- Erica

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

Re: [swift-evolution] How does "Sequence.joined" work?

[Daryle Walker via swift-evolution]

> On Aug 8, 2017, at 12:35 AM, Félix Cloutier  wrote:
> 
> All this means is that `joined()` does not create an array that contains the 
> new result. It's only as magic as the COW semantics on arrays.

So you’re saying the COW semantics for Array and other standard library types 
have secret references/pointers that work even for “let”-mode objects, and the 
Sequence variants the various forms of “joined” need use a Sequence/Collection 
of those secret references?

>> Le 7 août 2017 à 21:12, Daryle Walker via swift-evolution 
>> > a écrit :
>> 
>> I was looking at random items at SwiftDoc.org , and 
>> noticed the “FlattenBidirectionalCollection” structure. It helps implement 
>> some versions of “joined” from Sequence (probably when the Sequence is also 
>> a BidirectionalCollection). The directions for the type state that “joined” 
>> does not create new storage. Then wouldn’t it have to refer to the source 
>> objects by reference? How; especially how does it work without requiring a 
>> “&” with “inout” or how it works with “let”-mode objects? Or am I 
>> misunderstanding how it works behind the covers?
>> 
>> (If there is a secret sauce to have one object refer to another without 
>> “&”/“inout”/“UnsafeWhateverPointer”, I like to know. It may help with 
>> implementing an idea. The idea involves extending the language, so “compiler 
>> magic” that the user can’t access is OK; I’d just claim to use the same 
>> sauce in my proposal.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch][Swift 5?] #dup "macro", i.e. Entity Duplication

[Daryle Walker via swift-evolution]

I posted a revision (2) of the entity duplication 
. I added 
the ability to use the index placeholder as a closure anonymous argument, i.e. 
parameterize “$0,” “$1,” etc. with “$($$0).” I thought a direct 
triple-dollar-sign would be confusing, from determining which order the “$” and 
“$$” bind (or if it’s yet another new token).

I don’t think anyone has looked at this yet. I do want it for Swift 5, if 
possible. It’s the dual to variadic parameters/arguments; for producing 
comma-separated lists (instead of consuming), but can be used for non-variadic 
stuff too.  “constexpr” would help, but it’s not necessary. It would complement 
variadic generics, if added.

I want to know if the grammar scheme (the one in the “Grammar” section, not the 
troll version a few paragraphs before) is the good approach. And if the idea is 
even feasible to implement.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Mathew Huusko V via swift-evolution]

Perfect, thanks!

On Tue, Aug 8, 2017 at 7:25 PM, Douglas Gregor  wrote:

> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sorry to revive this, but back on my ABI stability education:
>
>
> [We’re a bit far afield of the original subject, but okay]
>
>
> Swift 5 planning was announced today (woohoo!) with a primary target on
> ABI stability. Finalising generics seems to be a major part of this, with
> "conditional conformances", "recursive protocol requirements," and "there
> are no known other generics enhancements needed for ABI stability" as key
> points.
>
> But it seems like there's quite a bit more left in the generics manifesto
> unimplemented.
>
>
> Right. We’re not going to get to all of this in a year, or two years, and
> we don’t get to block ABI stability on all of the features therein.
>
> Perhaps some of what's in there is controversial, but something like
> generalised existentials afaik *is/was* planned.. can someone explain how
> GE doesn't affect ABI stability?
>
>
> It’s an additive feature, so it doesn’t *change* the ABI per se, it
> extends the ABI to describe something it didn’t describe before. Now, there
> are a few places where we could still run into ABI-compatibility issues
> when adding something new:
>
> * Generalized existentials are a new structural type. An old runtime will
> not understand the type metadata for these types, so we have to deal with
> that in some way. Sometimes we can “implement ahead”, providing support for
> a a feature in the runtime that isn’t surfaced in the language itself yet,
> or we can try to build in future-proof mechanisms for adding more types.
>
> * Generalized existentials could change the way the standard library works
> or is implemented. This is mostly opportunity cost: if we don’t have the
> feature, we’ll have some suboptimal-in-retrospect APIs or implementation
> that’s baked into the standard library. For generalized existentials, we’re
> likely to have some suboptimality with struct AnyCollection, either in the
> implementation (it could wrap a “Collection where .Element == Element”) or
> even in the API itself (maybe the struct should go away and it should be a
> typealias for the corresponding generalized existential).
>
>
> To my very naive mind it's not that different from some other things said
> to affect ABI, and to my slightly less naive mind, I believe it was going
> to enable a protocol oriented approach to KeyPaths in the future, which
> seems like it would affect ABI of stdlib.
>
>
> Every ABI is suboptimal. Once you’ve shipped it, there are some hard
> limits on what you can change (because all of the existing binaries need to
> continue to work), but it’s still possible to make improvements. At worst,
> the improvements only be available on some future OS. Sometimes, one can do
> better by putting more work into the implementation to interoperate with
> other binaries, and often language runtime designers leave themselves hooks
> that allow such improvements in the future. We’ll do some of this in the
> Swift ABI, particularly where we expect change. Engineering trade-offs
> abound, and for generics, we feel like we can tackle what’s been proposed
> already… but not more… and that we can live with the limitations posed by
> that model.
>
> I'm quite sure I'm missing the core concept at this point, so I'd be
> content with my examples being ignored and just pointing me towards a
> general/educational resource on ABI vs. interface thats vaguely compatible
> with Swift.
>
>
> The ABI Dashboard (https://swift.org/abi-stability/) and ABI Manifesto (
> https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md)
> cover some of this.
>
> - Doug
>
>
> Thanks!
>
> On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner  wrote:
>
>>
>> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca <
>> retired.hunter.dj...@gmail.com> wrote:
>> >
>> > I agree with everything you wrote, in particular I agree with the idea
>> that it is more important to get the big efforts right, and that they
>> should take priority. But I would consider a distinction:
>> >
>> > - big efforts that add huge new features to the language so that things
>> that were done in userland with libraries can be done natively and
>> idiomatically (concurrent programming, for example);
>> > - more "theoretical" big efforts, that allow one, while building a
>> single app or a big library, to "express" more things more precisely in the
>> language, and improvements to the generics and protocols systems fall in
>> this second realm;
>> >
>> > The reason why I consider the second kind of feature as more important
>> than the first (thus, earning higher priority) is that, apart from reducing
>> the amount of busywork to be done in many cases where the abstraction power
>> is not good enough, it gives more tools for the community to build upon, it
>> allows many people to do more 

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Douglas Gregor via swift-evolution]

> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> Sorry to revive this, but back on my ABI stability education:

[We’re a bit far afield of the original subject, but okay]

> 
> Swift 5 planning was announced today (woohoo!) with a primary target on ABI 
> stability. Finalising generics seems to be a major part of this, with 
> "conditional conformances", "recursive protocol requirements," and "there are 
> no known other generics enhancements needed for ABI stability" as key points.
> 
> But it seems like there's quite a bit more left in the generics manifesto 
> unimplemented.

Right. We’re not going to get to all of this in a year, or two years, and we 
don’t get to block ABI stability on all of the features therein.

> Perhaps some of what's in there is controversial, but something like 
> generalised existentials afaik *is/was* planned.. can someone explain how GE 
> doesn't affect ABI stability?

It’s an additive feature, so it doesn’t *change* the ABI per se, it extends the 
ABI to describe something it didn’t describe before. Now, there are a few 
places where we could still run into ABI-compatibility issues when adding 
something new:

* Generalized existentials are a new structural type. An old runtime will not 
understand the type metadata for these types, so we have to deal with that in 
some way. Sometimes we can “implement ahead”, providing support for a a feature 
in the runtime that isn’t surfaced in the language itself yet, or we can try to 
build in future-proof mechanisms for adding more types.

* Generalized existentials could change the way the standard library works or 
is implemented. This is mostly opportunity cost: if we don’t have the feature, 
we’ll have some suboptimal-in-retrospect APIs or implementation that’s baked 
into the standard library. For generalized existentials, we’re likely to have 
some suboptimality with struct AnyCollection, either in the implementation (it 
could wrap a “Collection where .Element == Element”) or even in the API itself 
(maybe the struct should go away and it should be a typealias for the 
corresponding generalized existential).


> To my very naive mind it's not that different from some other things said to 
> affect ABI, and to my slightly less naive mind, I believe it was going to 
> enable a protocol oriented approach to KeyPaths in the future, which seems 
> like it would affect ABI of stdlib.

Every ABI is suboptimal. Once you’ve shipped it, there are some hard limits on 
what you can change (because all of the existing binaries need to continue to 
work), but it’s still possible to make improvements. At worst, the improvements 
only be available on some future OS. Sometimes, one can do better by putting 
more work into the implementation to interoperate with other binaries, and 
often language runtime designers leave themselves hooks that allow such 
improvements in the future. We’ll do some of this in the Swift ABI, 
particularly where we expect change. Engineering trade-offs abound, and for 
generics, we feel like we can tackle what’s been proposed already… but not 
more… and that we can live with the limitations posed by that model.

> I'm quite sure I'm missing the core concept at this point, so I'd be content 
> with my examples being ignored and just pointing me towards a 
> general/educational resource on ABI vs. interface thats vaguely compatible 
> with Swift.

The ABI Dashboard (https://swift.org/abi-stability/ 
) and ABI Manifesto 
(https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md 
) 
cover some of this.

- Doug

> 
> Thanks!
> 
> On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner  > wrote:
> 
> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca  > > wrote:
> >
> > I agree with everything you wrote, in particular I agree with the idea that 
> > it is more important to get the big efforts right, and that they should 
> > take priority. But I would consider a distinction:
> >
> > - big efforts that add huge new features to the language so that things 
> > that were done in userland with libraries can be done natively and 
> > idiomatically (concurrent programming, for example);
> > - more "theoretical" big efforts, that allow one, while building a single 
> > app or a big library, to "express" more things more precisely in the 
> > language, and improvements to the generics and protocols systems fall in 
> > this second realm;
> >
> > The reason why I consider the second kind of feature as more important than 
> > the first (thus, earning higher priority) is that, apart from reducing the 
> > amount of busywork to be done in many cases where the abstraction power is 
> > not good enough, it gives more tools for the 

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Michael Ilseman via swift-evolution]

The key difference is whether such things can be rolled out in the future in an 
additive way, potentially with extra compatibility affordances, vs whether 
something is inherent to the ABI as Swift and the standard library currently 
exists. This is a very fuzzy line, and is constantly getting reevaluated. But, 
generics features that change fundamental standard library internals such as 
Collection’s associated types fall more on the affects-current-ABI side of 
things, while additions that expose potential for new and better APIs fall on 
the ABI-additive side of things. 

New and improved existential-backed APIs can be added while keeping around (or 
even deprecating) the older ones, but existing protocol hierarchies and their 
associated types can’t be easily uprooted. I apologize that this doesn’t shed a 
ton of light on the difference, but these things exist on a case-by-case basis.



> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> Sorry to revive this, but back on my ABI stability education:
> 
> Swift 5 planning was announced today (woohoo!) with a primary target on ABI 
> stability. Finalising generics seems to be a major part of this, with 
> "conditional conformances", "recursive protocol requirements," and "there are 
> no known other generics enhancements needed for ABI stability" as key points.
> 
> But it seems like there's quite a bit more left in the generics manifesto 
> unimplemented. Perhaps some of what's in there is controversial, but 
> something like generalised existentials afaik *is/was* planned.. can someone 
> explain how GE doesn't affect ABI stability?
> To my very naive mind it's not that different from some other things said to 
> affect ABI, and to my slightly less naive mind, I believe it was going to 
> enable a protocol oriented approach to KeyPaths in the future, which seems 
> like it would affect ABI of stdlib.
> 
> I'm quite sure I'm missing the core concept at this point, so I'd be content 
> with my examples being ignored and just pointing me towards a 
> general/educational resource on ABI vs. interface thats vaguely compatible 
> with Swift.
> 
> Thanks!
> 
> On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner  > wrote:
> 
> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca  > > wrote:
> >
> > I agree with everything you wrote, in particular I agree with the idea that 
> > it is more important to get the big efforts right, and that they should 
> > take priority. But I would consider a distinction:
> >
> > - big efforts that add huge new features to the language so that things 
> > that were done in userland with libraries can be done natively and 
> > idiomatically (concurrent programming, for example);
> > - more "theoretical" big efforts, that allow one, while building a single 
> > app or a big library, to "express" more things more precisely in the 
> > language, and improvements to the generics and protocols systems fall in 
> > this second realm;
> >
> > The reason why I consider the second kind of feature as more important than 
> > the first (thus, earning higher priority) is that, apart from reducing the 
> > amount of busywork to be done in many cases where the abstraction power is 
> > not good enough, it gives more tools for the community to build upon, it 
> > allows many people to do more with the language than probably me, you and 
> > the core team have ever though of, it fosters the explosion of creativity 
> > that's only possible when a language is expressive enough and it's not only 
> > based on certain conventions (that, by definition, constraint the way a 
> > language is commonly used).
> 
> MHO is that both are important.  I think the details of the tradeoffs 
> involved prioritizing the individual members of those categories are bigger 
> than the difference between the two categories.  I don’t think this is a 
> useful way to try to slice the problem up.
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

[Ross O'Brien via swift-evolution]

I would like to add something to this discussion on casting generics.

I think there is a temptation to think of generic types as having a
protocol-like aspect. If String conforms to Any, then a [String] ought to
conform to [Any]; the current scope may think of the variable as being a
[Any] even though it is really a [String] and should only accept Strings as
elements. Similarly I shouldn't have to care what the element type is, if
all I want from the array is its count.

I think generic types can be complicated, particularly if they have
multiple generic components. I'm not sure that covariance and
contravariance, if I'm using those terms right, should be implicit for all
generic types.

However, I think it should be possible to explicitly make covariance or
contravariance easier to achieve for certain types.

Practically, what I'm getting at in Swift is this: 'as' and 'as?' are
keywords in Swift, but in a way they're used as operators, and it isn't
possible to write custom implementations.

For the sake of example: I am writing a Stack. It likely has an
array as a private property but it has other properties as well. I wish to
cast a Stack as a Stack. I cannot; they're two different
types. The best I can do is write an init function for Stack which takes
another Stack as an argument. The initialiser will have generic constraints
because I'm using a Stack as an argument to produce a Stack. When
this initialiser gets called, the caller will be very clear on what type
they are declaring B to be, so the new Stack can establish its Element type.

However, the compiler would not see a problem in using a Stack as an
argument to initialising a Stack. I can write code in my
initialiser, testing that each element of type A in the Stack is of type
B, and I can make my initialiser failable or throws if an A not castable to
B is found, but the compiler cannot enforce the generic constraint that A :
B, or B : A. (As of Swift 4, the A : B relationship could mean that A is a
subclass of B, A conforms to B, or both.)

I would be interested in allowing the following function call as a generic
constraint, so that casting generic types can be made easier:

func convert(from: Stack) -> Stack where A : B

Is this a possibility?


On Tue, Aug 8, 2017 at 2:52 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 8, 2017, at 06:38, Karl Wagner  wrote:
>
>
> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> One of my longstanding frustrations with generic types and protocols has
> been how hard it is to work with them when their type is unspecified.
> Often I find myself wishing that I could write a function that takes a
> generic type or protocol as a parameter, but doesn’t care what its generic
> type is.
>
> For example, if I have a type:
>
> struct Foo {
> let name: String
> let value: T
> }
>
> or:
>
> protocol Foo {
> associatedtype T
> var name: String { get }
> var value: T { get }
> }
>
> And I want to write a function that only cares about Foo.name, I’d like to
> be able to:
>
> func sayHi(to foo: Foo) {
> print("hi \(foo.name)")
> }
>
> But instead I get the error, “Reference to generic type Foo requires
> arguments in <…>”
>
> Also, when you want to have a polymorphic array of generic types, you
> can’t:
>
> let foos: [Foo] = [Foo(name: "Int", value: 2), Foo(name: "Double", value:
> 2.0)]
>
> And if you remove the explicit type coercion, you just get [Any]
>
> let foos = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 2.0)]
>
> I wish that could be inferred to be [Foo].
>
>
> What happens if you try to say "foos: [Foo] = ..."?
>
>
> Foo and Foo are very different. Otherwise, you could take a
> Foo, cast it to a Foo and set a String as its value.
>
> I think what he means are partial generics, e.g: Foo<_>.
>
>
> Oh I know, I just couldn't remember if it'd work as long as you didn't
> mess with the generic bits.
>
> - Dave Sweeris
>
> ___
> 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] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Mathew Huusko V via swift-evolution]

Sorry to revive this, but back on my ABI stability education:

Swift 5 planning was announced today (woohoo!) with a primary target on ABI
stability. Finalising generics seems to be a major part of this, with
"conditional conformances", "recursive protocol requirements," and "there
are no known other generics enhancements needed for ABI stability" as key
points.

But it seems like there's quite a bit more left in the generics manifesto
unimplemented. Perhaps some of what's in there is controversial, but
something like generalised existentials afaik *is/was* planned.. can
someone explain how GE doesn't affect ABI stability?
To my very naive mind it's not that different from some other things said
to affect ABI, and to my slightly less naive mind, I believe it was going
to enable a protocol oriented approach to KeyPaths in the future, which
seems like it would affect ABI of stdlib.

I'm quite sure I'm missing the core concept at this point, so I'd be
content with my examples being ignored and just pointing me towards a
general/educational resource on ABI vs. interface thats vaguely compatible
with Swift.

Thanks!

On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner  wrote:

>
> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca <
> retired.hunter.dj...@gmail.com> wrote:
> >
> > I agree with everything you wrote, in particular I agree with the idea
> that it is more important to get the big efforts right, and that they
> should take priority. But I would consider a distinction:
> >
> > - big efforts that add huge new features to the language so that things
> that were done in userland with libraries can be done natively and
> idiomatically (concurrent programming, for example);
> > - more "theoretical" big efforts, that allow one, while building a
> single app or a big library, to "express" more things more precisely in the
> language, and improvements to the generics and protocols systems fall in
> this second realm;
> >
> > The reason why I consider the second kind of feature as more important
> than the first (thus, earning higher priority) is that, apart from reducing
> the amount of busywork to be done in many cases where the abstraction power
> is not good enough, it gives more tools for the community to build upon, it
> allows many people to do more with the language than probably me, you and
> the core team have ever though of, it fosters the explosion of creativity
> that's only possible when a language is expressive enough and it's not only
> based on certain conventions (that, by definition, constraint the way a
> language is commonly used).
>
> MHO is that both are important.  I think the details of the tradeoffs
> involved prioritizing the individual members of those categories are bigger
> than the difference between the two categories.  I don’t think this is a
> useful way to try to slice the problem up.
>
> -Chris
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 5: start your engines

[Adrian Zubarev via swift-evolution]

Thank you for the kind updates Ted. However I already feel the negative impact 
because of the last restriction. I also would like to point out that, 
personally I think until the swift-evolution is not moved to a forum this will 
only create a great wall between proposal authors and people that are capable 
of implementing the pitched functionality. However I see your point there, I’ve 
also seen Slava Pestov pointing this out a couple of times before, and I fully 
understand the main idea behind it. However, my main point is that it would be 
really hard now to find volunteers who can implement new functionality before 
we can even review something. For instance we’ve got a quite complex proposal 
that didn’t made it in to Swift 3 in time and was deferred from Swift 4, which 
aimed to fix metatypes in Swift. I can only speak for myself and not the other 
two authors of our proposal, but I won’t be able to provide an implementation 
for that proposal, because I’m not a complier engineer and probably won’t 
become one any time soon. Long story short the last restriction makes it really 
hard for me to participate in swift-evolution process except for providing 
feedback in active reviews.


Am 8. August 2017 um 18:24:25, Ted Kremenek via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is now 
in endgame engineering convergence for an expected release later this year.  
Swift 4 has turned out to be one of the highest quality, well-rounded releases 
of Swift, and I am grateful to everyone in the community who made this release 
come together!

Now it is time to turn our attention to Swift 5.  I have just posted updates to 
the README.md file on the swift-evolution repository, which outlines the core 
themes and focus areas for Swift 5:

  https://github.com/apple/swift-evolution

and a more persistent URL (invariant to future README.md changes):

  
https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md

I am not going to repeat all of that information here, but I wanted to 
highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of 
our prioritization of efforts for Swift 5 around it.  With Swift 4, ABI 
stability was a strong goal.  In Swift 5, it is a *requirement* of the release. 
 Whatever ABI we have at the end of Swift 5 is the ABI that we will have.  ABI 
stability is an important inflection point for the maturity of the language, 
and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module 
stability.   If you are not aware of the difference — which is rather important 
— please read the first few paragraphs of the ABI stability manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

Module stability is a stretch goal for Swift 5, but even without module 
stability we can still achieve the primary value of ABI stability.

##  Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, 
but there is a general theme of refining and broadening out the core ergonomics 
of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for 
concurrency.  It is a non-goal of Swift 5 to roll out a full new concurrency 
model.  That is simply too large an effort to do alongside ABI stability.  
However, it is important that we start making progress on discussing the 
directions for concurrency and laying some of the groundwork.  This may take 
the form of specific enhancements to the language that get implemented, 
depending on where the discussions for concurrency lead and how they align with 
the priorities for delivering ABI stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  https://github.com/apple/swift-evolution#evolution-process-for-swift-5

With Swift 4, the release period was divided up into “stage 1” and “stage 2” 
for setting guidelines for the kind of evolution proposals that were in scope 
for the release.  This was needed to establish focus — especially after the 
churn we saw during Swift 3 — on some core themes that were aligned with 
converging the language towards source & ABI stability.  One downside is that 
“stage 2” opened up discussion for potentially disruptive changes fairly late 
in the release.  Further, some proposals — such as SE-0155 — came in so late 
that there was little runway to actually implement them for Swift 4, let alone 
evaluate their impact in practice on real projects.  Related, there has been 
some desire  for a while to be able to better evaluate the impact of proposals 
on real code before they are locked into the release, and the best way to do 
that is to 

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Chris Lattner via swift-evolution]

> On Aug 7, 2017, at 11:34 PM, Elviro Rocca  
> wrote:
> 
> I agree with everything you wrote, in particular I agree with the idea that 
> it is more important to get the big efforts right, and that they should take 
> priority. But I would consider a distinction:
> 
> - big efforts that add huge new features to the language so that things that 
> were done in userland with libraries can be done natively and idiomatically 
> (concurrent programming, for example);
> - more "theoretical" big efforts, that allow one, while building a single app 
> or a big library, to "express" more things more precisely in the language, 
> and improvements to the generics and protocols systems fall in this second 
> realm;
> 
> The reason why I consider the second kind of feature as more important than 
> the first (thus, earning higher priority) is that, apart from reducing the 
> amount of busywork to be done in many cases where the abstraction power is 
> not good enough, it gives more tools for the community to build upon, it 
> allows many people to do more with the language than probably me, you and the 
> core team have ever though of, it fosters the explosion of creativity that's 
> only possible when a language is expressive enough and it's not only based on 
> certain conventions (that, by definition, constraint the way a language is 
> commonly used).

MHO is that both are important.  I think the details of the tradeoffs involved 
prioritizing the individual members of those categories are bigger than the 
difference between the two categories.  I don’t think this is a useful way to 
try to slice the problem up.

-Chris

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

[swift-evolution] SE-184 Improved Pointers

[Taylor Swift via swift-evolution]

Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is
ready for community review, and I encourage everyone to look it over and
provide feedback. Thank you!
<
https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 5: start your engines

[Ted Kremenek via swift-evolution]

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is now 
in endgame engineering convergence for an expected release later this year.  
Swift 4 has turned out to be one of the highest quality, well-rounded releases 
of Swift, and I am grateful to everyone in the community who made this release 
come together!

Now it is time to turn our attention to Swift 5.  I have just posted updates to 
the README.md file on the swift-evolution repository, which outlines the core 
themes and focus areas for Swift 5:

  https://github.com/apple/swift-evolution 


and a more persistent URL (invariant to future README.md changes):

  
https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md
 


I am not going to repeat all of that information here, but I wanted to 
highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of 
our prioritization of efforts for Swift 5 around it.  With Swift 4, ABI 
stability was a strong goal.  In Swift 5, it is a *requirement* of the release. 
 Whatever ABI we have at the end of Swift 5 is the ABI that we will have.  ABI 
stability is an important inflection point for the maturity of the language, 
and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module 
stability.   If you are not aware of the difference — which is rather important 
— please read the first few paragraphs of the ABI stability manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md 


Module stability is a stretch goal for Swift 5, but even without module 
stability we can still achieve the primary value of ABI stability.

##  Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, 
but there is a general theme of refining and broadening out the core ergonomics 
of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for 
concurrency.  It is a non-goal of Swift 5 to roll out a full new concurrency 
model.  That is simply too large an effort to do alongside ABI stability.  
However, it is important that we start making progress on discussing the 
directions for concurrency and laying some of the groundwork.  This may take 
the form of specific enhancements to the language that get implemented, 
depending on where the discussions for concurrency lead and how they align with 
the priorities for delivering ABI stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  https://github.com/apple/swift-evolution 
#evolution-process-for-swift-5 


With Swift 4, the release period was divided up into “stage 1” and “stage 2” 
for setting guidelines for the kind of evolution proposals that were in scope 
for the release.  This was needed to establish focus — especially after the 
churn we saw during Swift 3 — on some core themes that were aligned with 
converging the language towards source & ABI stability.  One downside is that 
“stage 2” opened up discussion for potentially disruptive changes fairly late 
in the release.  Further, some proposals — such as SE-0155 — came in so late 
that there was little runway to actually implement them for Swift 4, let alone 
evaluate their impact in practice on real projects.  Related, there has been 
some desire  for a while to be able to better evaluate the impact of proposals 
on real code before they are locked into the release, and the best way to do 
that is to actually have an implementation that vets out the design in a 
proposal.

With Swift 5, the focus on ABI stability will predominate priorities for both 
design and implementation work, but the Core Team did not want that focus to 
stifle all discussion on potential enhancements to the language that were not 
fundamentally tied to that primary goal.  After reflecting on the evolution 
process during both the Swift 3 and Swift 4 releases, the Core Team felt that 
we could strike a balance with not diluting attention from ABI stability while 
still enabling a broader range of proposals compared to Swift 4 by **requiring 
that all proposals have an implementation** before they are officially reviewed 
by the Core Team.  An implementation can come long after an idea has been 
pitched and after a proposal has been written.  However, before a pull request 
for an evolution proposal will be accepted — and thus an official review 
scheduled — an implementation 

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

[David Sweeris via swift-evolution]

> On Aug 8, 2017, at 06:38, Karl Wagner  wrote:
> 
> 
>>> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution 
>>>  wrote:
>>> 
>>> One of my longstanding frustrations with generic types and protocols has 
>>> been how hard it is to work with them when their type is unspecified.
>>> Often I find myself wishing that I could write a function that takes a 
>>> generic type or protocol as a parameter, but doesn’t care what its generic 
>>> type is.
>>> 
>>> For example, if I have a type:
>>> 
>>> struct Foo {
>>> let name: String
>>> let value: T
>>> }
>>> 
>>> or:
>>> 
>>> protocol Foo {
>>> associatedtype T
>>> var name: String { get }
>>> var value: T { get }
>>> }
>>> 
>>> And I want to write a function that only cares about Foo.name, I’d like to 
>>> be able to:
>>> 
>>> func sayHi(to foo: Foo) {
>>> print("hi \(foo.name)")
>>> }
>>> 
>>> But instead I get the error, “Reference to generic type Foo requires 
>>> arguments in <…>”
>>> 
>>> Also, when you want to have a polymorphic array of generic types, you can’t:
>>> 
>>> let foos: [Foo] = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 
>>> 2.0)]
>>> 
>>> And if you remove the explicit type coercion, you just get [Any]
>>> 
>>> let foos = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 2.0)]
>>> 
>>> I wish that could be inferred to be [Foo].
>> 
>> What happens if you try to say "foos: [Foo] = ..."? 
>> 
> 
> Foo and Foo are very different. Otherwise, you could take a 
> Foo, cast it to a Foo and set a String as its value.
> 
> I think what he means are partial generics, e.g: Foo<_>.

Oh I know, I just couldn't remember if it'd work as long as you didn't mess 
with the generic bits.

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

Re: [swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

[Tino Heth via swift-evolution]

> Fixed-size arrays do not solve this particular issue that I've noted above.
And I didn't say so ;-)
But generic value parameters would not only allow you to define fixed-size 
arrays, but also arrays with certain other properties:
Minimal size, maximal size… maybe even number of elements or other more 
complicated things.
(that is one reason why I think this is the best approach — its more versatile 
than the alternative)

I really hope that you find supporters for non-empty arrays - that would also 
be a strong motivation to add subtyping for arrays ;-) (struct NonEmptyArray: 
Array)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

[Charlie Monroe via swift-evolution]

I had a similar though some time ago (and even suggested it here) - as e.g. 
"Hello".components(separatedBy: "123") will always produce a non-empty array. 
Even "".components(separatedBy: "") is [""].

Which would allow e.g. first, last and some other members to loose the 
optionality - which would be great. But would probably add unnecessary 
complexity to the stdlib.

Fixed-size arrays do not solve this particular issue that I've noted above.

> On Aug 8, 2017, at 1:39 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> I think it would make sense to have arrays with a minimal size, but wouldn't 
> consider it very important.
> But there is a long-running discussion about fixed-size arrays, and depending 
> on (if any) solution is chosen for them, your use case could be solved rather 
> easy as well.
> ___
> 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] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

[Logan Shire via swift-evolution]

You would have this guarantee with the fixed-size arrays currently being 
discussed. 
Perhaps this could be an amendment to that proposal - you could declare an 
array with bounds for its size.
Fixed-size arrays would be a subset of those where the upper and lower bounds 
are equal.
They could also offer non-opitional ‘first’ and ‘last’ properties, which, if 
the bounds are fixed,
could use the tuple .0, .1, etc syntax.

> This isn't a fully formed pitch, and maybe already discussed, but...
> 
> If we have have optionals and non-optionals, shouldn't we also have a way to 
> declare that an Array never be empty? It seems like this would naturally lead 
> to more elegant designs.
> 
> Here's a use-case:
> 
> struct Wavelet {
> var buff: [Double]
> var sign: Sign
> var peak:Double{
> returnbuff.find_max()! //<-- Yuck!
> }
> }
> 
> 
> In my app, I never want to create an empty "buff" here. If I could declare 
> that the Array always contain at least 1 element, I wouldn't need to worry 
> about a whole bunch of unwrapping elsewhere in my program. Native ability to 
> do this would also be handy to store chunks of memory, too?
> 
> Would this be worthwhile?
> 
> 
> 
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch?] Way to declare a Swift Array that guarantees it can't be empty

[Tino Heth via swift-evolution]

I think it would make sense to have arrays with a minimal size, but wouldn't 
consider it very important.
But there is a long-running discussion about fixed-size arrays, and depending 
on (if any) solution is chosen for them, your use case could be solved rather 
easy as well.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

[Logan Shire via swift-evolution]

I see what you're saying, and I agree that this is more of a half-measure.
But the benefit of this approach is that it's pretty trivial to implement,
and the language features it introduces could be reimplemented with
existentialists when they become available. I think advancing the syntax of
the language to improve usability in the near term is worthwhile. If this
syntax would not be supported by the existential approach I think that
would be a different story.

Also, I think this could go hand-in-hand with a syntax for types that are
protocols with their associated type fulfilled, e.g.

let grassEater = animal as? AnimalProtocol where Food = Grass

or:

let grassEater = animal as? AnimalProtocol

These grassEater values could then be used just like any other value.
On Tue, Aug 8, 2017 at 11:14 AM Elviro Rocca 
wrote:

> To my understanding, the following is exactly as it should be:
>
> FooStruct as? FooStruct // Compiles but conversion fails,
> becomes nil, and that's normal
>
> The reason for this is that FooStruct is not a subtype of
> FooStruct (or just FooStruct), while String is of course a subtype of
> Any, because generic types are not covariant in Swift, and that's the way
> it should be for a sound static type system. My comments on this were
> related to what you wrote about  arrays.
>
> In theory a protocol without associated types could be synthesized for all
> the non generic properties and methods of a generic type, with the ability
> of casting to it and possibly from it.
>
> It's a useful idea, and I'm all for it (I think literally everyone that
> uses generics and protocols with associated types encountered these kinds
> of problems at least once), I'm just saying that I'd rather work on
> generalized existentials which have already been considered by the core
> team, at least from a theoretical standpoint, have a greater scope and
> include cases like this. In general I tend to prefer broader, more generic
> solutions rooted in type theory when dealing with generics and protocols,
> but that's just me.
>
>
> Elviro
>
>
> Il giorno 08 ago 2017, alle ore 10:44, Logan Shire via swift-evolution <
> swift-evolution@swift.org> ha scritto:
>
> Thanks for the feedback!
>
> Félix, sorry about the confusion between FooStruct and FooProtocol - I'll
> refer to them as such moving forwards.
>
> David, I don't believe you should be able to cast an [FooStruct]
> to an [FooStruct] because those are both valid specifications. If 
> Generalized
> Existentials
> 
>  are
> implemented, that would be another story, but that's outside the scope of
> this proposal. I do believe you should be able to cast [FooStruct]
> to [FooStruct], and that you should be able to flatMap [FooStruct] into
> [FooStruct] with as?, but all of the casts would fail and you would be
> left with an empty array.
>
> In regards to the Named protocol, yes, that is the current idiomatic
> approach to solving this problem (along with making a function
> unnecessarily generic and then using the generic type as a constraint). I
> want to avoid jumping through those hoops. We'd essentially be synthesizing
> the Named protocol with the same name as the non-generic version of the
> type. I.e. FooStruct: FooStruct
>
> Félix, I believe the above answers some of your questions, but in regards
> to protocols with associated types, I'd imagine it would work the same way.
> If FooProtocol has an associated type T, there would be another protocol,
> FooProtocol, without the associated type. (behind the scenes its garbled
> name would be different)
>
> Also, an aside, it would be nice if protocols could use the generic syntax
> for their associated type constraints. I.e. "FooProtocol with T = Int"
> could be expressed as FooProtocol. It feels strange that we have
> two different syntaxes for essentially the same language construct. At the
> very least, I want some way to cast a value to a protocol type with an
> associated value. E.g. "if let grassEater = any as? Animal where Food =
> Grass"
>
> Elviro, yes, the generalized existentials would help a lot here, but
> that's outside the scope of what I'm proposing. In the near term I'd like
> to be able to use a generic type's non-generic interface, casting to and
> from it. See the above discussion regarding the Named protocol. Essentially
> we'd be synthesizing the Named protocol, but where the type's name is the
> same as the non-generic version of the type name.
>
> FooStruct as FooStruct // works
> FooStruct as? FooStruct // works
> FooStruct as? FooStruct // Compiles but conversion fails, becomes nil
> FooStruct as? FooStruct // Compiles but conversion fails,
> becomes nil
>
> Let me know if you have any other questions!
>
> Logan
>
>
> On Tue, Aug 8, 2017 at 9:43 AM Félix Cloutier 
> wrote:
>
>> I'm going to separate your examples into FooStruct 

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

[Elviro Rocca via swift-evolution]

Covariant generic types make for an unsound type system. I believe the reason 
why Array and Optional are covariant in their generic parameter is that the way 
their implementation interacts with their internal storage assures that new 
storage is created if types mismatch: this means that to make covariance work 
for generic types you have to be extra careful when using references, because 
it doesn't really make sense from a mathematical standpoint (from my 
understanding of the matter).

What could probably be useful in your case is the concept of "generalized 
existential", which is considered in the generics manifesto ( 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials
 

 ) and I believe is something that will eventually be added to Swift in the 
future because many use cases have come up in the mailing list over time: for 
example smart KeyPaths were implemented with classes instead of structs and 
protocols because of the lack of generalized existentials in the language.


Elviro   


> Il giorno 08 ago 2017, alle ore 00:00, Logan Shire via swift-evolution 
>  ha scritto:
> 
> One of my longstanding frustrations with generic types and protocols has been 
> how hard it is to work with them when their type is unspecified.
> Often I find myself wishing that I could write a function that takes a 
> generic type or protocol as a parameter, but doesn’t care what its generic 
> type is.
> 
> For example, if I have a type:
> 
> struct Foo {
> let name: String
> let value: T
> }
> 
> or:
> 
> protocol Foo {
> associatedtype T
> var name: String { get }
> var value: T { get }
> }
> 
> And I want to write a function that only cares about Foo.name, I’d like to be 
> able to:
> 
> func sayHi(to foo: Foo) {
> print("hi \(foo.name)")
> }
> 
> But instead I get the error, “Reference to generic type Foo requires 
> arguments in <…>”
> 
> Also, when you want to have a polymorphic array of generic types, you can’t:
> 
> let foos: [Foo] = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 
> 2.0)]
> 
> And if you remove the explicit type coercion, you just get [Any]
> 
> let foos = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 2.0)]
> 
> I wish that could be inferred to be [Foo]. I’d like to propose being able to 
> use the non-generic interface of a type normally. 
> I.e. if you have a type Foo, it is implicitly of type Foo as well. The 
> type Foo could be used like any other type.
> It could be a parameter in a function, a variable, or even the generic type 
> of another type (like a Dictionary)
> 
> The only restriction is that if you want to call or access, directly or 
> indirectly, a function or member that requires the generic type,
> the generic type would have to be known at that point.
> 
> Foo should be able to be implicitly casted to Foo wherever you want, and 
> Foo could be cast to Foo conditionally.
> Initializers would still obviously have to know the generic type, but given 
> the above example, you should be able to:
> 
> let names = foos.map { $0.name }
> 
> However, you could not do the following:
> 
> let foos = [Foo]()
> 
> Because the initializer would need to know the generic type in order to 
> allocate the memory.
> 
> Let me know what you think!
> 
> —
> 
> Logan Shire
> iOS @ Lyft
> 
> ___
> 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] Improving unspecified generic usability

[Félix Cloutier via swift-evolution]

I'm going to separate your examples into FooStruct and FooProtocol for clarity.

I agree that generics tend to propagate virally and I remember that at some 
point I wanted type erasure, though I don't remember for what exactly. The 
solution for `sayHi`, right now, is to make that one generic too:

> func sayHi(to foo: T) where T: FooProtocol {
> print("hi \(foo.name)")
> }

The "let foos: [FooStruct] = [FooStruct(name: "Int", value: 2), FooStruct(name: 
"Double", value: 2.0)]" part can't work for structs because arrays require each 
element to have the same size (but it could work for classes).

Even then, you couldn't infer the type to [FooClass] because 
contravariance isn't permissible in that situation: doing so would allow you to 
assign any Any to a FooClass's value.

Another problem that this would have to solve is that once you lose the 
associatedtype that came with the protocol, there is nothing you can do to 
recover it; you currently can't express "FooProtocol with T = Int" as a type 
that you can cast to, so you would only be able to pass the instance to 
functions that don't have constraints on T.

But all in all, with my current understanding of the issue, I think that I'm 
favorable to the idea.

Félix

> Le 7 août 2017 à 19:35, David Sweeris via swift-evolution 
>  a écrit :
> 
>> 
>> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution 
>> > wrote:
>> 
>> One of my longstanding frustrations with generic types and protocols has 
>> been how hard it is to work with them when their type is unspecified.
>> Often I find myself wishing that I could write a function that takes a 
>> generic type or protocol as a parameter, but doesn’t care what its generic 
>> type is.
>> 
>> For example, if I have a type:
>> 
>> struct Foo {
>> let name: String
>> let value: T
>> }
>> 
>> or:
>> 
>> protocol Foo {
>> associatedtype T
>> var name: String { get }
>> var value: T { get }
>> }
>> 
>> And I want to write a function that only cares about Foo.name, I’d like to 
>> be able to:
>> 
>> func sayHi(to foo: Foo) {
>> print("hi \(foo.name)")
>> }
>> 
>> But instead I get the error, “Reference to generic type Foo requires 
>> arguments in <…>”
>> 
>> Also, when you want to have a polymorphic array of generic types, you can’t:
>> 
>> let foos: [Foo] = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 
>> 2.0)]
>> 
>> And if you remove the explicit type coercion, you just get [Any]
>> 
>> let foos = [Foo(name: "Int", value: 2), Foo(name: "Double", value: 2.0)]
>> 
>> I wish that could be inferred to be [Foo].
> 
> What happens if you try to say "foos: [Foo] = ..."? 
> 
> 
> 
>> I’d like to propose being able to use the non-generic interface of a type 
>> normally. 
>> I.e. if you have a type Foo, it is implicitly of type Foo as well. The 
>> type Foo could be used like any other type.
>> It could be a parameter in a function, a variable, or even the generic type 
>> of another type (like a Dictionary)
>> 
>> The only restriction is that if you want to call or access, directly or 
>> indirectly, a function or member that requires the generic type,
>> the generic type would have to be known at that point.
>> 
>> Foo should be able to be implicitly casted to Foo wherever you want, and 
>> Foo could be cast to Foo conditionally.
>> Initializers would still obviously have to know the generic type, but given 
>> the above example, you should be able to:
>> 
>> let names = foos.map { $0.name }
>> 
>> However, you could not do the following:
>> 
>> let foos = [Foo]()
>> 
>> Because the initializer would need to know the generic type in order to 
>> allocate the memory.
>> 
>> Let me know what you think!
> 
> 
> The idiomatic solution would be to create a `Named` protocol with a `var 
> name: String {get}` property, and write your function like `func sayHi(to 
> foo:Named) {...}`. However, this `Named`protocol is really pretty trivial -- 
> its purpose is simply to "degenericify" a generic type, not to provide any 
> semantic meaning. Perhaps an analogy could be drawn between such "trivial 
> protocols" and how we sometimes view tuples as "trivial structs"? Dunno, 
> maybe I'm just trying to turn two trees into a forest, but this kinda smells 
> like it might be part of a bigger issue, and if it is I'd rather tackle that 
> and then see if we still need to address anything here.
> 
> +1, either way, though.
> 
> - Dave Sweeris
> ___
> 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] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Elviro Rocca via swift-evolution]

I agree with everything you wrote, in particular I agree with the idea that it 
is more important to get the big efforts right, and that they should take 
priority. But I would consider a distinction:

- big efforts that add huge new features to the language so that things that 
were done in userland with libraries can be done natively and idiomatically 
(concurrent programming, for example);
- more "theoretical" big efforts, that allow one, while building a single app 
or a big library, to "express" more things more precisely in the language, and 
improvements to the generics and protocols systems fall in this second realm;

The reason why I consider the second kind of feature as more important than the 
first (thus, earning higher priority) is that, apart from reducing the amount 
of busywork to be done in many cases where the abstraction power is not good 
enough, it gives more tools for the community to build upon, it allows many 
people to do more with the language than probably me, you and the core team 
have ever though of, it fosters the explosion of creativity that's only 
possible when a language is expressive enough and it's not only based on 
certain conventions (that, by definition, constraint the way a language is 
commonly used).

What do you think?

Thanks


Elviro

> Il giorno 07 ago 2017, alle ore 18:11, Chris Lattner  ha 
> scritto:
> 
> 
>> On Aug 7, 2017, at 12:43 AM, Elviro Rocca  
>> wrote:
>> 
>> I read many times the "most users don't care about this" objection but I 
>> always considered it more like an argument for postponing something than 
>> removing it completely from the Swift equation (I believe I also read words 
>> like that from yourself, Chris), because there is a point about scheduling 
>> work to make the language more useful for more people faster. I'm still 
>> acting upon the belief that the Swift core team recognizes that the language 
>> still lacks a lot of absolutely basic and essential features, that every 
>> "power user" that pushes the boundaries of what Swift has to offer can't 
>> wait for to be added.
> 
> Yes, there is a really huge amount of stuff that is missing from Swift.  I 
> suspect my list is longer than anyone else’s. :-)
> 
> My point on this is that it is more important to get the big efforts right 
> than it is to over-prioritize the small efforts.  This is both because of 
> implementation bandwidth reasons, but more importantly because it leads to a 
> better design.  Big efforts are *hard*, and tend to be less driven by the 
> community at large, but they really should take priority.
> 
> If you’re into analogies, I see features like the generics improvements, 
> concurrency model, ownership system, macro system, ABI stability, new 
> frameworks, and other large scale efforts as the “bricks" that make up the 
> house of Swift.  In that analogy, smaller proposals are “mortar” that fills 
> in the cracks between the bricks.  If we add too much mortar too early on, we 
> run the risk of the house of Swift being built out of mortar, or of not being 
> able to fit the bricks into the right places.  That would be very bad, given 
> that we all want the house of Swift to be strong and beautiful over the long 
> term.
> 
> Clearly there is a balance to be made, which is why major Swift releases are 
> a mix of large efforts (e.g. Codable improvements, typed keypaths, String 
> redesign...) as well as smaller ones (e.g. multiline strings, dictionary API 
> improvements, etc).
> 
> -Chris
> 
> 

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