Dot-prefixing considered ugly

tera · 2023-04-13T19:43:50.973Z

ExFalsoQuodlibet:

foo(.d(.c(.b(.a))))

I don't think you necessarily need static methods here, even for IDE autocomplete to work, for example once you typed "foo(" one of the autocomplete options could be "D()", once you autocomplete it to "foo(D(" IDE presents you with another autocomplete with "C()" as one of the options, etc, so at the end of the day you are getting autocompleted:

foo(D(C(B(a))))

which is arguably less noisy then the dot prefixed version:

foo(.d(.c(.b(a))))

Not to mention you won't need to have those static initialising methods to begin with – another source of noise – and if you do have those as statics and that's a class - subclass implementers would be very very unhappy.

Regardless, even the foo(D(C(B(a)))) version would feel backward to me (literally), with all those brackets, which in reality could be much worse due to function arguments:

foo(D(C(B(a), xxx()), options: Options(...)))

I'd try to make it fluid-style till the very end if possible:

a.b.c.d.foo()

which wraps nicely for more complex expressions:

    someObject[1]
        .someMethod(param1, param2)
        .someOtherMethod(...)
        .yetAnotherThing
        .foo()

jeremyabannister:

Yes, this is true, but you do know something concrete about foo(.red), which is that red is a static member of the argument type, which more importantly implies that the value is not being influenced by the instance that is making the call, which is a useful piece of knowledge that goes completely out the window with foo(red).

It might be important (and since you brought it up I'd like to know your opinion on the opposite change where you always know the variable scope, no ifs, no buts), would you prefer that change to the current swift version? If the difference between static and everything else is so important, perhaps as important is the difference between local, global and instance variables, and then the opposite change is what we'd like to have ideally (along with always requiring dot-prefixing for statics like in the examples in the quoted message)?

Two considerations that intend to show that the importance of knowing whether the variable is static or not (or, equally, whether this case is frequent enough in practice to bother about) is exaggerated:

remember (now dead) Hungarian notation. People advocating that also claimed "how else would we know the difference". In fact the current responses defending dot prefixes remind me Hungarian notation advocacy a lot.
Other languages (dozens of those) are quite happy without dot-prefixing static members (unless those that require full notation like C.foo). There are no attempts to borrow dot-prefixing from swift to other languages (while some other swift features – like optional chaining – were borrowed). If dot-prefixing was clearly superior it would have been copied to other languages.

jeremyabannister · 2023-04-13T20:06:01.131Z

The Art of Programming

This topic suddenly feels to me analogous to a vaguer concept that I've thought about, which is about where to start when trying to achieve something in code. I have noticed that there are two quite different but equally valid places to start, which could be called "the top" and "the bottom". I basically bounce back and forth between the two, digging down from the top and stacking up from the bottom until the two tunnels run into each other. Then I refactor. I think that the debate about whether to use nested static members or chained instance members might be analogous to the debate about whether to start from the top or the bottom (the answer being "both", I think).

For example, imagine I'm making a budgeting/finance tracker app which distinguishes itself from other similar apps by a particular piece of the interface that makes an important aspect of the interaction much nicer.

On the one hand, we should start with that piece of the interface. That screen was the motivating idea - it's the thing we know most clearly that we want, and for that reason it's the code that we will be able to make least wrong. The rest of the code should be a consequence of that key screen. Start with what you want, and then flesh it out until it works.

This approach is analogous to static members, where "starting with what you want" is typing . and selecting a static member, and "flesh it out until it works" is filling in the placeholder types until it's a fully and properly formed expression.

I think that that approach can sound perfect in theory ("perfect" as in, the only way it should ever be done), but the reality is that when fleshing out downwards it can be unclear what is the proper way to continue, and sometimes it is possible to flesh it out in a way the turns out to be fundamentally incompatible with the low-level tools that your code is eventually going to have to make contact with and use.

Therefore, another valid starting point is "the bottom", i.e., start not with what you know you want, but rather with what you know you have, and then build it up from there. For example, imagine that we didn't have UserDefaults yet, but we did have the lower-level tools that comprise it. We basically know that for out budgeting app we're going to want to work with persistence at the level of abstraction of UserDefaults, so we can fairly confidently begin to stack up our tools in that direction without worrying that it will be fundamentally incompatible with where we want to end up.

This approach is analogous to using instance members, where you start with what you know you have (e.g., responseData) and then you progressively transform it into what you want.

This approach could also sound perfect on paper, but it suffers from the same fundamental problem, which is that sometimes the way we stack things up turns out to be fundamentally incompatible with the high-level outcome that we were aiming at.

Therefore, bouncing between the two seems to me like the only way, and even then it remains an art, not a science.

xwu · 2023-04-13T20:13:04.592Z

tera:

I appreciate this would be a breaking change and no way we could possibly fit this change in swift at this stage. Forgetting that for a moment, do you think that Swift would have been better off or worse with the following change?

A gentle reminder that this is a working list which exists for the purpose of developing ideas for Swift's actual future evolution. We have a lot going on that's actually possible to implement which could really benefit from community attention and commentary, and counterfactuals/thought exercises in language design for some language other than what Swift can actually be—while fun—are probably best reserved for some other forum.

taylorswift · 2023-04-13T21:13:48.671Z

xwu:

and counterfactuals/thought exercises in language design for some language other than what Swift can actually be—while fun—are probably best reserved for some other forum.

while the scope of the original complaint is probably too broad to be useful, i think there is merit in discussing the drawbacks of leading-dot syntax - one of which is that it is utterly non-composable with result builders, because statements that begin with a leading dot parse as member references on the expression from the line above it.

Hacksaw · 2023-04-14T05:47:13.850Z

I kind of like the dot prefixes, but I'm not a fan of the Enum syntax. I turn everything into English sentences in my head, so I think of case in switches to read "in the case of".

I'm not sure what the syntax gets us, really. (Not a fan of the keyword "switch", either but that's another thing entirely).

