Re: Trouble with imported enums in Swift
On Oct 20, 2014, at 10:53 PM, Rick Mann rm...@latencyzero.com wrote: Sigh, I figured it out. Not only do you have to use NS_ENUM, the enumeration members MUST begin with the name of the enumeration. Example please ... I feel unfulfilled. -rags ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 09:18 , Raglan T. Tiger r...@crusaderrabbit.net wrote:
On Oct 20, 2014, at 10:53 PM, Rick Mann rm...@latencyzero.com wrote:
Sigh, I figured it out. Not only do you have to use NS_ENUM, the enumeration
members MUST begin with the name of the enumeration.
Example please ... I feel unfulfilled.
It's precisely as shown here (if not spelled out in words), under
Enumerations:
https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/InteractingWithCAPIs.html
typedef NS_ENUM(NSInteger, UITableViewCellStyle)
{
UITableViewCellStyleDefault,
UITableViewCellStyleValue1,
UITableViewCellStyleValue2,
UITableViewCellStyleSubtitle
};
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 11:38 AM, Rick Mann rm...@latencyzero.com wrote:
On Oct 21, 2014, at 09:18 , Raglan T. Tiger r...@crusaderrabbit.net wrote:
On Oct 20, 2014, at 10:53 PM, Rick Mann rm...@latencyzero.com wrote:
Sigh, I figured it out. Not only do you have to use NS_ENUM, the
enumeration members MUST begin with the name of the enumeration.
Example please ... I feel unfulfilled.
It's precisely as shown here (if not spelled out in words), under
Enumerations:
https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/InteractingWithCAPIs.html
typedef NS_ENUM(NSInteger, UITableViewCellStyle)
{
UITableViewCellStyleDefault,
UITableViewCellStyleValue1,
UITableViewCellStyleValue2,
UITableViewCellStyleSubtitle
};
NS_ENUM or NS_OPTIONS is required for Swift to import it.
The name prefix is not required. If I recall correctly, the Swift importer has
some heuristics to omit any shared prefix from the Swift names, but if there is
no prefix then the enumerators are imported unchanged.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 13:13 , Greg Parker gpar...@apple.com wrote: NS_ENUM or NS_OPTIONS is required for Swift to import it. The name prefix is not required. If I recall correctly, the Swift importer has some heuristics to omit any shared prefix from the Swift names, but if there is no prefix then the enumerators are imported unchanged. I guess I'm going to have to make a demo project to show that this isn't precisely true. If I make a plain enum in C, Swift recognizes it for the purposes of creating a type, and for assignment. It will not, however, allow comparisons with those values. If I use NS_ENUM without also prefixing each member with the enum's type name, Swift will not allow comparisons. Only if I use NS_ENUM and prefix each member with the type name will Swift fully support the enum. Honestly, though, I don't see why Swift can't just deal with plain enums. -- Rick Mann rm...@latencyzero.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 13:33 , Rick Mann rm...@latencyzero.com wrote:
Honestly, though, I don't see why Swift can't just deal with plain enums.
Because it’s not an Obj-C compiler?
I suspect that the reason you saw the “incomplete” behavior is that you
declared the enum in two parts:
enum McpSweepState
{
MCP_SWEEP_UNKNOWN = 0,
MCP_SWEEP_EMPTY= 1,
MCP_SWEEP_ROTATING = 2,
MCP_SWEEP_PROCESSING = 3,
MCP_SWEEP_COMPLETE = 4,
MCP_SWEEP_CANCELED = 5,
MCP_SWEEP_ABORTED_PHYSICAL = 6,
MCP_SWEEP_ABORTED_DATA = 7,
MCP_SWEEP_ERROR= 8,
};
typedef enum McpSweepState McpSweepState;
Under this theory, Swift is able to parse the typedef, so it knows that
‘McpSweepState’ is a type, and maybeeven an enum, but it doesn’t know what the
values are. That might be enough to let it assign, but not to compare (since ==
is not a built-in operator).
Or, it might be that it can parse the enum, but it doesn’t know its underlying
type, since you didn’t say ‘enum McpSweepState : NSUInteger’ or some such.
Honestly, though, I don’t see why you can’t just deal with writing enums the
“compatible” way.
;)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 14:26 , Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Oct 21, 2014, at 13:33 , Rick Mann rm...@latencyzero.com wrote:
Honestly, though, I don't see why Swift can't just deal with plain enums.
Because it’s not an Obj-C compiler?
I suspect that the reason you saw the “incomplete” behavior is that you
declared the enum in two parts:
enum McpSweepState
{
MCP_SWEEP_UNKNOWN = 0,
MCP_SWEEP_EMPTY= 1,
MCP_SWEEP_ROTATING = 2,
MCP_SWEEP_PROCESSING = 3,
MCP_SWEEP_COMPLETE = 4,
MCP_SWEEP_CANCELED = 5,
MCP_SWEEP_ABORTED_PHYSICAL = 6,
MCP_SWEEP_ABORTED_DATA = 7,
MCP_SWEEP_ERROR= 8,
};
typedef enum McpSweepState McpSweepState;
Under this theory, Swift is able to parse the typedef, so it knows that
‘McpSweepState’ is a type, and maybeeven an enum, but it doesn’t know what
the values are. That might be enough to let it assign, but not to compare
(since == is not a built-in operator).
Or, it might be that it can parse the enum, but it doesn’t know its
underlying type, since you didn’t say ‘enum McpSweepState : NSUInteger’ or
some such.
Honestly, though, I don’t see why you can’t just deal with writing enums the
“compatible” way.
Because the file whence it comes is part of a library of C++ code that also has
to run on Linux.
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 14:35 , Rick Mann rm...@latencyzero.com wrote: On Oct 21, 2014, at 14:26 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: Honestly, though, I don’t see why you can’t just deal with writing enums the “compatible” way. Because the file whence it comes is part of a library of C++ code that also has to run on Linux. Swift isn’t a C++ cross-compiler either. You know that the NS_ENUM thing is a macro, don’t you? (Or, at least, can be — it seems to be a syntax feature in the latest clang.) Five seconds searching the web gave me this: #ifndef NS_ENUM #define NS_ENUM(_type, _name) enum _name : _type _name; enum _name : _type #endif of which I assume a slight variant will eliminate the clang-specific syntax and therefore work fine in C++ and on Linux. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 14:54 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Oct 21, 2014, at 14:35 , Rick Mann rm...@latencyzero.com wrote: On Oct 21, 2014, at 14:26 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: Honestly, though, I don’t see why you can’t just deal with writing enums the “compatible” way. Because the file whence it comes is part of a library of C++ code that also has to run on Linux. Swift isn’t a C++ cross-compiler either. You know that the NS_ENUM thing is a macro, don’t you? (Or, at least, can be — it seems to be a syntax feature in the latest clang.) Five seconds searching the web gave me this: #ifndef NS_ENUM #define NS_ENUM(_type, _name) enum _name : _type _name; enum _name : _type #endif of which I assume a slight variant will eliminate the clang-specific syntax and therefore work fine in C++ and on Linux. I think you're missing the point. The header (which can be included in a C file) is used throughout a body of code that knows nothing about NS. Sure we can make a macro to mimic the behavior, but only because the code is all generated in-house (it's not some open source code base we use). But the names of the elements all have to start with the type name, and that means not only changing the entire code base that uses the header, but also changing the naming convention used by that code base. Sure, we can do it, but it'll irritate a number of engineers, at best. All because Swift bridging wasn't designed to be more accommodating. The reason this header is shared in the first place is that the values are used in a protocol between nodes. -- Rick Mann rm...@latencyzero.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 16:25 , Rick Mann rm...@latencyzero.com wrote: But the names of the elements all have to start with the type name, and that means not only changing the entire code base that uses the header, but also changing the naming convention used by that code base. Sure, we can do it, but it'll irritate a number of engineers, at best. It’s a time-honored (ahem!) tradition in C and C++ to use macros to smooth over the differences when writing code that crosses platform and architecture boundaries. It’s a time-honored (ugh!) tradition that such code tends to refuse to acknowledge that Mac platforms exist. Why is the Mac automatically the poor cousin? Since, you say, this code base is in-house, you have the opportunity to treat the Mac requirements equally, which means those other platforms might have to suck up their compatibility macros, and like it. Or, if you don’t have that kind of influence over the code base, you, Rick, are going to have to re-write your enums in Swift, and like it. All because Swift bridging wasn't designed to be more accommodating. Swift doesn’t seem to be designed to be accommodating towards C or C++. It seems to be designed to be accommodating towards code already written for Cocoa frameworks. That means it understands Obj-C syntax, which means it understands C syntax automatically (though not non-C C++ syntax), but it doesn’t “translate” Obj-C programs, only Obj-C *headers*, and only the parts it want to translate**. Again, it’s not the cross-compiler you want it to be. If you don’t like that, you get to file a Radar like everyone else. The reason this header is shared in the first place is that the values are used in a protocol between nodes. It’s not really sharing if the Mac version isn’t allowed to impose any requirements on your code base. See above, under “poor cousin”. ** It only translates a small subset of macros, too. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 4:25 PM, Rick Mann rm...@latencyzero.com wrote:
But the names of the elements all have to start with the type name
This should not be the case. Please provide an example of the ObjC and Swift
code you're using.
Here's mine:
// ObjC header: no type name prefix on enumerators
typedef NS_ENUM(NSInteger, Foo) {
Aalpha, Bbeta, Oomega
};
// Swift code: compiles successfully
var f = Foo.Aalpha
if f == Foo.Bbeta { println(same) }
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
I've created a sample project showing the behavior and submitted it with radar
#18730653.
On Oct 21, 2014, at 17:09 , Greg Parker gpar...@apple.com wrote:
On Oct 21, 2014, at 4:25 PM, Rick Mann rm...@latencyzero.com wrote:
But the names of the elements all have to start with the type name
This should not be the case. Please provide an example of the ObjC and Swift
code you're using.
Here's mine:
// ObjC header: no type name prefix on enumerators
typedef NS_ENUM(NSInteger, Foo) {
Aalpha, Bbeta, Oomega
};
// Swift code: compiles successfully
var f = Foo.Aalpha
if f == Foo.Bbeta { println(same) }
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/rmann%40latencyzero.com
This email sent to rm...@latencyzero.com
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 5:45 PM, Rick Mann rm...@latencyzero.com wrote:
I've created a sample project showing the behavior and submitted it with
radar #18730653.
Thanks for the bug report. There is a Swift importer bug here. Your enumerators
all have a common name prefix, but that name prefix differs from the type name.
I think the importer tries to remove that prefix from the Swift names but gets
it wrong.
typedef NS_ENUM(int, McpResponseStatus) {
MCP_RESPONSE_SUCCESS = 0,
MCP_RESPONSE_BAD_TOKEN = 1
};
// Swift names should be McpResponseStatus.SUCCESS etc.
// Swift is instead mistakenly importing these as
McpResponseStatus.CP_RESPONSE_SUCCESS etc. (with only 'M' removed).
Workaround: add an enumerator that doesn't have the same name prefix. Then the
importer will not try to strip any common prefix and you can use the long names
in Swift.
typedef NS_ENUM(int, McpResponseStatus) {
MCP_RESPONSE_SUCCESS = 0,
MCP_RESPONSE_BAD_TOKEN = 1,
SwiftHackForMcpResponseStatus
};
// Swift names are McpResponseStatus.MCP_RESPONSE_SUCCESS etc.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 21, 2014, at 18:13 , Greg Parker gpar...@apple.com wrote:
On Oct 21, 2014, at 5:45 PM, Rick Mann rm...@latencyzero.com wrote:
I've created a sample project showing the behavior and submitted it with
radar #18730653.
Thanks for the bug report. There is a Swift importer bug here. Your
enumerators all have a common name prefix, but that name prefix differs from
the type name. I think the importer tries to remove that prefix from the
Swift names but gets it wrong.
typedef NS_ENUM(int, McpResponseStatus) {
MCP_RESPONSE_SUCCESS = 0,
MCP_RESPONSE_BAD_TOKEN = 1
};
// Swift names should be McpResponseStatus.SUCCESS etc.
// Swift is instead mistakenly importing these as
McpResponseStatus.CP_RESPONSE_SUCCESS etc. (with only 'M' removed).
Workaround: add an enumerator that doesn't have the same name prefix. Then
the importer will not try to strip any common prefix and you can use the long
names in Swift.
typedef NS_ENUM(int, McpResponseStatus) {
MCP_RESPONSE_SUCCESS = 0,
MCP_RESPONSE_BAD_TOKEN = 1,
SwiftHackForMcpResponseStatus
};
// Swift names are McpResponseStatus.MCP_RESPONSE_SUCCESS etc.
Thanks. In the end I made Swift equivalents.
Would it not be possible to just import any enum? That will help Swift adoption.
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Trouble with imported enums in Swift
I'm having weird trouble using a C enumeration imported via bridging header
from swift. I can define an instance variable and initialize it using the enum,
but I can't compare the enum:
Camera.swift:60:18: Cannot invoke '==' with an argument list of type '(@lvalue
McpSweepState, McpSweepState)'
The code is here:
class
MyClass
{
func
getCameraState()
- McpCameraState
{
if mSweepState == MCP_SWEEP_UNKNOWN // error here
{
return MCP_STATE_SWEEP_IN_PROGRESS;
}
else
{
return MCP_STATE_READY;
}
}
var mSweepState: McpSweepState= MCP_SWEEP_UNKNOWN; // --- no error
}
Imported via bridging header:
enum McpSweepState
{
MCP_SWEEP_UNKNOWN = 0,
MCP_SWEEP_EMPTY= 1,
MCP_SWEEP_ROTATING = 2,
MCP_SWEEP_PROCESSING = 3,
MCP_SWEEP_COMPLETE = 4,
MCP_SWEEP_CANCELED = 5,
MCP_SWEEP_ABORTED_PHYSICAL = 6,
MCP_SWEEP_ABORTED_DATA = 7,
MCP_SWEEP_ERROR= 8,
};
typedef enum McpSweepState McpSweepState;
enum McpCameraState
{
MCP_STATE_UNKNOWN = 0,
MCP_STATE_READY = 1,
MCP_STATE_SWEEP_IN_PROGRESS = 2,
MCP_STATE_BLOCKED = 3,
};
typedef enum McpCameraState McpCameraState;
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On 21 Oct 2014, at 10:03 am, Rick Mann rm...@latencyzero.com wrote:
I'm having weird trouble using a C enumeration imported via bridging header
from swift. I can define an instance variable and initialize it using the
enum, but I can't compare the enum:
Camera.swift:60:18: Cannot invoke '==' with an argument list of type
'(@lvalue McpSweepState, McpSweepState)'
The code is here:
class
MyClass
{
func
getCameraState()
- McpCameraState
{
if mSweepState == MCP_SWEEP_UNKNOWN// error here
{
return MCP_STATE_SWEEP_IN_PROGRESS;
}
else
{
return MCP_STATE_READY;
}
}
var mSweepState: McpSweepState= MCP_SWEEP_UNKNOWN; // --- no error
}
—
well one is ‘==‘ and the other is ‘=‘ so not totally shocked there’s no error
in the second one.
Have you tried
1) a switch
2) using .MCP_SWEEP_UNKNOWN or an even more totally qualified name
McpSweepState.MCP_SWEEP_UNKNOWN
3) if !( mSweepState != MCP_SWEEP_UNKNOWN ) // I know you think I’m joking but
I’m not
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On Oct 20, 2014, at 19:17 , Roland King r...@rols.org wrote: well one is ‘==‘ and the other is ‘=‘ so not totally shocked there’s no error in the second one. Well, okay, but == sure is getting confused, but = sees the two types as compatible. Have you tried 1) a switch Type 'McpSweepState' does not conform to protocol 'IntervalType' (I've never been able to get switch to work) 2) using .MCP_SWEEP_UNKNOWN or an even more totally qualified name McpSweepState.MCP_SWEEP_UNKNOWN Could not find member 'MCP_SWEEP_UNKNOWN' 3) if !( mSweepState != MCP_SWEEP_UNKNOWN ) // I know you think I’m joking but I’m not Could not find an overload for '!' that accepts the supplied arguments -- Rick Mann rm...@latencyzero.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
On 21 Oct 2014, at 10:23 am, Rick Mann rm...@latencyzero.com wrote:
On Oct 20, 2014, at 19:17 , Roland King r...@rols.org wrote:
well one is ‘==‘ and the other is ‘=‘ so not totally shocked there’s no
error in the second one.
Well, okay, but == sure is getting confused, but = sees the two types as
compatible
well it would, = takes an lvalue of a type and a type, which is what the error
message says you have. You’d have thunk == would be smart enough to do the same
but clearly it’s not or else they aren’t really the same type, but two
different types with the same name or they aren’t enums which have ==
automagically defined on them (as long as they don’t have associated types).
Have you tried
1) a switch
Type 'McpSweepState' does not conform to protocol 'IntervalType'
(I've never been able to get switch to work)
2) using .MCP_SWEEP_UNKNOWN or an even more totally qualified name
McpSweepState.MCP_SWEEP_UNKNOWN
Could not find member 'MCP_SWEEP_UNKNOWN'
3) if !( mSweepState != MCP_SWEEP_UNKNOWN ) // I know you think I’m joking
but I’m not
Could not find an overload for '!' that accepts the supplied arguments
oh dear you do have some major borkage there. I have no idea what’s going on.
Kind of looks like the enum didn’t bridge over as an enum but some other type
which doesn’t conform to ‘==‘. Perhaps the typedef of the name 'enum XXX' to
‘XXX' upsets it.
Only other thought I have is to change the original version to
typedef NS_ENUM( NSInteger, McpSweepState )
{
// your enum values here
}
but I’m not entirely sure I hold out much hope for that either.
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble with imported enums in Swift
Sigh, I figured it out. Not only do you have to use NS_ENUM, the enumeration
members MUST begin with the name of the enumeration.
On Oct 20, 2014, at 19:43 , Roland King r...@rols.org wrote:
On 21 Oct 2014, at 10:23 am, Rick Mann rm...@latencyzero.com wrote:
On Oct 20, 2014, at 19:17 , Roland King r...@rols.org wrote:
well one is ‘==‘ and the other is ‘=‘ so not totally shocked there’s no
error in the second one.
Well, okay, but == sure is getting confused, but = sees the two types as
compatible
well it would, = takes an lvalue of a type and a type, which is what the
error message says you have. You’d have thunk == would be smart enough to do
the same but clearly it’s not or else they aren’t really the same type, but
two different types with the same name or they aren’t enums which have ==
automagically defined on them (as long as they don’t have associated types).
Have you tried
1) a switch
Type 'McpSweepState' does not conform to protocol 'IntervalType'
(I've never been able to get switch to work)
2) using .MCP_SWEEP_UNKNOWN or an even more totally qualified name
McpSweepState.MCP_SWEEP_UNKNOWN
Could not find member 'MCP_SWEEP_UNKNOWN'
3) if !( mSweepState != MCP_SWEEP_UNKNOWN ) // I know you think I’m joking
but I’m not
Could not find an overload for '!' that accepts the supplied arguments
oh dear you do have some major borkage there. I have no idea what’s going on.
Kind of looks like the enum didn’t bridge over as an enum but some other type
which doesn’t conform to ‘==‘. Perhaps the typedef of the name 'enum XXX' to
‘XXX' upsets it.
Only other thought I have is to change the original version to
typedef NS_ENUM( NSInteger, McpSweepState )
{
// your enum values here
}
but I’m not entirely sure I hold out much hope for that either.
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/rmann%40latencyzero.com
This email sent to rm...@latencyzero.com
--
Rick Mann
rm...@latencyzero.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
