Re: [swift-evolution] [Pitch] Scoped @available

[Xiaodi Wu via swift-evolution]

This would be very useful, but the spelling needs dramatic improvement.

"Available unavailable" is already challenging to read, but at least it is
learnable with time. The example where "@available(*, deprecated, access:
internal) open" means "fileprivate" is entirely unreasonable.

On Sun, Jul 9, 2017 at 22:40 rintaro ishizaki via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi evolution community,
>
> I would like to propose "Scoped @available" attribute.
>
> What I want to achieve is to declare something that is publicly
> unavailable, but still usable from narrower scope. A concrete example is
> IndexableBase in the standard library:
>
> https://github.com/apple/swift/blob/master/stdlib/public/core/Collection.swift#L18-L20
> Workaround for this problem in stdlib is to use typealias to underscored
> declaration. However, we can't use this technique in our module because
> underscored declarations are still visible and usable from outside.
>
> As a solution, I propose to add "access" parameter to @available
> attribute, which limits the effect of @available attribute to the
> specified value or outer.
>
> ---
> // Module: Library
>
> /// This protocol is available for internal, but deprecated for public.
> @available(*, deprecated, access: public, message: "it will be removed in
> future")
> public protocol OldProtocol {
> /* ... */
> }
>
> public Foo: OldProtocol { // No diagnostics
> }
>
> ---
> // Module: main
>
> import Library
>
> public Bar: OldProtocol { // warning: 'OldProtocol' is deprecated: it will
> be removed in future
> }
>
> ---
>
> I think this is useful when you want to stop exposing declarations, but
> want to keep using them internally.
>
> More examples:
>
> // is `open`, going to be `filerprivate`
> @available(*, deprecated, access: internal)
> open class Foo {}
>
> // was `internal`, now `private`
> @available(*, unavailable, access: fileprivate)
> var value: Int
>
> // No effect (invisible from public anyway): emit a warning
> @available(*, unavailable, access: public)
> internal struct Foo {}
>
> What do you think?
> ___
> 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] Scoped @available

[rintaro ishizaki via swift-evolution]

Hi evolution community,

I would like to propose "Scoped @available" attribute.

What I want to achieve is to declare something that is publicly
unavailable, but still usable from narrower scope. A concrete example is
IndexableBase in the standard library:
https://github.com/apple/swift/blob/master/stdlib/
public/core/Collection.swift#L18-L20
Workaround for this problem in stdlib is to use typealias to underscored
declaration. However, we can't use this technique in our module because
underscored declarations are still visible and usable from outside.

As a solution, I propose to add "access" parameter to @available attribute,
which limits the effect of @available attribute to the specified value or
outer.

---
// Module: Library

