Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

This is a good point. This should, perhaps, be address using #if arch(x86_64), but you are right that many systems have some system typedefs defined otherwise even on the same architecture, which may be painful to deal with. > Is there any need to consider the following common C sizeof() usage,

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

+1 on #3 3. MemoryLayout.size http://i.gifntext.com/29412-number-3-my-lord.gif > On Jun 6, 2016, at 3:37 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Jun 06 2016, Nate Cook wrote: > >> I'd like to

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> Le 3 juin 2016 à 17:11, Erica Sadun via swift-evolution > a écrit : > > Discussion has more or less drawn down. Are there any further significant > requests / issues that need addressing? Both standalone functions (my > recommended approach) and the MemoryLayout

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Mon Jun 06 2016, Nate Cook wrote: > I'd like to cast another vote in favor of something like the > MemoryLayout struct. In general, people aren't always making the right > choice about which of these values to use. Combining them into one > data type would mean they see that there are three

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

I'd like to cast another vote in favor of something like the MemoryLayout struct. In general, people aren't always making the right choice about which of these values to use. Combining them into one data type would mean they see that there are three related values and can find out when to use

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, John McCall wrote: > On Jun 2, 2016, at 1:43 PM, Russ Bishop wrote: > > On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution > > wrote: > > I still think the value-based APIs are

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, John McCall wrote: > On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution > > wrote: > > On Jun 2, 2016, at 10:38 AM, Xiaodi Wu wrote: > > Well, as I understand it, it's not actually

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, Matthew Johnson wrote: > On Jun 2, 2016, at 10:03 AM, Xiaodi Wu wrote: > > That proposal was returned for revision; as far as user ergonomics in Swift > 3, .self is going to be a consideration. Best to find a solution >

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, Matthew Johnson wrote: > On Jun 2, 2016, at 10:01 AM, Charlie Monroe > wrote: > > Isn’t this a short-term concern? I thought that requirement was going away. > > AFAIK there are still concerns about ambiguity - [Int]

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On 04 Jun 2016, Erica Sadun wrote: > > Discussion has more or less drawn down. Are there any further significant > requests / issues that need addressing? Both standalone functions (my > recommended approach) and the MemoryLayout struct approach (alternative, > with reasons why I think it's

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

There was also my suggestion for a function such as memoryLayout(of:) that returned an instance of a simple MemoryLayout struct which I believe is a bit different than the MemoryLayout generics approach. I’m not sure if that was expressly shot down or ruled out or not, though. l8r Sean > On

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

In defense of MemoryLayout's "less clarity", the people who know enough to use that stuff won't have trouble understanding it. That said, while I like it, I'm mostly interested in sequestering this stuff away in a type as a step towards a some sort of vague macro system. Since that's obviously

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Discussion has more or less drawn down. Are there any further significant requests / issues that need addressing? Both standalone functions (my recommended approach) and the MemoryLayout struct approach (alternative, with reasons why I think it's not as ideal) are discussed in-proposal. Pull

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad On Jun 3, 2016, at 7:08 AM, Brent Royal-Gordon wrote: >> This might be silly, but what if there were a struct with all of the >> relevant fields (not sure what the best name would be): >> >> struct MemoryLayout { >> let size: Int >> let alignment:

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> This might be silly, but what if there were a struct with all of the relevant > fields (not sure what the best name would be): > > struct MemoryLayout { > let size: Int > let alignment: Int > let stride: Int > // etc > } > > Then you’d only maybe need two functions: > > memoryLayout(of:)

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Jun 2, 2016, at 16:57, Sean Heber via swift-evolution > wrote: > This might be silly, but what if there were a struct with all of the relevant > fields (not sure what the best name would be): > > struct MemoryLayout { > let

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 4:57 PM, Sean Heber wrote: > > This might be silly, but what if there were a struct with all of the relevant > fields (not sure what the best name would be): > > struct MemoryLayout { > let size: Int > let alignment: Int > let

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution > wrote: > > Isn't this the same argument for .dynamicType over type(of:) though? > > Given that that debate has been settled in favor of the latter, I think the > question today is how

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

As I said above, I disagree. Unsafe things should have names that call attention to themselves. Safe things should not, *especially* if they're unsafe-adjacent. It's not useful in a line of code to have every part of it competing for your attention merely because they're typically used in

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 4:25 PM, Xiaodi Wu via swift-evolution > wrote: > > On the other hand, on its own sizeof() is not unsafe, and so the argument > that it should be longer to call attention to itself (by analogy with > UnsafePointer) isn't

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Nope. I use it with Metal buffers, for example :) Moreover, there's nothing inherently unsafe about sizeof, and I think it's important, *especially when you're working with UnsafePointers*, that safe things look safe. If the moment a pointer comes into the picture everything related to it is

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 3:55 PM, Brent Royal-Gordon wrote: > >> I don't disagree with the points you make. But one can argue that this is a >> good thing. It calls attention to code that requires extra attention and >> care. In some ways this is similar to

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

This might be silly, but what if there were a struct with all of the relevant fields (not sure what the best name would be): struct MemoryLayout { let size: Int let alignment: Int let stride: Int // etc } Then you’d only maybe need two functions: memoryLayout(of:) and

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> I don't disagree with the points you make. But one can argue that this is a > good thing. It calls attention to code that requires extra attention and > care. In some ways this is similar to 'UnsafeMutablePointer' vs '*T'. > Verbosity was a deliberate choice in that case. You

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Isn't this the same argument for .dynamicType over type(of:) though? Given that that debate has been settled in favor of the latter, I think the question today is how best to come up with a consistent scheme. Earlier in this conversation, it was pointed out (by Matt, I think?) that one key

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu wrote: > On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution > > wrote: >> On Jun 2, 2016, at 1:43 PM, Russ Bishop >

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 3:28 PM, John McCall via swift-evolution > wrote: > >> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu > > wrote: >> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution >>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu wrote: > > > In the earlier conversation, it was pointed out (by Dave A., I think?) that > examples such as Array.size show how this solution can get confusing. And > even though there aren't fixed-length arrays in Swift, those may

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On the other hand, on its own sizeof() is not unsafe, and so the argument that it should be longer to call attention to itself (by analogy with UnsafePointer) isn't quite apt. And I'm not sure we really want to encourage anyone else to be defining a global function named size(of:) anyway, so I

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Given that these are fairly low-level values with very specialized uses, I definitely agree that they should be somehow namespaced in a way that doesn't cause us to make very common words unusable for our users. Even size(of:) seems more general to me than I'd like. I'd like to see the word

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 2, 2016, at 1:43 PM, Russ Bishop wrote: > > On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > > I still think the

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 1:43 PM, Russ Bishop wrote: >> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution >> > wrote: >> >> I still think the value-based APIs are misleading and that it would be >> better to

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 2:43 PM, Russ Bishop wrote: > > >> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution >> > wrote: >> >> I still think the value-based APIs are misleading and that it would be >>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution > wrote: > > I still think the value-based APIs are misleading and that it would be better > to ask people to just use a type explicitly. > > John. I agree; in fact why aren’t these properties on the

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 2:13 PM, Matthew Johnson wrote: > I don't disagree with the points you make. But one can argue that this is a > good thing. It calls attention to code that requires extra attention and > care. In some ways this is similar to

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 2:58 PM, Erica Sadun wrote: > > >> On Jun 2, 2016, at 12:47 PM, Matthew Johnson via swift-evolution >> wrote: >> On Jun 2, 2016, at 1:30 PM, John McCall wrote: >> On Jun 2,

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 12:47 PM, Matthew Johnson via swift-evolution > wrote: > On Jun 2, 2016, at 1:30 PM, John McCall > wrote: > >>> On Jun 2, 2016, at 11:22 AM, Matthew Johnson >>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 11:22 AM, Matthew Johnson wrote: > On Jun 2, 2016, at 12:01 PM, John McCall > wrote: > >>> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 12:01 PM, John McCall wrote: > >>> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution >>> wrote: >>> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu wrote: >>> >>> Well, as I

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution > wrote: >> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu > > wrote: >> >> Well, as I understand it, it's not actually possible to write your own >>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 10:12 AM, Matthew Johnson wrote: >> On Jun 2, 2016, at 11:04 AM, Erica Sadun > > wrote: >>> On Jun 2, 2016, at 9:48 AM, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 11:04 AM, Erica Sadun wrote: > > >> On Jun 2, 2016, at 9:48 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> struct MemoryLayout { >> init() {} >> init(t: T) { /* throw

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 11:04 AM, Pyry Jahkola wrote: > >> Matthew Johnson wrote: >> >> Going with MemoryLayout *does not* mean we would have to give up the value >> functions if we don’t want to: >> >> struct MemoryLayout { >> init(t: T) { /* throw away the value */ }

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Both good points. I could live with your solution. On Thu, Jun 2, 2016 at 10:48 AM Matthew Johnson wrote: > On Jun 2, 2016, at 10:38 AM, Xiaodi Wu wrote: > > Well, as I understand it, it's not actually possible to write your own > type(of:), so

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu wrote: > > Well, as I understand it, it's not actually possible to write your own > type(of:), so we're going from a "magic" property to a "magic" function at > least for now. No, but you *can* write `func foo(_ t: T)` which

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 10:01 AM, Charlie Monroe wrote: > >> Isn’t this a short-term concern? I thought that requirement was going away. > > AFAIK there are still concerns about ambiguity - [Int] - is it an array with > one element (Int.self), or is it [Int].self?

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 10:03 AM, Xiaodi Wu wrote: > > That proposal was returned for revision; as far as user ergonomics in Swift > 3, .self is going to be a consideration. Best to find a solution that reads > nicely regardless of the situation with .self removal. From the

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

That proposal was returned for revision; as far as user ergonomics in Swift 3, .self is going to be a consideration. Best to find a solution that reads nicely regardless of the situation with .self removal. On Thu, Jun 2, 2016 at 9:57 AM Matthew Johnson wrote: > On Jun

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> Isn’t this a short-term concern? I thought that requirement was going away. AFAIK there are still concerns about ambiguity - [Int] - is it an array with one element (Int.self), or is it [Int].self? > >> For this reason, this proposal prefers using no-label calls for types >> (otherwise

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 9:43 AM, Erica Sadun wrote: > > Supporting Dave A, type-based calls are much more likely to be used than > instance calls, unlike with dynamicType/type(of:) > > Term stdlib search gist search Google site:github +swift > sizeof157

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Supporting Dave A, type-based calls are much more likely to be used than instance calls, unlike with dynamicType/type(of:) Termstdlib search gist search Google site:github +swift sizeof 157 169 4880 sizeofValue 4 34 584 alignof 44 11 334 alignofValue

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad On Jun 2, 2016, at 6:26 AM, Brent Royal-Gordon via swift-evolution wrote: >> /// Returns the contiguous memory footprint of `T`. >> /// >> /// Does not include any dynamically-allocated or "remote" storage. >> /// In particular, `size(of:

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad >> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith wrote: >> I really like this idea. This IMO is lower level functionality than >> `type(of:)` (née

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Sent from my iPad > On Jun 2, 2016, at 12:05 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Wed, Jun 1, 2016 at 11:55 PM, Xiaodi Wu wrote: >>> On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> /// Returns the contiguous memory footprint of `T`. > /// > /// Does not include any dynamically-allocated or "remote" storage. > /// In particular, `size(of: X.self)`, when `X` is a class type, is the > /// same regardless of how many stored properties `X` has. > public func size(of: T.Type) ->

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Yeah I realise who Dave is :) Ok, that’s good to know about your uses. An extra benefit that MemoryLayout has is a developer who is familiar with sizeof() from other languages (I only know of C), if it was called the same thing in Swift they might just go ahead and use it and add their own

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Thu, Jun 2, 2016 at 12:37 AM, Patrick Smith wrote: > Yes but, if they weren’t functions now, what would be the best design? > Dave's suggestions then were made in the context of a language that had `.dynamicType`. The question today is how best to align these functions

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Yes but, if they weren’t functions now, what would be the best design? How many Swift developers will be using this functionality? Less than 1%? I trust Dave’s judgement because he is in that small group. > On 2 Jun 2016, at 3:27 PM, Xiaodi Wu wrote: > > On Thu, Jun 2,

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith wrote: > I really like this idea. This IMO is lower level functionality than > `type(of:)` (née dynamicType), so I think it makes sense for it to be > grouped under its own domain, the MemoryLayout type. > > Plus MemoryLayout can

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Using MemoryLayout is a much bigger change than the simple name changes being pitched here. I'm not ruling it out, but it may be deferred or additive as the 3.0 timeline allows and the core team decides. For now, my suggested design (strongly based on Wux's feedback and the previous thread

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

I really like this idea. This IMO is lower level functionality than `type(of:)` (née dynamicType), so I think it makes sense for it to be grouped under its own domain, the MemoryLayout type. Plus MemoryLayout can be extended with new convenience methods. I’m fine with those old methods being

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 1, 2016, at 11:10 PM, Xiaodi Wu wrote: > > On Thu, Jun 2, 2016 at 12:03 AM, Jacob Bandes-Storch > wrote: > If it's worth continuing the discussion in this thread, I rather like the > MemoryLayout.size idea. For

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Thu, Jun 2, 2016 at 12:03 AM, Jacob Bandes-Storch wrote: > If it's worth continuing the discussion in this thread, I rather like the > MemoryLayout.size idea. For discoverability, we might want to have > @availability(*, unavailable, message: "use MemoryLayout.size, etc.")

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Wed, Jun 1, 2016 at 11:55 PM, Xiaodi Wu wrote: > On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > >> Upon accepting SE-0098, the core team renamed the proposed stdlib >> function from dynamicType() to type(of:).

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 1, 2016, at 10:55 PM, Xiaodi Wu wrote: > > On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution > > wrote: > Upon accepting SE-0098, the core team renamed the proposed stdlib function > from

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

If it's worth continuing the discussion in this thread, I rather like the MemoryLayout.size idea. For discoverability, we might want to have @availability(*, unavailable, message: "use MemoryLayout.size, etc.") public init(){}. Jacob On Wed, Jun 1, 2016 at 9:55 PM, Xiaodi Wu via swift-evolution

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > Upon accepting SE-0098, the core team renamed the proposed stdlib function > from dynamicType() to type(of:). They write, "The core team recognizes > that this means that we should probably

[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

Upon accepting SE-0098, the core team renamed the proposed stdlib function from dynamicType() to type(of:). They write, "The core team recognizes that this means that we should probably resyntax the existing sizeof/strideof functions, but that should be a follow-on discussion." Follow on