This is probably very minor, but I’m not sure the protocol name “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what the guidelines have to say about protocol names:
Protocols that describe what something is should read as nouns (e.g. Collection).
Protocols that describe a capability should be named using the suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
From these two, BitwiseOperations appears to be (attempting) to follow the first rule, yet “BitwiseOperations” doesn’t really describe what the type is, but rather that it can do bitwise operations. The documentation itself even describes the protocol as “a type that supports standard bitwise arithmetic operators."
I propose we rename it to “BitwiseOperable”, or something similar. Again, a small change, but if this were to ever happen, I think Swift 3 is the time.
is implemented, and its uses replaced by FixedWidthInteger.
···
on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:
Hi all,
This is probably very minor, but I’m not sure the protocol name
“BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
the guidelines have to say about protocol names:
Protocols that describe what something is should read as nouns (e.g. Collection).
Protocols that describe a capability should be named using the
suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
From these two, BitwiseOperations appears to be (attempting) to follow
the first rule, yet “BitwiseOperations” doesn’t really describe what
the type is, but rather that it can do bitwise operations. The
documentation itself even describes the protocol as “a type that
supports standard bitwise arithmetic operators."
I propose we rename it to “BitwiseOperable”, or something
similar. Again, a small change, but if this were to ever happen, I
think Swift 3 is the time.
I am still curious why the SE-0104 FixedWidthInteger protocol uses member
functions like “.xor” rather than operators for bitwise manipulation.
Nevin
···
On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:
on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:
> Hi all,
>
> This is probably very minor, but I’m not sure the protocol name
> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
> the guidelines have to say about protocol names:
>
> Protocols that describe what something is should read as nouns (e.g.
Collection).
>
> Protocols that describe a capability should be named using the
> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>
> From these two, BitwiseOperations appears to be (attempting) to follow
> the first rule, yet “BitwiseOperations” doesn’t really describe what
> the type is, but rather that it can do bitwise operations. The
> documentation itself even describes the protocol as “a type that
> supports standard bitwise arithmetic operators."
>
> I propose we rename it to “BitwiseOperable”, or something
> similar. Again, a small change, but if this were to ever happen, I
> think Swift 3 is the time.
FixedWidthInteger only handles the implementation for the numbers, we should also consider OptionSet.
I think we should keep the protocol in case someone wants to implement their own type other than an integer to be used as a raw value type in the OptionSet.
On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:
Hi all,
This is probably very minor, but I’m not sure the protocol name
“BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
the guidelines have to say about protocol names:
Protocols that describe what something is should read as nouns (e.g. Collection).
Protocols that describe a capability should be named using the
suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
From these two, BitwiseOperations appears to be (attempting) to follow
the first rule, yet “BitwiseOperations” doesn’t really describe what
the type is, but rather that it can do bitwise operations. The
documentation itself even describes the protocol as “a type that
supports standard bitwise arithmetic operators."
I propose we rename it to “BitwiseOperable”, or something
similar. Again, a small change, but if this were to ever happen, I
think Swift 3 is the time.
I am still curious why the SE-0104 FixedWidthInteger protocol uses member functions like “.xor” rather than operators for bitwise manipulation.
The global operators are implemented in terms of those methods in the protocol.
-Chris
···
On Jul 3, 2016, at 9:41 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:
Nevin
On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hi all,
>
> This is probably very minor, but I’m not sure the protocol name
> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
> the guidelines have to say about protocol names:
>
> Protocols that describe what something is should read as nouns (e.g. Collection).
>
> Protocols that describe a capability should be named using the
> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>
> From these two, BitwiseOperations appears to be (attempting) to follow
> the first rule, yet “BitwiseOperations” doesn’t really describe what
> the type is, but rather that it can do bitwise operations. The
> documentation itself even describes the protocol as “a type that
> supports standard bitwise arithmetic operators."
>
> I propose we rename it to “BitwiseOperable”, or something
> similar. Again, a small change, but if this were to ever happen, I
> think Swift 3 is the time.
Option sets use set notation, not bitwise notation, no?
Jordan
···
On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution <swift-evolution@swift.org> wrote:
FixedWidthInteger only handles the implementation for the numbers, we should also consider OptionSet.
I think we should keep the protocol in case someone wants to implement their own type other than an integer to be used as a raw value type in the OptionSet.
On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:
Hi all,
This is probably very minor, but I’m not sure the protocol name
“BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
the guidelines have to say about protocol names:
Protocols that describe what something is should read as nouns (e.g. Collection).
Protocols that describe a capability should be named using the
suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
From these two, BitwiseOperations appears to be (attempting) to follow
the first rule, yet “BitwiseOperations” doesn’t really describe what
the type is, but rather that it can do bitwise operations. The
documentation itself even describes the protocol as “a type that
supports standard bitwise arithmetic operators."
I propose we rename it to “BitwiseOperable”, or something
similar. Again, a small change, but if this were to ever happen, I
think Swift 3 is the time.
Wasn't there a proposal to stop defining methods in addition to global operators? I would very much support that, doesn't make sense to me to have two ways to do the same thing IMO.
···
On Jul 3, 2016, at 3:40 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 3, 2016, at 9:41 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:
I am still curious why the SE-0104 FixedWidthInteger protocol uses member functions like “.xor” rather than operators for bitwise manipulation.
The global operators are implemented in terms of those methods in the protocol.
-Chris
Nevin
On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:
> Hi all,
>
> This is probably very minor, but I’m not sure the protocol name
> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
> the guidelines have to say about protocol names:
>
> Protocols that describe what something is should read as nouns (e.g. Collection).
>
> Protocols that describe a capability should be named using the
> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>
> From these two, BitwiseOperations appears to be (attempting) to follow
> the first rule, yet “BitwiseOperations” doesn’t really describe what
> the type is, but rather that it can do bitwise operations. The
> documentation itself even describes the protocol as “a type that
> supports standard bitwise arithmetic operators."
>
> I propose we rename it to “BitwiseOperable”, or something
> similar. Again, a small change, but if this were to ever happen, I
> think Swift 3 is the time.
OptionSets do conform to AlgebraSet but they require raw value type to conform to BitwiseOperations.
Max
···
On Jul 6, 2016, at 3:44 PM, Jordan Rose <jordan_rose@apple.com> wrote:
Option sets use set notation, not bitwise notation, no?
Jordan
On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution <swift-evolution@swift.org> wrote:
FixedWidthInteger only handles the implementation for the numbers, we should also consider OptionSet.
I think we should keep the protocol in case someone wants to implement their own type other than an integer to be used as a raw value type in the OptionSet.
On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:
Hi all,
This is probably very minor, but I’m not sure the protocol name
“BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
the guidelines have to say about protocol names:
Protocols that describe what something is should read as nouns (e.g. Collection).
Protocols that describe a capability should be named using the
suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
From these two, BitwiseOperations appears to be (attempting) to follow
the first rule, yet “BitwiseOperations” doesn’t really describe what
the type is, but rather that it can do bitwise operations. The
documentation itself even describes the protocol as “a type that
supports standard bitwise arithmetic operators."
I propose we rename it to “BitwiseOperable”, or something
similar. Again, a small change, but if this were to ever happen, I
think Swift 3 is the time.
Yes, it will hopefully be coming back for discussion in the next week:
-Chris
···
On Jul 3, 2016, at 1:53 PM, Riley Testut <rileytestut@gmail.com> wrote:
Wasn't there a proposal to stop defining methods in addition to global operators? I would very much support that, doesn't make sense to me to have two ways to do the same thing IMO.
On Jul 3, 2016, at 3:40 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jul 3, 2016, at 9:41 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I am still curious why the SE-0104 FixedWidthInteger protocol uses member functions like “.xor” rather than operators for bitwise manipulation.
The global operators are implemented in terms of those methods in the protocol.
-Chris
Nevin
On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hi all,
>
> This is probably very minor, but I’m not sure the protocol name
> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
> the guidelines have to say about protocol names:
>
> Protocols that describe what something is should read as nouns (e.g. Collection).
>
> Protocols that describe a capability should be named using the
> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>
> From these two, BitwiseOperations appears to be (attempting) to follow
> the first rule, yet “BitwiseOperations” doesn’t really describe what
> the type is, but rather that it can do bitwise operations. The
> documentation itself even describes the protocol as “a type that
> supports standard bitwise arithmetic operators."
>
> I propose we rename it to “BitwiseOperable”, or something
> similar. Again, a small change, but if this were to ever happen, I
> think Swift 3 is the time.
Another use case: I've got a BitArray that makes sense to conform to
BitwiseOperations, but it definitely isn't a FixedWidthInteger.
···
On Wed, Jul 6, 2016 at 17:56 Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote:
OptionSets do conform to AlgebraSet but they require raw value type to
conform to BitwiseOperations.
Max
> On Jul 6, 2016, at 3:44 PM, Jordan Rose <jordan_rose@apple.com> wrote:
>
> Option sets use set notation, not bitwise notation, no?
>
> Jordan
>
>> On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> FixedWidthInteger only handles the implementation for the numbers, we
should also consider OptionSet.
>>
>> I think we should keep the protocol in case someone wants to implement
their own type other than an integer to be used as a raw value type in the
OptionSet.
>>
>> As for renaming it, how about BitwiseOperand?
>>
>> protocol BitwiseOperand {
>> func bitwiseOr(_ rhs: Self) -> Self
>> func bitwiseAnd(_ rhs: Self) -> Self
>> // etc ...
>> }
>>
>> Max
>>
>>> On Jul 1, 2016, at 5:19 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>>
>>> on Fri Jul 01 2016, Riley Testut <swift-evolution@swift.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> This is probably very minor, but I’m not sure the protocol name
>>>> “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
>>>> the guidelines have to say about protocol names:
>>>>
>>>> Protocols that describe what something is should read as nouns (e.g.
Collection).
>>>>
>>>> Protocols that describe a capability should be named using the
>>>> suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>>>>
>>>> From these two, BitwiseOperations appears to be (attempting) to follow
>>>> the first rule, yet “BitwiseOperations” doesn’t really describe what
>>>> the type is, but rather that it can do bitwise operations. The
>>>> documentation itself even describes the protocol as “a type that
>>>> supports standard bitwise arithmetic operators."
>>>>
>>>> I propose we rename it to “BitwiseOperable”, or something
>>>> similar. Again, a small change, but if this were to ever happen, I
>>>> think Swift 3 is the time.
>>>
>>> BitwiseOperations should really be retired after
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>> is implemented, and its uses replaced by FixedWidthInteger.
>>>
>>> --
>>> Dave
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>