/// This protocol is available for internal, but deprecated for public.
@available(*, deprecated, access: public, message: "it will be removed in
future")
public protocol OldProtocol {
/* ... */
}

public Foo: OldProtocol { // No diagnostics
}

---
// Module: main

import Library

public Bar: OldProtocol { // warning: 'OldProtocol' is deprecated: it will
be removed in future
}

---

I think this is useful when you want to stop exposing declarations, but
want to keep using them internally.

More examples:

// is `open`, going to be `filerprivate`
@available(*, deprecated, access: internal)
open class Foo {}

// was `internal`, now `private`
@available(*, unavailable, access: fileprivate)
var value: Int

// No effect (invisible from public anyway): emit a warning
@available(*, unavailable, access: public)
internal struct Foo {}

What do you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

[Brent Royal-Gordon via swift-evolution]

> On Jul 7, 2017, at 4:27 PM, Dave Abrahams  wrote:
> 
> Yes, that's a lot of extra syntax.  But again, you've used an
> abbreviated, single identifier for the property and a
> short, non-descriptive identifier for the array.  Let's make this a
> fair/realistic comparison:
> 
>gradeHistories.map { $0[keyPath: \.average] }
> 
> vs.
>gradeHistories.map(\.average)

FWIW, this example isn't terribly realistic because you'd normally use a direct 
reference to a property, rather than a key path, in the transform closure. But 
after correcting for that, I don't think it changes the calculus very much:

gradeHistories.map { $0[keyPath: aggregate] }
gradeHistories.map(aggregate)

>> That's essentially what happened with the much-requested placeholder
>> syntax:
> 
> Sorry, I may have missed that discussion.

It was somewhere back in the Swift 3 timeframe. Short version is, people wanted 
a way to say something like:

numbers.map(abs(_) + 1)

But it was pointed out that this is fundamentally unclear about which of these 
you mean:

numbers.map({ abs($0) } + 1)
numbers.map({ abs($0) + 1 })
{ numbers.map(abs($0) + 1) }

And so the proponents pretty much dropped the suggestion.

> It's not fundamentally weird.  I'm just not sure it's important.

I'm not going to argue key-paths-as-functions are critical, because they're 
not. But I think they should be on the to-do list. And I think that niceties 
*like* this are, as a whole, something we should try to deliver more of. The 
soundness work that's being prioritized right now is really important, so I'm 
not sure how exactly to manage this—maybe these niceties should be left more to 
the community while full-time professional contributors focus more on core 
design issues and deep refactoring. But however we achieve it, I think a 
spoonful of syntactic sugar would help the medicine go down.

> If it
> actually is important, as I said, I feel very strongly that it shouldn't
> require anyone to create an overload of map, because that quickly leads
> to overloading everything that takes a closure.

I agree that we shouldn't overload `map` to specially support keypaths, except 
perhaps as a stopgap measure while we support subtyping more fully. And I don't 
think this is important enough to justify a stopgap.

>> There's one more reason I think we should do this. It is not about the
>> technology; it is not even really about the ergonomics. It's more
>> about language "marketing", for lack of a better term.
>> 
>> I think we were all surprised by the SE-0110 backlash. But in
>> hindsight, I think it's pretty easy to explain. During the Swift 3 and
>> 4 cycles, we systematically stripped conveniences and sugar from
>> higher-order functions. We have good reasons to do this; we want to
>> pare things down, fix the foundations, and then build up new
>> conveniences. Eat your vegetables now and you can have dessert later.
>> 
>> But we're entering our second year of eating nothing but
>> vegetables. It's very difficult to maintain a strict diet forever,
>> especially when—like the vast majority of Swift's users who don't
>> participate in evolution or implementation—you don't really see the
>> point of it. It's hard to blame them for being tired of it, or for
>> complaining when yet another tasty food is pulled off the menu.
>> 
>> Offering a treat like this on occasion will help ease the pain of
>> losing the things we *need* to take away. And this is a particularly
>> good candidate because, although it's a convenience for higher-order
>> functions—which is where the pain is felt—it has little to do with
>> parameter handling, the area where we actually need to remove things
>> and refactor. It's like a dessert of ultra-dark chocolate—it's a treat
>> that doesn't set the actual goal back very far.
>> 
>> In the abstract, "fundamentals now, sugar later" is the right
>> approach. But it can't be considered "right" if the users won't accept
>> it. So let's look for opportunities to add conveniences where we
>> can. Maybe this isn't the right feature—subtyping is always a bit
>> perilous—but we should be on the lookout for features like this one,
>> places where we can improve things for our functional programming fans
>> without obstructing our own efforts to clean up parameter handling.
> 
> These are all good arguments.  For me it's a question of priorities and
> long-term, irrevocable impacts.
> 
> By the way, if you're worried about whether subtyping will fly, I've
> recently been thinking there might be a role for a “promotion” operator
> that enables lossless “almost-implicit” conversions, e.g.:
> 
>someNumber^  is equivalent tonumericCast(someNumber)
>\.someKeyPath^   is equivalent to{ $0\.someKeyPath }
>someSubstring^   is equivalent toString(someSubstring)
> 
>etc.

I actually played with something like this years ago (pre-open source, IIRC), 
but I used 

Re: [swift-evolution] https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md

[Erica Sadun via swift-evolution]

> On Jul 9, 2017, at 4:30 PM, Mario Duran  wrote:
> 
> Worst Idea Ever.

Thank you for your feedback. 

If you'd like to learn more about Swift and its open sourced evolution process, 
please check out swift.org  and see how you can become a 
contributor and an active voice in the community.

Best regards,

-- Erica Sadun

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

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[John McCall via swift-evolution]

> On Jul 9, 2017, at 6:57 PM, Robert Bennett  wrote:
> Just a question: how would/does allowing the reordering of fields affect the 
> correctness and performance of the (de)serialization API added in Swift 4?

The design of that is definitely proof against changes to the in-memory layout 
of the type.  I believe it's also proof against reordering but I'm not entirely 
certain about that.

John.

> 
> On Jul 9, 2017, at 6:21 PM, Jens Persson via swift-evolution 
> > wrote:
> 
>> Thanks for that clarification John McCall.
>> My code is using a lot of generic structs (in which memory layout is 
>> important) though, an example would be:
>> struct Vector4 : Vector {
>> typealias Index = VectorIndex4
>> typealias Element = E
>> var e0, e1, e2, e3: Element
>> …
>> }
>> And I guess I'm out of luck trying to represent those as C structs?
>> So AFAICS it looks like it is currently impossible to write generic low 
>> level code in Swift, unless I just keep doing what I've been doing (It does 
>> currently work after all) knowing that it will probably break in some future 
>> versions of Swift. But in that possible future version of Swift, I could 
>> probably find a way to make it work again (using some possible explicit 
>> tools for layout control present in that version of Swift).
>> Correct?
>> /Jens
>> 
>> 
>> On Sun, Jul 9, 2017 at 11:41 PM, John McCall > > wrote:
>> 
>>> On Jul 9, 2017, at 4:49 PM, Jens Persson via swift-evolution 
>>> > wrote:
>>> 
>>> Sorry for making so much off topic noise in this thread, but I made a 
>>> mistake regarding the Metal tutorial:
>>> Looking more carefully I see now that they rebuild a vertedData: [Float] 
>>> from their vertices: [Vertex] using the floatBuffer() method of the Vertex 
>>> struct, which returns an Array with the stored properties of Vertex in 
>>> correct order.
>>> 
>>> While searching the internet about this I saw Joe Groff mentioning on 
>>> Twitter that:
>>> "We plan to sort fields in padding order to minimize size, and may also 
>>> automatically pack bools and enums in bitfields."
>>> 
>>> So AFAICS my current image processing code is making the possibly invalid 
>>> assumption that eg
>>> struct S {
>>> var a, b, c, d: Float
>>> }
>>> will have a memory layout of 4*4=16 bytes (stride and size == 16) and an 
>>> alignment of 4, and most importantly that a, b, c, d will be in that order.
>> 
>> This is currently true, but may not always be.  We want to reserve the right 
>> to re-order the fields even if it doesn't improve packing — for example, if 
>> two fields are frequently accessed together, field reordering could yield 
>> substantial locality benefits.  We've also discussed reordering fields to 
>> put them in a canonical order for resilience, since it's a little 
>> counter-intuitive that reordering the fields of a struct should be 
>> ABI-breaking.  (There are arguments against doing that as well, of course — 
>> for example, the programmer may have chosen the current order for their own 
>> locality optimizations.)
>> 
>>> It looks like I should be defining my structs (the ones for which memory 
>>> layout is important) in C and import them.
>> 
>> This should always work, yes.
>> 
>>> Although I would be surprised if a Swift-struct containing only same-sized 
>>> fields (all of the same primitive type) would be reordered, and such 
>>> changes to the language would probably include some per-struct way to 
>>> express some sort of layout control (since being able to define structs to 
>>> be used for low level data manipulation is important in a systems language).
>> 
>> Exactly.  In the long term, Swift will have some explicit tools for layout 
>> control.
>> 
>> John.
>> 
>>> 
>>> /Jens
>>> 
>>> 
>>> On Sun, Jul 9, 2017 at 7:01 PM, Jens Persson via swift-evolution 
>>> > wrote:
>>> I should perhaps add that in my image processing code, I use code like this:
>>> 
>>> func withVImageBuffer(for table: Table, body: 
>>> (vImage_Buffer) -> R) -> R
>>> where
>>> Data.Coordinate.Index == VectorIndex2
>>> {
>>> let vib = vImage_Buffer(
>>> data: table.baseAddress,
>>> height: vImagePixelCount(table.size.e1),
>>> width: vImagePixelCount(table.size.e0),
>>> rowBytes: table.stride.e1
>>> )
>>> return withExtendedLifetime(table) { body(vib) }
>>> }
>>> 
>>> Here, Table is the raster image. Data.Coordinate == VectorIndex2 
>>> makes it a 2D table, and a Table's Data also has a type parameter 
>>> Data.Value which can be eg one of the "pixel"-struct I showed before.
>>> This works without any problems (I've tested and used the some variant of 
>>> this type of code for years) but it would surely break if the memory layout 

Re: [swift-evolution] [Pitch] Guard/Catch

[Charles Srstka via swift-evolution]

> On Jul 8, 2017, at 3:08 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> I am opposed to this proposal because it muddies up the language to support 
> what is essentially an edge case. The standard way to exit a function early 
> because an exception is thrown is to make the function itself throw, if it is 
> part of a larger operation. The addition of a few lines of try/catch code is 
> not a great burden and makes the termination of an an exception very clear.

Not such an edge case, if you write asynchronous code:

func doSomething(completionHandler: @escaping (Error?) -> ()) {
guard let foo = try makeFoo() catch {
completionHandler(error)
return
}

doSomeAsyncThing(with: foo) {
do {
try parseTheResult($0)
completionHandler(nil)
} catch {
completionHandler(error)
}
}
}

With the existing facilities, one must either use this rather awkward 
construction to make foo:

func doSomething(completionHandler: @escaping (Error?) -> ()) {
let foo: Foo

do {
foo = try makeFoo()
} catch {
completionHandler(error)
return
}

doSomeAsyncThing(with: foo) {
do {
try parseTheResult($0)
completionHandler(nil)
} catch {
completionHandler(error)
}
}
}