The dot prefixes tell me that we're looking at a member of a type, not a variable or constant, and it's simple and clean. It might not be symmetric with the declaration, but the usage isn't symmetric either, one being a binding and the other a lookup.

Karl · 2023-04-14T07:27:20.651Z

jeremyabannister:

Why do you prefer this? To me the choice between explicit and implicit feels like a useful architectural tool that lets me exert some influence over the "ways in which my code churns", so to speak. The concrete effect that I'm referring to is of course the fact that when it's implicit, changing the type name causes no churn.

I don't find that it is true that changing a type name causes no churn; extensions, stored properties and enum payloads cannot always use inference, so if I change a type name, I'll almost always need to update other code to use the new name anyway (often using Xcode's refactor tool, so it's relatively painless).

Besides, I don't find that I change type names very often. Putting it all together, I feel that the decrease in readability isn't worth it. I have seen code that looks like .init(.init(.init(foo))), and I find that harder to reason about than if it had just said something like: Widget(String(Int(foo))).

That doesn't apply to all static members - as I said, a member named .red, for instance, clearly communicates that it is somewhat related to colours; .init just has so little information that I personally find it too opaque at the call site.

jeremyabannister · 2023-04-14T09:53:16.558Z

To be clear I was saying that when a particular initializer is implicit then that line will not churn if I change the type name, which reduces the overall churn.

Regarding readability:

Karl:

I feel that the decrease in readability isn't worth it.

Would you agree that my example is actually made more readable by the use of .init, because the type name would have just been redundant noise in the context of the parameter name?

jeremyabannister:

downloadVideoForOfflineUse(
    videoMetadata:
        responseData
            .jsonDecoded(as: FetchVideoMetadataRESTResponse.self)
            .asVideoMetadata(),
    downloadSettings:
        .init(
            useCellular: false,
            continueInBackground: true,
            completionNotification: .standardDownloadCompletionMessage
        )
)

A possible argument against this usage of .init that doesn’t have to do with readability is that in this case a change in type name could indicate a corresponding change that I should make to that argument label, which I would be alerted to if I have to churn and which I will miss if I don’t.

The thing is though that my type names are much more likely to change their phrasing or their clarifying additional words than their essence, which will often mean that argument labels such as the one in this example will continue to read perfectly even after the type name change (therefore, for now I continue to use .init in this way to what I think is good effect).

Lastly, those last two paragraphs made me realize that there’s actually one more argument for the positive readability of .init, which is that in examples like mine not only would the type name be redundant noise, in my code it would actually most often be an especially verbose and noisy name relative to the argument label (which I think is not just me, but rather a natural consequence of that types mostly share a global namespace while argument labels only have to be unambiguous within a much more restricted context).

Karl:

I have seen code that looks like .init(.init(.init(foo)))

With all of that said, yes I agree, this sucks.

Karl · 2023-04-14T13:19:32.425Z

Like I said, it's a matter of personal preference, but even in that example I don't feel .init makes up for the loss of clarity at the point of use:

// SomeFile.swift

struct SettingsA {
  var flag: Bool = false
}

struct SettingsB {
  var count: Int
}

func doTheThing(_: SettingsA) { print("A") }
func doTheThing(_: SettingsB) { print("B") }

// AnotherFile.swift

// Which does this call?
// Unclear unless I know a lot of details about the interfaces of SettingsA/B.

doTheThing(.init())

// What about these? Still not entirely obvious.
// There is much more required knowledge to understand what this does.

doTheThing(.init(flag: true))
doTheThing(.init(count: 42))

// And these? Much more obvious.

doTheThing(SettingsA())
doTheThing(SettingsA(flag: true))
doTheThing(SettingsB(count: 42))

By specifying the type name, I can have confidence that even people who are brand new to this codebase, and/or reading it using a non-sourcekit interface (e.g. GitHub), will immediately know exactly which type is being constructed, and which overload is being called.

IMO, anything that is not the most obvious thing needs good justification, and .init is almost never enough of a gain to make up for what we lose.

Also, I don't like the negative connotations of the word "churn", or the idea that minimising it should be a goal. My coding style is not designed to minimise the number of lines that need to be edited were some hypothetical future change to occur - it is designed to be clear to the people who actually read and maintain it now, as it is.

If I rename a type, it's because there's a new, better name for it, which better describes what it does. I do not mind at all if some code needs to be updated to use that better name.

Of course, I realise that not everybody feels the same way. It's a self-imposed rule to not use .init (or at least to use it very, very sparingly), but I feel that I can justify it and most people I've explained it to don't consider it an unreasonable position to take, even if they choose to continue using .init.

tera · 2023-04-14T13:39:56.424Z

I somewhat agree with that train of thought. But is it unique to "init" though?

struct Rgb {
    static func red(density: Int) -> Rgb { ... }
}
struct Cmyk {
    static func red(darkMode: Bool = false) -> Cmyk { ... }
}
func doTheThing(_: Rgb) { ... }
func doTheThing(_: Cmyk) { ... }

....

doTheThing(.red())
doTheThing(.red(darkMode: true))
doTheThing(.red(density: 0.42))

Obviously the clash of "init" name is quite probable, but it could happen with static function names (e.g. "normal", "default", "custom", etc, or even less generic names like "red" in the above example).

taylorswift · 2023-04-14T23:14:27.617Z

Karl:

Besides, I don't find that I change type names very often. Putting it all together, I feel that the decrease in readability isn't worth it. I have seen code that looks like .init(.init(.init(foo))), and I find that harder to reason about than if it had just said something like: Widget(String(Int(foo))).

usually when i write russian nesting inits it is because i actually meant Widget.init(foo), but the sugaring inits were not worth the additional boilerplate on Widget. if the interceding type conversions spelled out with Widget.init(String.init(Int.init(foo))) are not important or surprising i would prefer to read .init(.init(.init(foo))) because that communicates “this is just doing the obvious things to turn this Int into a Widget”.

here’s a common example i run into:

init?(parsing string:Substring)
{
    self.init(rawValue: .init(string))
}

self.init(rawValue: String.init(string)) doesn’t add anything meaningful, i am only copying the string because string-backed enums don’t know how to decode themselves from anything other than a String.

taylorswift · 2023-04-14T23:26:37.957Z

Karl:

By specifying the type name, I can have confidence that even people who are brand new to this codebase, and/or reading it using a non-sourcekit interface (e.g. GitHub), will immediately know exactly which type is being constructed, and which overload is being called.

you did not label the doTheThing(_:) arguments, which signals that SettingsA and SettingsB are merely different shapes of the same concept. if it were important to distinguish between them at the call site, i probably would have labeled them doTheThing(a:) and doTheThing(b:).

among

Karl:

struct SettingsA {
  var flag: Bool = false
}

struct SettingsB {
  var count: Int
}

only SettingsA is completely defaulted, which indicates to me that SettingsA.init(flag: false) is a sensible default value for the “doTheThing” operations. (if it’s not a globally sensible default value, then it shouldn’t be constructible with .init())

so the specific overload chosen by

Karl:

doTheThing(.init())

should not be relevant on a first reading of this code.

tera · 2023-04-15T12:22:34.389Z

taylorswift:

self.init(rawValue: String.init(string)) doesn’t add anything meaningful, i am only copying the string because string-backed enums don’t know how to decode themselves from anything other than a String.

It is not immediately obvious without looking at the type itself:

what type is rawValue, is it a string or something else?
how many init(rawValue:) initialisers does this type have and what parameters do those accept? (Note that those initialisers could be in another files.)

self.init(rawValue: String(substring)) makes it crystal clear what particular init we are talking about without looking any further and without any extra knowledge; and BTW, there's normally no need to write String(substring) as String.init(substring).

taylorswift · 2023-04-15T20:29:05.736Z

tera:

It is not immediately obvious without looking at the type itself:

i have to disagree, usually this appears in such close proximity to the enum definition itself that it really should be immediately obvious that in

@frozen public
enum ContentType:String, Equatable, Hashable, Sendable
{
    case html
    case css
    case javascript
}
extension ContentType:LosslessStringConvertible
{
    @inlinable public
    init?(_ description:some StringProtocol)
    {
        self.init(rawValue: .init(description))
    }
}

the rawValue is a String.

jeremyabannister · 2023-04-15T21:22:05.076Z

In some contexts there is actually a piece of information that is currently only communicated to the reader if you use the implicit initializer.

I was going to bring up this point earlier, but then I remembered about SE-0299 and I assumed that it was a moot point. Then I checked with the compiler (see below) and to my surprise, at least for now, it is a relevant point.

/// By looking at this function call
/// I know for sure (for now) that the
/// `downloadSettings:` argument has a concrete type.
downloadVideo(
    metadata: selectedVideo.metadata,
    downloadSettings: .init(continueInBackground: true)
)

/// That piece of information is lost here,
/// which may cause me to wonder if I can
/// define my own settings type to modify the behavior
downloadVideo(
    metadata: selectedVideo.metadata,
    downloadSettings: VideoDownloadSettings(continueInBackground: true)
)

(The snippet that demonstrates that `.init` cannot (yet) be used if the argument is generic.)

protocol MyProtocol { }
struct MyStruct: MyProtocol { }
func takesMyProtocol (_ value: some MyProtocol) { }
extension MyProtocol where Self == MyStruct {
    static func foo () -> Self { MyStruct() }
    init (foo: Void) { self.init() }
}
func demo () {
    takesMyProtocol(.foo()) // ✅ This works
    takesMyProtocol(.init(foo: ())) // ⛔️ This doesn't (yet)
}

taylorswift · 2023-04-15T22:35:19.758Z

jeremyabannister:

but then I remembered about SE-0299 and I assumed that it was a moot point. Then I checked with the compiler (see below) and to my surprise, at least for now, it is a relevant point.

