On Thu, Jun 2, 2016 at 2:25 PM Xiaodi Wu <[email protected]> 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 <[email protected]> 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 < >> [email protected]> wrote: >> >>> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution < >>> [email protected]> wrote: >>> >>>> On Jun 2, 2016, at 1:43 PM, Russ Bishop <[email protected]> wrote: >>>> >>>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution < >>>> [email protected]> 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 >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