Or, alternatively, construct a pyramid of doom:

func doSomething(completionHandler: @escaping (Error?) -> ()) {
do {
let foo = try makeFoo()

doSomeAsyncThing(with: foo) {
do {
try parseTheResult($0)
completionHandler(nil)
} catch {
completionHandler(error)
}
}
} catch {
completionHandler(error)
}
}

Charles

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

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[Robert Bennett via swift-evolution]

Just a question: how would/does allowing the reordering of fields affect the 
correctness and performance of the (de)serialization API added in Swift 4?

> On Jul 9, 2017, at 6:21 PM, Jens Persson via swift-evolution 
>  wrote:
> 
> Thanks for that clarification John McCall.
> My code is using a lot of generic structs (in which memory layout is 
> important) though, an example would be:
> struct Vector4 : Vector {
> typealias Index = VectorIndex4
> typealias Element = E
> var e0, e1, e2, e3: Element
> …
> }
> And I guess I'm out of luck trying to represent those as C structs?
> So AFAICS it looks like it is currently impossible to write generic low level 
> code in Swift, unless I just keep doing what I've been doing (It does 
> currently work after all) knowing that it will probably break in some future 
> versions of Swift. But in that possible future version of Swift, I could 
> probably find a way to make it work again (using some possible explicit tools 
> for layout control present in that version of Swift).
> Correct?
> /Jens
> 
> 
>> On Sun, Jul 9, 2017 at 11:41 PM, John McCall  wrote:
>> 
>>> On Jul 9, 2017, at 4:49 PM, Jens Persson via swift-evolution 
>>>  wrote:
>>> 
>>> Sorry for making so much off topic noise in this thread, but I made a 
>>> mistake regarding the Metal tutorial:
>>> Looking more carefully I see now that they rebuild a vertedData: [Float] 
>>> from their vertices: [Vertex] using the floatBuffer() method of the Vertex 
>>> struct, which returns an Array with the stored properties of Vertex in 
>>> correct order.
>>> 
>>> While searching the internet about this I saw Joe Groff mentioning on 
>>> Twitter that:
>>> "We plan to sort fields in padding order to minimize size, and may also 
>>> automatically pack bools and enums in bitfields."
>>> 
>>> So AFAICS my current image processing code is making the possibly invalid 
>>> assumption that eg
>>> struct S {
>>> var a, b, c, d: Float
>>> }
>>> will have a memory layout of 4*4=16 bytes (stride and size == 16) and an 
>>> alignment of 4, and most importantly that a, b, c, d will be in that order.
>> 
>> This is currently true, but may not always be.  We want to reserve the right 
>> to re-order the fields even if it doesn't improve packing — for example, if 
>> two fields are frequently accessed together, field reordering could yield 
>> substantial locality benefits.  We've also discussed reordering fields to 
>> put them in a canonical order for resilience, since it's a little 
>> counter-intuitive that reordering the fields of a struct should be 
>> ABI-breaking.  (There are arguments against doing that as well, of course — 
>> for example, the programmer may have chosen the current order for their own 
>> locality optimizations.)
>> 
>>> It looks like I should be defining my structs (the ones for which memory 
>>> layout is important) in C and import them.
>> 
>> This should always work, yes.
>> 
>>> Although I would be surprised if a Swift-struct containing only same-sized 
>>> fields (all of the same primitive type) would be reordered, and such 
>>> changes to the language would probably include some per-struct way to 
>>> express some sort of layout control (since being able to define structs to 
>>> be used for low level data manipulation is important in a systems language).
>> 
>> Exactly.  In the long term, Swift will have some explicit tools for layout 
>> control.
>> 
>> John.
>> 
>>> 
>>> /Jens
>>> 
>>> 
 On Sun, Jul 9, 2017 at 7:01 PM, Jens Persson via swift-evolution 
  wrote:
 I should perhaps add that in my image processing code, I use code like 
 this:
 
 func withVImageBuffer(for table: Table, body: 
 (vImage_Buffer) -> R) -> R
 where
 Data.Coordinate.Index == VectorIndex2
 {
 let vib = vImage_Buffer(
 data: table.baseAddress,
 height: vImagePixelCount(table.size.e1),
 width: vImagePixelCount(table.size.e0),
 rowBytes: table.stride.e1
 )
 return withExtendedLifetime(table) { body(vib) }
 }
 
 Here, Table is the raster image. Data.Coordinate == VectorIndex2 
 makes it a 2D table, and a Table's Data also has a type parameter 
 Data.Value which can be eg one of the "pixel"-struct I showed before.
 This works without any problems (I've tested and used the some variant of 
 this type of code for years) but it would surely break if the memory 
 layout of simple structs changed.
 
 I can't see how this usage is much different from the one in the Metal 
 tutorial. It too uses pointers to point into a data created using the 
 (Swift) struct "Vertex", and the GPU hardware has its expectations on the 
 memory layout of that data, so the code would break if the memory layout 
 of the Vertex struct changed.
 
 /Jens

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[Jens Persson via swift-evolution]

Thanks for that clarification John McCall.
My code is using a lot of generic structs (in which memory layout is
important) though, an example would be:
struct Vector4 : Vector {
typealias Index = VectorIndex4
typealias Element = E
var e0, e1, e2, e3: Element
…
}
And I guess I'm out of luck trying to represent those as C structs?
So AFAICS it looks like it is currently impossible to write generic low
level code in Swift, unless I just keep doing what I've been doing (It does
currently work after all) knowing that it will probably break in some
future versions of Swift. But in that possible future version of Swift, I
could probably find a way to make it work again (using some possible
explicit tools for layout control present in that version of Swift).
Correct?
/Jens


On Sun, Jul 9, 2017 at 11:41 PM, John McCall  wrote:

