While I was watching WWDC videos today, I noticed that there's a bit of annoying boilerplate in OptionSet specifications, and set out to get rid of it. Basically, what I'd like to do is this:
static let bar = FooOptions(bit: 0)
static let baz = FooOptions(bit: 1)
}
However, this was thwarted by the fact that the << operator is not in Integer. Or BitwiseOperations. Or any protocol, in fact.
From what I understand, this is a long-known issue we were planning to address in the Integer redesign, but I'm not sure what the status of that is at this point. I would guess that we're facing one of three situations:
1. An Integer redesign is still planned for Swift 3, but hasn't been reviewed yet.
2. An Integer redesign has been deferred, but an incremental improvement (like adding bitshifting to BitwiseOperations) would be welcome.
3. An Integer redesign has been deferred, and an incremental improvement is either not desired or too late at this point.
Can anyone share the status of this? If we're in #2, I'd be happy to put together a quick proposal to patch this particular issue up in time for Swift 3. (I assume that `OptionSet.init(bit:)` would be considered a "new feature" and thus out of scope.)
on Wed Jun 15 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:
While I was watching WWDC videos today, I noticed that there's a bit
of annoying boilerplate in OptionSet specifications, and set out to
get rid of it. Basically, what I'd like to do is this:
static let bar = FooOptions(bit: 0)
static let baz = FooOptions(bit: 1)
}
However, this was thwarted by the fact that the << operator is not in
Integer. Or BitwiseOperations. Or any protocol, in fact.
From what I understand, this is a long-known issue we were planning to
address in the Integer redesign, but I'm not sure what the status of
that is at this point.
While I was watching WWDC videos today, I noticed that there's
a bit of annoying boilerplate in OptionSet specifications, and
set out to get rid of it. Basically, what I'd like to do is this:
On second thoughts, perhaps the current design is better. OptionSet changes the failable initializer (inherited from RawRepresentable) into a *nonfailable* initializer. But if we used `init(_ rawValue: RawValue)` in OptionSet, it would also still have the failable initializer (which could maybe have a default implementation).
The original FooOptions example is missing some required boilerplate: `init(rawValue: Int) { self.rawValue = rawValue }`. In the future, a *macro* could be used to hide the RawRepresentable requirements of option sets, making them as easy to read/write as enum cases.
-- Ben
···
On 18 Jun 2016, at 02:25, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Jun 17 2016, Ben Rimmington <swift-evolution@swift.org> wrote: