4 ms·

Yeah first being a property is weird to me too. Although I do believe Swift has "virtual properties" that are really a method under the hood.

deleted 8y ago
[deleted]
skohan 8y ago
The reverse seems weird to me. Things like the first element, or the count of an array seem conceptually more like properties than functions: they're just values derived from the data structure. The fact that you need to use function call syntax for things like this in other languages seems like it is unnecessarily exposing implementation details to the API because of limitations of the language.
- romanovcode 8y ago
  Or maybe they just opt for it for the simplicity sake? Just like said above, the first is just a magic getter which is a function underneath anyway.
  - skohan 8y ago
    But why should I as the user of an interface care whether something is implemented as a function or whether it's just a reference to a pure value? For instance, let's imagine in some C++-like language I had two list implementations: one static and one dynamic: class StaticList { ... int count; // set at initialization time } class DynamicList { ... int count() { ... // compute the count dynamically return count; } } Here `count` is conceptually the same between these two implementations, but if I want to get that value, I have to access it differently: int c1 = staticList.count; int c2 = dynamicList.count(); But that difference is essentially an implementation detail which means nothing to the client. The Swift way just lets me express my interface however I decide is most fitting.
    - dbaupp 8y ago
      There is a useful distinction between "properties" and "functions" that appears in some languages: properties exist in memory and so can be addressed. This is particularly important for "systems"/low-level programming, where addresses are often manipulated directly and need to be stable/controlled. In languages like C, C++ and Rust, properties are things that are definitely in memory, and functions/methods are things that may not be. If you have an interface like `count` that may be dynamic, it should be uniformly expressed as a method/function (that may have a trivial "return count;" implementation). On the other, Swift has to put a non-trivial amount of infrastructure into making sure all the things with property syntax can behave as if they are backed by memory, so that an address/pointer can be generated for them (in the general case, a temporary pointer, that becomes invalid quickly).
    - kibwen 8y ago
      The reason that performance-oriented languages like C++ and Rust make a distinction there is to make it easier for someone reading the code to understand the performance implications of a piece of code. Accessing a field involves jumping to a statically-known offset, which is a minor and predictable cost, whereas calling a function could have any cost imaginable. It's reasonable for languages that prioritize ergonomics over extreme performance to make the decision to paper over that distinction.
- the_duke 8y ago
  For me it's exactly the other way around. Having "first" as a property feels like exposing implementation details to me. Sure, a array/vector is a contiguous slice of memory filled with items of a certain size. But the vector/array is is basically a pointer to the start of the memory + a size, so "first" is not a inherent part of the data structure, rather a computed/derived property. When I see a property I think member of a struct, which is not the case here. (ps: this is all really just hair splitting, it's a minor difference that you would get used to pretty quickly either way)
  - wool_gather 8y ago
    It's a reasonable point. But here `first` is actually declared in the `Collection` interface, which `Array` implements. There's no guarantee about what it's actually doing. (Although possibly it has a documented expectation to be O(1), can't remember at the moment.)
    - saagarjha 8y ago
      Collection's startIndex and subscripting is supposed to be O(1), so I'd assume that first is also supposed to be O(1) since it's trivial to implement it by composing the first two (in fact, this is how Swift implements it by default if you don't override it: https://github.com/apple/swift/blob/e08b2194487d883896a377a0f343577775845cd3/stdlib/public/core/Collection.swift#L1095 https://github.com/apple/swift/blob/e08b2194487d883896a377a0...)

deleted 8y ago

[deleted]

skohan 8y ago

The reverse seems weird to me. Things like the first element, or the count of an array seem conceptually more like properties than functions: they're just values derived from the data structure. The fact that you need to use function call syntax for things like this in other languages seems like it is unnecessarily exposing implementation details to the API because of limitations of the language.

romanovcode 8y ago
Or maybe they just opt for it for the simplicity sake? Just like said above, the first is just a magic getter which is a function underneath anyway.
- skohan 8y ago
  But why should I as the user of an interface care whether something is implemented as a function or whether it's just a reference to a pure value? For instance, let's imagine in some C++-like language I had two list implementations: one static and one dynamic: class StaticList { ... int count; // set at initialization time } class DynamicList { ... int count() { ... // compute the count dynamically return count; } } Here `count` is conceptually the same between these two implementations, but if I want to get that value, I have to access it differently: int c1 = staticList.count; int c2 = dynamicList.count(); But that difference is essentially an implementation detail which means nothing to the client. The Swift way just lets me express my interface however I decide is most fitting.
  - dbaupp 8y ago
    There is a useful distinction between "properties" and "functions" that appears in some languages: properties exist in memory and so can be addressed. This is particularly important for "systems"/low-level programming, where addresses are often manipulated directly and need to be stable/controlled. In languages like C, C++ and Rust, properties are things that are definitely in memory, and functions/methods are things that may not be. If you have an interface like `count` that may be dynamic, it should be uniformly expressed as a method/function (that may have a trivial "return count;" implementation). On the other, Swift has to put a non-trivial amount of infrastructure into making sure all the things with property syntax can behave as if they are backed by memory, so that an address/pointer can be generated for them (in the general case, a temporary pointer, that becomes invalid quickly).
  - kibwen 8y ago
    The reason that performance-oriented languages like C++ and Rust make a distinction there is to make it easier for someone reading the code to understand the performance implications of a piece of code. Accessing a field involves jumping to a statically-known offset, which is a minor and predictable cost, whereas calling a function could have any cost imaginable. It's reasonable for languages that prioritize ergonomics over extreme performance to make the decision to paper over that distinction.
the_duke 8y ago
For me it's exactly the other way around. Having "first" as a property feels like exposing implementation details to me. Sure, a array/vector is a contiguous slice of memory filled with items of a certain size. But the vector/array is is basically a pointer to the start of the memory + a size, so "first" is not a inherent part of the data structure, rather a computed/derived property. When I see a property I think member of a struct, which is not the case here. (ps: this is all really just hair splitting, it's a minor difference that you would get used to pretty quickly either way)
- wool_gather 8y ago
  It's a reasonable point. But here `first` is actually declared in the `Collection` interface, which `Array` implements. There's no guarantee about what it's actually doing. (Although possibly it has a documented expectation to be O(1), can't remember at the moment.)
  - saagarjha 8y ago
    Collection's startIndex and subscripting is supposed to be O(1), so I'd assume that first is also supposed to be O(1) since it's trivial to implement it by composing the first two (in fact, this is how Swift implements it by default if you don't override it: https://github.com/apple/swift/blob/e08b2194487d883896a377a0f343577775845cd3/stdlib/public/core/Collection.swift#L1095 https://github.com/apple/swift/blob/e08b2194487d883896a377a0...)