>
> On Jul 9, 2017, at 4:49 PM, Jens Persson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sorry for making so much off topic noise in this thread, but I made a
> mistake regarding the Metal tutorial:
> Looking more carefully I see now that they rebuild a vertedData: [Float]
> from their vertices: [Vertex] using the floatBuffer() method of the Vertex
> struct, which returns an Array with the stored properties of Vertex in
> correct order.
>
> While searching the internet about this I saw Joe Groff mentioning on
> Twitter that:
> "We plan to sort fields in padding order to minimize size, and may also
> automatically pack bools and enums in bitfields."
>
> So AFAICS my current image processing code is making the possibly invalid
> assumption that eg
> struct S {
> var a, b, c, d: Float
> }
> will have a memory layout of 4*4=16 bytes (stride and size == 16) and an
> alignment of 4, and most importantly that a, b, c, d will be in that order.
>
>
> This is currently true, but may not always be.  We want to reserve the
> right to re-order the fields even if it doesn't improve packing — for
> example, if two fields are frequently accessed together, field reordering
> could yield substantial locality benefits.  We've also discussed reordering
> fields to put them in a canonical order for resilience, since it's a little
> counter-intuitive that reordering the fields of a struct should be
> ABI-breaking.  (There are arguments against doing that as well, of course —
> for example, the programmer may have chosen the current order for their own
> locality optimizations.)
>
> It looks like I should be defining my structs (the ones for which memory
> layout is important) in C and import them.
>
>
> This should always work, yes.
>
> Although I would be surprised if a Swift-struct containing only same-sized
> fields (all of the same primitive type) would be reordered, and such
> changes to the language would probably include some per-struct way to
> express some sort of layout control (since being able to define structs to
> be used for low level data manipulation is important in a systems language).
>
>
> Exactly.  In the long term, Swift will have some explicit tools for layout
> control.
>
> John.
>
>
> /Jens
>
>
> On Sun, Jul 9, 2017 at 7:01 PM, Jens Persson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I should perhaps add that in my image processing code, I use code like
>> this:
>>
>> func withVImageBuffer(for table: Table, body:
>> (vImage_Buffer) -> R) -> R
>> where
>> Data.Coordinate.Index == VectorIndex2
>> {
>> let vib = vImage_Buffer(
>> data: table.baseAddress,
>> height: vImagePixelCount(table.size.e1),
>> width: vImagePixelCount(table.size.e0),
>> rowBytes: table.stride.e1
>> )
>> return withExtendedLifetime(table) { body(vib) }
>> }
>>
>> Here, Table is the raster image. Data.Coordinate == VectorIndex2
>> makes it a 2D table, and a Table's Data also has a type parameter
>> Data.Value which can be eg one of the "pixel"-struct I showed before.
>> This works without any problems (I've tested and used the some variant of
>> this type of code for years) but it would surely break if the memory layout
>> of simple structs changed.
>>
>> I can't see how this usage is much different from the one in the Metal
>> tutorial. It too uses pointers to point into a data created using the
>> (Swift) struct "Vertex", and the GPU hardware has its expectations on the
>> memory layout of that data, so the code would break if the memory layout of
>> the Vertex struct changed.
>>
>> /Jens
>>
>>
>> On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson  wrote:
>>
>>> I don't think I'm misunderstanding you, but I might be, so I'll add more
>>> detail:
>>>
>>> If you look at the Metal article, you'll see that the (Swift) struct
>>> "Vertex" is used to specify the data that is sent to Metal for creating a
>>> buffer (using MTLDevice.makeBuffer). The result that the GPU will
>>> produce surely depends on the fields of the Vertex struct (x, y, z, r, g,
>>> b, a) being in the 

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[John McCall via swift-evolution]

> On Jul 9, 2017, at 6:14 PM, Jens Persson  wrote:
> 
> Thanks for that clarification John McCall.
> My code is using a lot of generic structs (in which memory layout is 
> important) though, an example would be:
> struct Vector4 : Vector {
> typealias Index = VectorIndex4
> typealias Element = E
> var e0, e1, e2, e3: Element
> …
> }
> And I guess I'm out of luck trying to represent those as C structs?
> So AFAICS it looks like it is currently impossible to write generic low level 
> code in Swift, unless I just keep doing what I've been doing (It does 
> currently work after all) knowing that it will probably break in some future 
> versions of Swift. But in that possible future version of Swift, I could 
> probably find a way to make it work again (using some possible explicit tools 
> for layout control present in that version of Swift).
> Correct?

Correct.

John.

> /Jens
> 
> 
> On Sun, Jul 9, 2017 at 11:41 PM, John McCall  > wrote:
> 
>> On Jul 9, 2017, at 4:49 PM, Jens Persson via swift-evolution 
>> > wrote:
>> 
>> Sorry for making so much off topic noise in this thread, but I made a 
>> mistake regarding the Metal tutorial:
>> Looking more carefully I see now that they rebuild a vertedData: [Float] 
>> from their vertices: [Vertex] using the floatBuffer() method of the Vertex 
>> struct, which returns an Array with the stored properties of Vertex in 
>> correct order.
>> 
>> While searching the internet about this I saw Joe Groff mentioning on 
>> Twitter that:
>> "We plan to sort fields in padding order to minimize size, and may also 
>> automatically pack bools and enums in bitfields."
>> 
>> So AFAICS my current image processing code is making the possibly invalid 
>> assumption that eg
>> struct S {
>> var a, b, c, d: Float
>> }
>> will have a memory layout of 4*4=16 bytes (stride and size == 16) and an 
>> alignment of 4, and most importantly that a, b, c, d will be in that order.
> 
> This is currently true, but may not always be.  We want to reserve the right 
> to re-order the fields even if it doesn't improve packing — for example, if 
> two fields are frequently accessed together, field reordering could yield 
> substantial locality benefits.  We've also discussed reordering fields to put 
> them in a canonical order for resilience, since it's a little 
> counter-intuitive that reordering the fields of a struct should be 
> ABI-breaking.  (There are arguments against doing that as well, of course — 
> for example, the programmer may have chosen the current order for their own 
> locality optimizations.)
> 
>> It looks like I should be defining my structs (the ones for which memory 
>> layout is important) in C and import them.
> 
> This should always work, yes.
> 
>> Although I would be surprised if a Swift-struct containing only same-sized 
>> fields (all of the same primitive type) would be reordered, and such changes 
>> to the language would probably include some per-struct way to express some 
>> sort of layout control (since being able to define structs to be used for 
>> low level data manipulation is important in a systems language).
> 
> Exactly.  In the long term, Swift will have some explicit tools for layout 
> control.
> 
> John.
> 
>> 
>> /Jens
>> 
>> 
>> On Sun, Jul 9, 2017 at 7:01 PM, Jens Persson via swift-evolution 
>> > wrote:
>> I should perhaps add that in my image processing code, I use code like this:
>> 
>> func withVImageBuffer(for table: Table, body: (vImage_Buffer) 
>> -> R) -> R
>> where
>> Data.Coordinate.Index == VectorIndex2
>> {
>> let vib = vImage_Buffer(
>> data: table.baseAddress,
>> height: vImagePixelCount(table.size.e1),
>> width: vImagePixelCount(table.size.e0),
>> rowBytes: table.stride.e1
>> )
>> return withExtendedLifetime(table) { body(vib) }
>> }
>> 
>> Here, Table is the raster image. Data.Coordinate == VectorIndex2 makes 
>> it a 2D table, and a Table's Data also has a type parameter Data.Value which 
>> can be eg one of the "pixel"-struct I showed before.
>> This works without any problems (I've tested and used the some variant of 
>> this type of code for years) but it would surely break if the memory layout 
>> of simple structs changed.
>> 
>> I can't see how this usage is much different from the one in the Metal 
>> tutorial. It too uses pointers to point into a data created using the 
>> (Swift) struct "Vertex", and the GPU hardware has its expectations on the 
>> memory layout of that data, so the code would break if the memory layout of 
>> the Vertex struct changed.
>> 
>> /Jens
>> 
>> 
>> On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson > > wrote:
>> I don't think I'm misunderstanding you, but I might be, so I'll add more 

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[John McCall via swift-evolution]

> On Jul 9, 2017, at 4:49 PM, Jens Persson via swift-evolution 
>  wrote:
> 
> Sorry for making so much off topic noise in this thread, but I made a mistake 
> regarding the Metal tutorial:
> Looking more carefully I see now that they rebuild a vertedData: [Float] from 
> their vertices: [Vertex] using the floatBuffer() method of the Vertex struct, 
> which returns an Array with the stored properties of Vertex in correct order.
> 
> While searching the internet about this I saw Joe Groff mentioning on Twitter 
> that:
> "We plan to sort fields in padding order to minimize size, and may also 
> automatically pack bools and enums in bitfields."
> 
> So AFAICS my current image processing code is making the possibly invalid 
> assumption that eg
> struct S {
> var a, b, c, d: Float
> }
> will have a memory layout of 4*4=16 bytes (stride and size == 16) and an 
> alignment of 4, and most importantly that a, b, c, d will be in that order.

This is currently true, but may not always be.  We want to reserve the right to 
re-order the fields even if it doesn't improve packing — for example, if two 
fields are frequently accessed together, field reordering could yield 
substantial locality benefits.  We've also discussed reordering fields to put 
them in a canonical order for resilience, since it's a little counter-intuitive 
that reordering the fields of a struct should be ABI-breaking.  (There are 
arguments against doing that as well, of course — for example, the programmer 
may have chosen the current order for their own locality optimizations.)

> It looks like I should be defining my structs (the ones for which memory 
> layout is important) in C and import them.

This should always work, yes.

> Although I would be surprised if a Swift-struct containing only same-sized 
> fields (all of the same primitive type) would be reordered, and such changes 
> to the language would probably include some per-struct way to express some 
> sort of layout control (since being able to define structs to be used for low 
> level data manipulation is important in a systems language).

Exactly.  In the long term, Swift will have some explicit tools for layout 
control.

John.

> 
> /Jens
> 
> 
> On Sun, Jul 9, 2017 at 7:01 PM, Jens Persson via swift-evolution 
> > wrote:
> I should perhaps add that in my image processing code, I use code like this:
> 
> func withVImageBuffer(for table: Table, body: (vImage_Buffer) 
> -> R) -> R
> where
> Data.Coordinate.Index == VectorIndex2
> {
> let vib = vImage_Buffer(
> data: table.baseAddress,
> height: vImagePixelCount(table.size.e1),
> width: vImagePixelCount(table.size.e0),
> rowBytes: table.stride.e1
> )
> return withExtendedLifetime(table) { body(vib) }
> }
> 
> Here, Table is the raster image. Data.Coordinate == VectorIndex2 makes 
> it a 2D table, and a Table's Data also has a type parameter Data.Value which 
> can be eg one of the "pixel"-struct I showed before.
> This works without any problems (I've tested and used the some variant of 
> this type of code for years) but it would surely break if the memory layout 
> of simple structs changed.
> 
> I can't see how this usage is much different from the one in the Metal 
> tutorial. It too uses pointers to point into a data created using the (Swift) 
> struct "Vertex", and the GPU hardware has its expectations on the memory 
> layout of that data, so the code would break if the memory layout of the 
> Vertex struct changed.
> 
> /Jens
> 
> 
> On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson  > wrote:
> I don't think I'm misunderstanding you, but I might be, so I'll add more 
> detail:
> 
> If you look at the Metal article, you'll see that the (Swift) struct "Vertex" 
> is used to specify the data that is sent to Metal for creating a buffer 
> (using MTLDevice.makeBuffer). The result that the GPU will produce surely 
> depends on the fields of the Vertex struct (x, y, z, r, g, b, a) being in the 
> specified order (ie swapping the red channel with the x coordinate would 
> produce an unexpected result).
> 
> And regarding the second example, pixel structs used for manipulating raster 
> image data. Manipulating raster image data presumably includes stuff like 
> displaying to screen, loading and saving raster images.
> I currently use this way of doing this right now without any problems, but if 
> the order of the fields (eg a, r, g, b) should change in the future, then my 
> code would break (the colors of the images would at least not come out as 
> expected).
> 
> /Jens
> 
> 
> 
> 
> 
> 
> On Sun, Jul 9, 2017 at 5:53 PM, Chris Lattner  > wrote:
> 
>> On Jul 9, 2017, at 12:23 AM, Jens Persson > > wrote:
>> 
>> 
>> On Sat, Jul 8, 2017 at 6:28 

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[Jens Persson via swift-evolution]

Sorry for making so much off topic noise in this thread, but I made a
mistake regarding the Metal tutorial:
Looking more carefully I see now that they rebuild a vertedData: [Float]
from their vertices: [Vertex] using the floatBuffer() method of the Vertex
struct, which returns an Array with the stored properties of Vertex in
correct order.

While searching the internet about this I saw Joe Groff mentioning on
Twitter that:
"We plan to sort fields in padding order to minimize size, and may also
automatically pack bools and enums in bitfields."

So AFAICS my current image processing code is making the possibly invalid
assumption that eg
struct S {
var a, b, c, d: Float
}
will have a memory layout of 4*4=16 bytes (stride and size == 16) and an
alignment of 4, and most importantly that a, b, c, d will be in that order.

It looks like I should be defining my structs (the ones for which memory
layout is important) in C and import them.

Although I would be surprised if a Swift-struct containing only same-sized
fields (all of the same primitive type) would be reordered, and such
changes to the language would probably include some per-struct way to
express some sort of layout control (since being able to define structs to
be used for low level data manipulation is important in a systems language).

/Jens


On Sun, Jul 9, 2017 at 7:01 PM, Jens Persson via swift-evolution <
swift-evolution@swift.org> wrote:

> I should perhaps add that in my image processing code, I use code like
> this:
>
> func withVImageBuffer(for table: Table, body:
> (vImage_Buffer) -> R) -> R
> where
> Data.Coordinate.Index == VectorIndex2
> {
> let vib = vImage_Buffer(
> data: table.baseAddress,
> height: vImagePixelCount(table.size.e1),
> width: vImagePixelCount(table.size.e0),
> rowBytes: table.stride.e1
> )
> return withExtendedLifetime(table) { body(vib) }
> }
>
> Here, Table is the raster image. Data.Coordinate == VectorIndex2
> makes it a 2D table, and a Table's Data also has a type parameter
> Data.Value which can be eg one of the "pixel"-struct I showed before.
> This works without any problems (I've tested and used the some variant of
> this type of code for years) but it would surely break if the memory layout
> of simple structs changed.
>
> I can't see how this usage is much different from the one in the Metal
> tutorial. It too uses pointers to point into a data created using the
> (Swift) struct "Vertex", and the GPU hardware has its expectations on the
> memory layout of that data, so the code would break if the memory layout of
> the Vertex struct changed.
>
> /Jens
>
>
> On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson  wrote:
>
>> I don't think I'm misunderstanding you, but I might be, so I'll add more
>> detail:
>>
>> If you look at the Metal article, you'll see that the (Swift) struct
>> "Vertex" is used to specify the data that is sent to Metal for creating a
>> buffer (using MTLDevice.makeBuffer). The result that the GPU will
>> produce surely depends on the fields of the Vertex struct (x, y, z, r, g,
>> b, a) being in the specified order (ie swapping the red channel with the x
>> coordinate would produce an unexpected result).
>>
>> And regarding the second example, pixel structs used for manipulating
>> raster image data. Manipulating raster image data presumably includes stuff
>> like displaying to screen, loading and saving raster images.
>> I currently use this way of doing this right now without any problems,
>> but if the order of the fields (eg a, r, g, b) should change in the future,
>> then my code would break (the colors of the images would at least not come
>> out as expected).
>>
>> /Jens
>>
>>
>>
>>
>>
>>
>> On Sun, Jul 9, 2017 at 5:53 PM, Chris Lattner 
>> wrote:
>>
>>>
>>> On Jul 9, 2017, at 12:23 AM, Jens Persson  wrote:
>>>
>>>
>>> On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Hi Susan,

 Swift does not currently specify a layout for Swift structs.  You
 shouldn’t be using them for memory mapped i/o or writing to a file, because
 their layout can change.  When ABI stability for fragile structs lands, you
 will be able to count on it, but until then something like this is probably
 a bad idea.

 -Chris