related: Inconsistent SE-0299 behavior if closure parameters are unnamed?

jeremyabannister · 2023-04-17T23:22:43.327Z

@Karl, I've found that I actually think you're right about this in many situations. After considering your perspective and continuing to code I have indeed found places where I felt that readability was improved by replacing .init with the full type name. The leading dot + code completion is still how I start the expression (because it's like an order of magnitude faster and easier), but then I go back and fill in the type name, often. It would be cool for IDEs to make it easy to retroactively replace .init with the type name when desired.

There is still a common (for me) situation though where I find `.init` to be more readable than writing out the type name.

The reason it may only be common for me is because my preferred way of formatting function signatures plays an important role. Consider this function I was just working with:

///
public func createAdvertiser
    (discoveryInfo: [String : String]?,
     serviceType: String)
-> Advertiser {
    .init(
        localPeerID: localPeerID,
        serviceType: serviceType,
        discoveryInfo: discoveryInfo,
        physicalSpace: physicalSpace,
        physicalLocation: physicalLocation
    )
}

I prefer what's above to writing out the type name as seen here:

///
public func createAdvertiser
    (discoveryInfo: [String : String]?,
     serviceType: String)
-> Advertiser {
    Advertiser(
        localPeerID: localPeerID,
        serviceType: serviceType,
        discoveryInfo: discoveryInfo,
        physicalSpace: physicalSpace,
        physicalLocation: physicalLocation
    )
}

The thing is that sometimes I will opt for adding some more visual distinction between the signature and the implementation, in which case given the new opinion you've convinced me of I might go back to spelling out the type name:

///
public func createAdvertiser
    (discoveryInfo: [String : String]?,
     serviceType: String)
-> Advertiser {

    ///
    Advertiser(
        localPeerID: localPeerID,
        serviceType: serviceType,
        discoveryInfo: discoveryInfo,
        physicalSpace: physicalSpace,
        physicalLocation: physicalLocation
    )
}

I'll keep playing with it.

taylorswift · 2023-04-17T23:46:00.536Z

jeremyabannister:

The reason it may only be common for me is because my preferred way of formatting function signatures plays an important role. Consider this function I was just working with:
///
public func createAdvertiser
    (discoveryInfo: [String : String]?,
     serviceType: String)

kind of off-topic, but how did you configure your IDE to do the five-space indent for the function parameters?

jeremyabannister · 2023-04-17T23:49:05.573Z

Hm, I didn’t do it explicitly and I just checked the Xcode settings and I don’t see anything about it. I have of course noticed and appreciated that the second, third, etc. parameters get that fifth space to line up properly with the first parameter.

anon9791410 · 2023-04-18T06:51:01.380Z

This is not an exhaustive list, but every time I see "foo", "bar" (the most prevalent), or "considered", I feel a little physical disgust in my midsection, not dissimilar from when I swallow too big of a capybara. I understand that it comes naturally for some people, but I think it's unnecessary gatekeeping.

jeremyabannister · 2023-04-19T19:10:15.579Z

taylorswift:

how did you configure your IDE to do the five-space indent for the function parameters?

Actually I discovered the answer ...

I have my way of doing it so physically internalized that I forgot that I leverage idiosyncratic aspects of Xcode's default editing behavior to make the parameters line up.

Specifically, the idiosyncrasy to leverage is the following. If you are here:

public func createAdvertiser
    (discoveryInfo: [String : String]?,| (👈 that's the cursor)

then if you hit enter the cursor will line up wrong (i.e., when you start typing it will line up with the parenthesis, not with the first letter of the first parameter):

public func createAdvertiser
    (discoveryInfo: [String : String]?,
    ser

but if you first type a single letter, then hit the left arrow, and then hit enter, you will find that the letter you have typed is lined up with the first letter of parameter above, not with the parenthesis, and you may merrily jump to the end of the line and keep typing:

public func createAdvertiser
    (discoveryInfo: [String : String]?,
     serviceType: String)