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

[Tony Allevato]

On Thu, Jun 2, 2016 at 2:25 PM Xiaodi Wu <xiaodi.wu at gmail.com> 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 defining a
> global function named size(of:) anyway, so I wouldn't consider vacating
> that name for end-user purposes to be a meaningful positive.
>

I was thinking more of situations where someone is in a scope (such as a
method in a struct or class) that has its own size(of:) method but also
needs to do something with the global size(of:) and now has to distinguish
the two. I'll admit that the likelihood of all of those stars aligning is
probably rare, though.

That being said, I see no reason to choose a very general name over one
that is far more descriptive. We should optimize for the N times an
expression is read instead of the one time it's written.



> On Thu, Jun 2, 2016 at 16:15 Tony Allevato <allevato at google.com> wrote:
>
>> 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 "memory" as part of the name somehow, whether it's a wrapping type
>> or a function prefix of some sort. These values are specialized; we don't
>> need to optimize typing them, IMO.
>>
>> On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> On Jun 2, 2016, at 1:43 PM, Russ Bishop <xenadu at gmail.com> wrote:
>>>>
>>>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <
>>>> swift-evolution at 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.
>>>>
>>>> John.
>>>>
>>>>
>>>>
>>>> I agree; in fact *why aren’t these properties on the type itself*? The
>>>> type is what matters; why can’t the type just tell me it’s size?
>>>> Having free functions or magic operators seems to be another holdover
>>>> from C.
>>>>
>>>>
>>>>     Int.size
>>>>     Int.alignment
>>>>     Int.spacing
>>>>
>>>>     let x: Any = 5
>>>>     type(of: x).size
>>>>
>>>>
>>>> The compiler should be able to statically know the first three values
>>>> and inline them. The second is discovering the size dynamically.
>>>>
>>>>
>>>> Two reasons.  The first is that this is a user-extensible namespace via
>>>> static members, so it's somewhat unfortunate to pollute it with names from
>>>> the library.  The second is that there's currently no language mechanism
>>>> for adding a static member to every type, so this would have to be
>>>> built-in.  But I agree that in the abstract a static property would be
>>>> preferable.
>>>>
>>>
>>> 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, making the syntax even more confusing.
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160602/97bf70ab/attachment.html>