>>>
>>> Does this imply that you should never use Swift structs to eg interact
>>> with Metal?
>>>
>>>
>>> No.
>>>
>>> This seems to be a very common practice. Here is a typical example (from
>>> a Metal tutorial at raywenderlich.com):
>>>
>>> struct Vertex {
>>>   var x,y,z: Float // position data
>>>   var r,g,b,a: Float   // color data
>>>
>>>   func floatBuffer() -> [Float] {
>>> return [x,y,z,r,g,b,a]
>>>   }
>>> }
>>>
>>>
>>> This doesn’t appear to expose the layout of the struct.
>>>
>>> Also, does it imply that we cannot use structs (of only primitive types)
>>> like:

Re: [swift-evolution] [Pitch] Guard/Catch

[Christopher Kornher via swift-evolution]

I dashed these emails off very quickly, which is something I should never do 
here. There problems with the “trailing catch” idea. Some of them could be made 
to work, with enough rules added, but it would probably have been best to just 
stick with my original objection to adding special-case syntactic sugar at this 
point in the evolution of the language.

The "trailing catch” would be pretty straightforward for `try?` and `try!` 
calls, since both handle the lack of a return value from the called function. 
There is currently no way to do anything with exceptions thrown from `try?` and 
‘try!’, so there might be some value for these.`try` is more problematic and 
would require an exit or a or an exception to be thrown from the catch block. 
This adds more rules to ‘catch’, which argues against including it in the 
language. Another keyword like “intercept” for catches that would guarantee 
that an exception is thrown from the handling block would be a better choice 
for “try”, I think, but the bar for new keywords is justifiably very high.

In any case, the logic from all uses of a "trailing catch" can be replicated 
with nested do/catch blocks, so I do not think that these ideas should be 
considered now.

The “trailing catch” idea might fit with Dave DeLong’s suggestion of a few days 
ago, in which he wanted support for detailed diagnostics (hopefully that is a 
correct summary). If/when that topic ever is considered, then the "trailing 
catch” may have a place as part of that effort.


> On Jul 8, 2017, at 5:16 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> Thanks for you considerate reply. My concern over the proliferation of “sugar 
> proposals” is a general one. This proposal has more merit and general 
> utiliity than many others. I have never used a throwing function in a guard 
> statement that was not itself in a throwing function, but I can see that it 
> could possibly be common in some code. Wrapping a guard statement and all the 
> code that uses variables set in the guard in a do/catch is sub-optimal.
> 
>> On Jul 8, 2017, at 4:16 PM, Benjamin Spratling via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jul 8, 2017, at 4:08 PM, Christopher Kornher >> > wrote:
>>> 
>>> I am opposed to this proposal because it muddies up the language to support 
>>> what is essentially an edge case. The standard way to exit a function early 
>>> because an exception is thrown is to make the function itself throw, if it 
>>> is part of a larger operation. The addition of a few lines of try/catch 
>>> code is not a great burden and makes the termination of an an exception 
>>> very clear.
>> 
>> I’ve read your email, but haven’t digested it fully.  One thing I agree with 
>> is that most functions which call throwing functions don’t actually use a 
>> do…catch block, but instead are merely marked “throws” and the error is 
>> propagated back through the stack.  Once I seriously started coding 
>> functions with errors, I realized I almost always wanted my errors to reach 
>> my view-controller or my business logic so I could present separate UI if a 
>> real error occurred, and often my error message depended on the details of 
>> the error instance.
>> 
>>> `guard` statements are generally used to set variables that are needed in 
>>> the body of a function. Using them to save a few lines of exception handing 
>>> code is a very different use. There is no need to mix two relatively clean 
>>> syntaxes for a few edge cases and increase cognitive load one more time, 
>> 
>> 
>> I disagree with your conclusion on this point.
>> The “guard” syntax is specifically designed to achieve early return (and 
>> placing code associated with early return at the point where it happens) and 
>> cleanly installing the returned value into the surrounding scope.  So far it 
>> has been used to achieve early return only with optionals, true.  But is 
>> that inherent to ‘guard’, or is it merely because that’s the only way it has 
>> been used?  The guard does set variables that are needed in the body of the 
>> function, and that’s exactly why using guard with values returned from 
>> throwing functions makes so much sense, because it does exactly the same 
>> thing in a general sense.  The “do”…”catch” structure is intentionally 
>> designed differently, to place the “happy path” in one place and place the 
>> returns in another place.  I think with guard/else, we’re seeing developers 
>> who can handle less cognitive loading find it easier to reason about early 
>> return than grouping failures after the happy path.  This proposal hopes to 
>> introduce that better language architecture to the catching of errors.
> 
> All catches don’t have to exit the outer scope, so using guard only handles a 
> subset 
> 
> It think that creating the terse try/catch for simple cases has multiple 
> 

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[Jens Persson via swift-evolution]

I should perhaps add that in my image processing code, I use code like this:

func withVImageBuffer(for table: Table, body:
(vImage_Buffer) -> R) -> R
where
Data.Coordinate.Index == VectorIndex2
{
let vib = vImage_Buffer(
data: table.baseAddress,
height: vImagePixelCount(table.size.e1),
width: vImagePixelCount(table.size.e0),
rowBytes: table.stride.e1
)
return withExtendedLifetime(table) { body(vib) }
}

Here, Table is the raster image. Data.Coordinate == VectorIndex2
makes it a 2D table, and a Table's Data also has a type parameter
Data.Value which can be eg one of the "pixel"-struct I showed before.
This works without any problems (I've tested and used the some variant of
this type of code for years) but it would surely break if the memory layout
of simple structs changed.

I can't see how this usage is much different from the one in the Metal
tutorial. It too uses pointers to point into a data created using the
(Swift) struct "Vertex", and the GPU hardware has its expectations on the
memory layout of that data, so the code would break if the memory layout of
the Vertex struct changed.

/Jens


On Sun, Jul 9, 2017 at 6:35 PM, Jens Persson  wrote:

