News for hackers. Stuff that matters.
Re:The Curious Case of Swift's Adoption of Smalltalk Keyword... by saagarjha on Sunday June 14, 2020 @01:07PM (#23519362)
> Here you can do something even better: give these two options different types, this way not only it makes the code more explicit, it also means that it gets enforced by the compiler

Bool is also enforced by the compiler; adding ad-hoc types for things that have only two values is generally not something you should do without good reason. By the way, constructs like these are fairly common in Swift:

  enum SearchType {
      case literal
      case regex
      case extendedRegex
  }

  extension String {
      func substring(matching needle: String, interpretedAs type: SearchType = .literal) -> Substring
  }
which you'd use as something like

  "foobar".substring(matching: "o*ba", interpretedAs: .regex) // "ooba"
Re:The Curious Case of Swift's Adoption of Smalltalk Keyword... by barrkel on Sunday June 14, 2020 @02:45PM (#23520149)
In the absence of keyword arguments as a language feature, boolean arguments should almost always be avoided, and replaced by enums where possible. Boolean arguments are almost always inscrutable at the call site.
Re:The Curious Case of Swift's Adoption of Smalltalk Keyword... by skohan on Sunday June 14, 2020 @02:59PM (#23520300)
Then it would be very convenient to have keyword arguments, as in the case presented by the previous poster