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 cast another vote in favor

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 struct approach (alternativ

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 r

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 wh

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 misleading and that it would be > better to ask people to just use a type explici

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 possible to write your own > type(of:), so we're going from a "magic" prop

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 > that reads nicely regardless of the situation with

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] - is it an array with > one element (Int.self), or is

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

on Wed Jun 01 2016, Xiaodi Wu 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 > > wrote: > > Upon accepting SE-0098, the core team renamed the proposed stdlib function > from dynamicType() to type(of:). They w

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 J

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

Looks good! I definitely like the ‘memory’ prefixes for the functions. I appreciate that stating the name earlier with the functions vs MemoryLayout.blah is easier to read. It feels a little bit of a shame to make `memorySize(ofType:)` longer than `memorySize(of:)`, as I think it will be used m

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 R

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: Int >> let stride: Int >>

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:) a

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

On Jun 2, 2016, at 16:57, Sean Heber via swift-evolution mailto:swift-evolution@swift.org>> 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 >

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 stride: Int > // etc >

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 best to come up with a cons

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 conjuncti

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 quite apt. These operations ar

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 prefi

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 'UnsafeMutablePointer' vs '*T'. >>

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 memoryLayout(ofType

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

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

> On Jun 2, 2016, at 3:35 PM, Tony Allevato via swift-evolution > wrote: > > On Thu, Jun 2, 2016 at 2:25 PM Xiaodi Wu > 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 ana

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 advant

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

On Thu, Jun 2, 2016 at 2:25 PM Xiaodi Wu 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 quite apt. > > And I'm not sure we really want to encourage anyone else to be

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 > mailto: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-evolut

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 >> mailto:swift-evolution@swift.org>> wrote: > > Yes, I think that it is

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 come one > day, maki

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 wou

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

While I prefer Russ's approach...I actually find the MemoryLayout API much easier to read than the current way. Namely: - it stands out more and makes it clearer what you are doing - less parens everywhere :) Brandon > On Jun 2, 2016, at 3:58 PM, Erica Sadun via swift-evolution > wrote: >

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 "memor

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 value-based APIs are mi

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 >> mailto:swift-evolution@swift.org>> 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. >> >

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 >> mailto:swift-evolution@swift.org>> 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

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 type itself? The type is wh

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 'UnsafeMutablePointer' vs '*T'. > Verbosity

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, 2016, at 11:22 AM, Matthew Johnson wrote: On Jun 2, 2016, at

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 >> > wrote: >>> On Jun 2, 2016, at 12:01 PM, John McCall >

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

Sent from my iPad > On Jun 2, 2016, at 1:30 PM, John McCall wrote: > >> 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 > wrote: > On Jun 2, 2016, at 1

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 >>> mailto:swift-evolution@swift.org>> wrote: On Jun 2, 2016, at 10:38 AM, Xiaodi Wu >>

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 understand it, it's not actually possible to write your own >>> type(of

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 >> type(of:), so we're going from a "magic" property to a "mag

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> struct MemoryLayout { >>> init(

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> struct MemoryLayout { >> init() {} >> init(t: T) { /* throw away the value */ } >> >> // we could omit t

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

> 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 */ } > // … > } > > let sizeOfValue = MemoryLayout(42).size You could also use @auto

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

MemoryLayout is reminiscent of how of how mirror types are wrap around underlying data they represent... so that would add to the regularity if the runtime lib. Not to mention there are precedents outside swift. > On Jun 2, 2016, at 5:56 PM, Xiaodi Wu via swift-evolution > wrote: > > Both goo

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

> On Jun 2, 2016, at 9:48 AM, Matthew Johnson via swift-evolution > wrote: > > struct MemoryLayout { > init() {} > init(t: T) { /* throw away the value */ } > > // we could omit the static properties and require > // writing MemoryLayout() if we don’t like the duplication

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 we're going from a "magic" property to a "magic" f

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 accepts any value (you *ca

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

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. I'm most alarmed that one implication of the MemoryLayout proposal is loss of the `ofValue` family of functions. These functions don't fi

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? IIRC Joe Groff was going to wo

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 core team decision:

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 2, 2016, at 9:43 AM, Erica

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 they

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 169 4880 > sizeofVal

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

And following up to myself. Please look here: https://github.com/erica/swift-evolution/blob/0f93c3c31b1d59358a61a5e2608dc71a598d9316/proposals/-sidestride.md Plus, I fixed the typos in strideof/strideofValue's counts. -- E > On Jun 2, 2016, at 8:43 AM, Erica Sadun via swift-evolution > w

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: X.self)`, when `X` is a class type,

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 dynamicType), so I think it makes sense for it to

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 >>> wrote: >> >>> Upon accepting SE-0098, the core team renamed the proposed

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 alig

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 with `type(of:)`. If we

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, 2016 at 12:24 AM, Patric

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 be extended with new

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 disc

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

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 discoverability, we might want to have > @avai

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.") > public init(){}. >

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:). They write, "The core tea

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 > mailto: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 cor

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 resy

[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 discu