> I don't think I'm misunderstanding you, but I might be, so I'll add more
> detail:
>
> If you look at the Metal article, you'll see that the (Swift) struct
> "Vertex" is used to specify the data that is sent to Metal for creating a
> buffer (using MTLDevice.makeBuffer). The result that the GPU will produce
> surely depends on the fields of the Vertex struct (x, y, z, r, g, b, a)
> being in the specified order (ie swapping the red channel with the x
> coordinate would produce an unexpected result).
>
> And regarding the second example, pixel structs used for manipulating
> raster image data. Manipulating raster image data presumably includes stuff
> like displaying to screen, loading and saving raster images.
> I currently use this way of doing this right now without any problems, but
> if the order of the fields (eg a, r, g, b) should change in the future,
> then my code would break (the colors of the images would at least not come
> out as expected).
>
> /Jens
>
>
>
>
>
>
> On Sun, Jul 9, 2017 at 5:53 PM, Chris Lattner  wrote:
>
>>
>> On Jul 9, 2017, at 12:23 AM, Jens Persson  wrote:
>>
>>
>> On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hi Susan,
>>>
>>> Swift does not currently specify a layout for Swift structs.  You
>>> shouldn’t be using them for memory mapped i/o or writing to a file, because
>>> their layout can change.  When ABI stability for fragile structs lands, you
>>> will be able to count on it, but until then something like this is probably
>>> a bad idea.
>>>
>>> -Chris
>>>
>>
>> Does this imply that you should never use Swift structs to eg interact
>> with Metal?
>>
>>
>> No.
>>
>> This seems to be a very common practice. Here is a typical example (from
>> a Metal tutorial at raywenderlich.com):
>>
>> struct Vertex {
>>   var x,y,z: Float // position data
>>   var r,g,b,a: Float   // color data
>>
>>   func floatBuffer() -> [Float] {
>> return [x,y,z,r,g,b,a]
>>   }
>> }
>>
>>
>> This doesn’t appear to expose the layout of the struct.
>>
>> Also, does it imply that we cannot use structs (of only primitive types)
>> like:
>>
>> struct RgbaFloatsLinearGamma {
>> var r, g, b, a: Float
>> …
>> }
>> struct BgraBytesSrgbGamma {
>> var b, g, r, a: UInt8
>> }
>>
>> for manipulating raster image data?
>>
>>
>> I don’t see why that would be a problem.
>>
>> I vaguely remember a swift evo discussion where it was concluded that
>> such usage was considered OK provided the stored properties of the structs
>> was only primitive types, but I can't find it now.
>>
>> Perhaps it could be considered OK at least when the intended platforms
>> are known to be only iOS devices?
>>
>>
>> I think you’re misunderstanding what I’m saying.  It isn’t correct to
>> take (e.g.) an unsafepointer to the beginning of a struct, and serialize
>> that out to disk, and expect that the fields are emitted in some order with
>> some specific padding between them.  None of the uses above try to do this.
>>
>> -Chris
>>
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[Jens Persson via swift-evolution]

I don't think I'm misunderstanding you, but I might be, so I'll add more
detail:

If you look at the Metal article, you'll see that the (Swift) struct
"Vertex" is used to specify the data that is sent to Metal for creating a
buffer (using MTLDevice.makeBuffer). The result that the GPU will produce
surely depends on the fields of the Vertex struct (x, y, z, r, g, b, a)
being in the specified order (ie swapping the red channel with the x
coordinate would produce an unexpected result).

And regarding the second example, pixel structs used for manipulating
raster image data. Manipulating raster image data presumably includes stuff
like displaying to screen, loading and saving raster images.
I currently use this way of doing this right now without any problems, but
if the order of the fields (eg a, r, g, b) should change in the future,
then my code would break (the colors of the images would at least not come
out as expected).

/Jens






On Sun, Jul 9, 2017 at 5:53 PM, Chris Lattner  wrote:

>
> On Jul 9, 2017, at 12:23 AM, Jens Persson  wrote:
>
>
> On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi Susan,
>>
>> Swift does not currently specify a layout for Swift structs.  You
>> shouldn’t be using them for memory mapped i/o or writing to a file, because
>> their layout can change.  When ABI stability for fragile structs lands, you
>> will be able to count on it, but until then something like this is probably
>> a bad idea.
>>
>> -Chris
>>
>
> Does this imply that you should never use Swift structs to eg interact
> with Metal?
>
>
> No.
>
> This seems to be a very common practice. Here is a typical example (from a
> Metal tutorial at raywenderlich.com):
>
> struct Vertex {
>   var x,y,z: Float // position data
>   var r,g,b,a: Float   // color data
>
>   func floatBuffer() -> [Float] {
> return [x,y,z,r,g,b,a]
>   }
> }
>
>
> This doesn’t appear to expose the layout of the struct.
>
> Also, does it imply that we cannot use structs (of only primitive types)
> like:
>
> struct RgbaFloatsLinearGamma {
> var r, g, b, a: Float
> …
> }
> struct BgraBytesSrgbGamma {
> var b, g, r, a: UInt8
> }
>
> for manipulating raster image data?
>
>
> I don’t see why that would be a problem.
>
> I vaguely remember a swift evo discussion where it was concluded that such
> usage was considered OK provided the stored properties of the structs was
> only primitive types, but I can't find it now.
>
> Perhaps it could be considered OK at least when the intended platforms are
> known to be only iOS devices?
>
>
> I think you’re misunderstanding what I’m saying.  It isn’t correct to take
> (e.g.) an unsafepointer to the beginning of a struct, and serialize that
> out to disk, and expect that the fields are emitted in some order with some
> specific padding between them.  None of the uses above try to do this.
>
> -Chris
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Introduces endianness specific type

[Chris Lattner via swift-evolution]

> On Jul 9, 2017, at 12:23 AM, Jens Persson  wrote:
> 
> 
> On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution 
> > wrote:
> Hi Susan,
> 
> Swift does not currently specify a layout for Swift structs.  You shouldn’t 
> be using them for memory mapped i/o or writing to a file, because their 
> layout can change.  When ABI stability for fragile structs lands, you will be 
> able to count on it, but until then something like this is probably a bad 
> idea.
> 
> -Chris
> 
> Does this imply that you should never use Swift structs to eg interact with 
> Metal?

No.

> This seems to be a very common practice. Here is a typical example (from a 
> Metal tutorial at raywenderlich.com ):
> 
> struct Vertex {
>   var x,y,z: Float // position data
>   var r,g,b,a: Float   // color data
> 
>   func floatBuffer() -> [Float] {
> return [x,y,z,r,g,b,a]
>   }
> }

This doesn’t appear to expose the layout of the struct.
> Also, does it imply that we cannot use structs (of only primitive types) like:
> 
> struct RgbaFloatsLinearGamma {
> var r, g, b, a: Float
> …
> }
> struct BgraBytesSrgbGamma {
> var b, g, r, a: UInt8
> }
> 
> for manipulating raster image data?

I don’t see why that would be a problem.

> I vaguely remember a swift evo discussion where it was concluded that such 
> usage was considered OK provided the stored properties of the structs was 
> only primitive types, but I can't find it now.
> 
> Perhaps it could be considered OK at least when the intended platforms are 
> known to be only iOS devices?

I think you’re misunderstanding what I’m saying.  It isn’t correct to take 
(e.g.) an unsafepointer to the beginning of a struct, and serialize that out to 
disk, and expect that the fields are emitted in some order with some specific 
padding between them.  None of the uses above try to do this.

-Chris


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

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

[Benjamin Herzog via swift-evolution]

In Scala you can implement an apply method which makes it possible to call an 
object just like a function. Example:

case class Foo(x: Int) {
def apply(y: Int) = x + y
}

val foo = Foo(3)
val bar = foo(4)

That is similar to what you suggested to have a possibility to convert an 
object to a closure getting called. And I totally see the point for this! I 
think using a keyword or special name like apply is not a good idea because 
it's not obvious what it does and it also makes it possible to just call the 
method with its name: foo.apply(4).

However, having a protocol is kinda hard because it's not possible to have a 
flexible parameter list. Maybe having a method without a name? Swift example:

class Foo {
var x: Int
init(x: Int) { self.x = x }

func (y: Int) -> Int {
return self.x + y
}
}

let foo = Foo(x: 3)
let bar = foo(y: 4)

I actually like that, would be like an anonymous function. It would also be 
possible to have multiple of those defined for one object (which would have to 
be unambiguous of course).

So getting back to KeyPath, it could look like this:

class KeyPath {
func (_ root: Root) -> Value {
return root[keyPath: self]
}
}

I see that this would be a much bigger change and would not justify the 
syntactic sugar for map, flatMap, etc. But it would still be a nice addition to 
the Swift programming language, especially for KeyPath, transformers etc.

What do you think?
__

Benjamin Herzog



> On 9. Jul 2017, at 13:09, Karl Wagner  wrote:
> 
> I agree that it should be completely implicit.
> 
> KeyPaths are simply chains of partially-applied properties and subscripts. At 
> the same time, it was noted in the KeyPath proposal that a similar mechanism 
> might be used to model chains of partially-applied functions. I think that 
> having both types be convertible to a closure would be sensible.
> 
> In fact, you could argue for a general-purpose “Executable” protocol which 
> would allow any conforming object to be implicitly used as a 
> function/closure. Command-style objects such as predictes and transformers 
> would also benefit from such a feature.
> 
> - Karl
> 



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

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

[Karl Wagner via swift-evolution]

  
  

 I agree that it should be completely implicit.
  

  
KeyPaths are simply chains of partially-applied properties and subscripts. At 
the same time, it was noted in the KeyPath proposal that a similar mechanism 
might be used to model chains of partially-applied functions. I think that 
having both types be convertible to a closure would be sensible.
  

  
In fact, you could argue for a general-purpose “Executable” protocol which 
would allow any conforming object to be implicitly used as a function/closure. 
Command-style objects such as predictes and transformers would also benefit 
from such a feature.
  

  
- Karl
  

  

  

  

  
  

  
  
>   
> On Jul 8, 2017 at 11:56 pm,   (mailto:swift-evolution@swift.org)>  wrote:
>   
>   
> 
> Is this operator common in other languages? I would actually expect that the 
> conversation is not 'almost-implicit' but completely implicit instead. I 
> think both - a prefix and postfix operator - are not obvious enough what 
> happens here,   especially because this kind of conversion is not happening 
> in other parts of the language.  
> All conversions are implicit (from explicit type to protocol, from Swift 
> stdlib types to Objective-C types, from any type to Any, …) currently.
>   
>
>   
>   
> __
>   
>
>   
> Benjamin Herzog
>   
>   
>   
> 
>   
> >   
> > On 8. Jul 2017, at 22:10, Hooman Mehr via swift-evolution  
> >   wrote:
> >   
> >   
> > 
> > I like this promote operator idea. I have been defining similar operators 
> > for specific projects almost at random. It makes sense to come up with a 
> > well-defined behavior and name for such operators, as a common practice as 
> > you suggest.  
> >
> >   
> > The problem with the postfix operator is that it does not currently work 
> > without an extra set of parenthesis:
> >   
> >
> >   
> >   
> > postfix  operator  ^
> >   
> >
> >   
> > postfix   func  ^(lhs:  KeyPath) ->  (T)->U  {  return  { 
> > $0[keyPath: lhs] } }
> >   
> >
> >   
> > struct  Guy {  let  name:  String  }
> >   
> >
> >   
> > let  guys = [
> >   
> > Guy(name:  "Benjamin"),
> >   
> > Guy(name:  "Dave"),
> >   
> > Guy(name:  "Brent"),
> >   
> > Guy(name:  "Max")
> >   
> > ]
> >   
> >
> >   
> > guys.map(\.name^)  // Error: Invalid component of Swift key path
> >   
> >
> >   
> > guys.map((\.name)^)  // This works
> >   
> >   
> >
> >   
> > Is this a bug?   
> >   
> >
> >   
> > That is the reason I used a prefix operator (~) in my suggestion in the a 
> > previous e-mail on this thread.
> >   
> >   
> >   
>   
>   
>  ___ 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] [Proposal] Introduces endianness specific type

[Jens Persson via swift-evolution]

On Sat, Jul 8, 2017 at 6:28 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Susan,
>
> Swift does not currently specify a layout for Swift structs.  You
> shouldn’t be using them for memory mapped i/o or writing to a file, because
> their layout can change.  When ABI stability for fragile structs lands, you
> will be able to count on it, but until then something like this is probably
> a bad idea.
>
> -Chris
>

Does this imply that you should never use Swift structs to eg interact with
Metal?

This seems to be a very common practice. Here is a typical example (from a
Metal tutorial at raywenderlich.com):

struct Vertex {
  var x,y,z: Float // position data
  var r,g,b,a: Float   // color data

  func floatBuffer() -> [Float] {
return [x,y,z,r,g,b,a]
  }
}

(
https://www.raywenderlich.com/146416/metal-tutorial-swift-3-part-2-moving-3d
 )

Also, does it imply that we cannot use structs (of only primitive types)
like:

struct RgbaFloatsLinearGamma {
var r, g, b, a: Float
…
}
struct BgraBytesSrgbGamma {
var b, g, r, a: UInt8
}

for manipulating raster image data?

I vaguely remember a swift evo discussion where it was concluded that such
usage was considered OK provided the stored properties of the structs was
only primitive types, but I can't find it now.

Perhaps it could be considered OK at least when the intended platforms are
known to be only iOS devices?

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

[swift-evolution] [Accepted] SE-0180: String Index Overhaul

[John McCall via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md
 


The second review of “SE-0180: String Index Overhaul" ran from June 22nd – 
28th, 2017.

The proposal is accepted.  There was a lively discussion about it, but in the 
end everyone seems to agree that this is the right thing to do.

As always, I'd like to thank you for your help in making Swift a better 
language.

John McCall
Core Team___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution