As I was coding with enumerations right now, I suddenly thought if a method with a return type of an enumeration doesn’t return anything (has a path with no return statement), what would one get? The first entered value, the first reordered value, nil? If Nil, it’d be hard to check an enumeration against nil (the same issue existed, years ago, for several months with arrays, where the compiler would refuse to compare an array against nil, should none be returned from methods).
So I looked at the language reference and could find nothing about that. Obviously, I tried with a sample project, but I think mentioning this in the LR would be good.
you get back whatever enumerated value is = 0
since the underlying data type is an integer the default value for an integer is 0 so the default for an enum is 0
you can try it as well
create a new project
add an enum to a window and set the values as follows
enum untitledEnum
first = 1
second = 2
default = 0
end enum
then add a method to the window
function foo() as untitledEnum
end function
then in the window open event do
dim v as untitledEnum = untitledEnum.first
break // check the value in the debugger
v = foo
break // check the value in the debugger
[quote=497433:@Norman Palardy]you get back whatever enumerated value is = 0
since the underlying data type is an integer the default value for an integer is 0 so the default for an enum is 0[/quote]
This make sense, but
Yes, I made the test to have a definitive answer. Indeed, 0 is returned and it makes sense. Except:
When someone is confused because an enum can’t directly equal an integer, without typecasting, the answers in this forum is in the form of An enum defines its own type (your answer is here, for example: https://forum.xojo.com/38663-integer-enums/0#p315327). This is misleading, as one may think an enum might then be some class (it also has a dot notation, etc.), thus be nil when not returned. I know what the current behaviour is, but the other way of thinking could be valid.
(this is actually a bug) if your enumerations don’t have a field being 0:
MyEnum:
First=1
Second=2
Third=3
And your method has a return type of MyEnum but no return, it still returns 0 (shown in red in the debugger) and it breaks the purpose of enumerations being limited to its members’ values.
[quote=497465:@Arnaud Nicolet]This make sense, but
Yes, I made the test to have a definitive answer. Indeed, 0 is returned and it makes sense. Except:
When someone is confused because an enum can’t directly equal an integer, without typecasting, the answers in this forum is in the form of An enum defines its own type (your answer is here, for example: https://forum.xojo.com/38663-integer-enums/0#p315327). This is misleading, as one may think an enum might then be some class (it also has a dot notation, etc.), thus be nil when not returned. I know what the current behaviour is, but the other way of thinking could be valid.
[/quote]
An enum IS a new type
It can be converted to an equivalent integer or an integer cast to be one - even one out of range (see below)
And since enums are also an intrinsic type they have a default value just like strings default to “” and integers default to 0 and double default to 0 and colors default to &c00000000
Since they are effectively 32 bit values their “default” is 0 just like other numeric values
So they get initialized to that and you get what you get
They are NOT reference types - otherwise you could get a NIL
[quote=497465:@Arnaud Nicolet]
(this is actually a bug) if your enumerations don’t have a field being 0:
MyEnum:
First=1
Second=2
Third=3
And your method has a return type of MyEnum but no return, it still returns 0 (shown in red in the debugger) and it breaks the purpose of enumerations being limited to its members’ values.[/quote]
Enums have NEVER been limited to their members
Doing so might be nice but then you would have to have a means in the compiler to make sure that ever new instance was set to whatever default value (instead of just clearing the memory - which effectively sets it to 0
I think this has been repoted more than once as a bug and its always been closed as NOT a bug
Since this behaviour goes back to the beginning of the product I doubt it will ever be changed
Feel free to submit a bug report though
Why would I submit a bug report after you’ve explained to me it’s not a bug?
I was just seeing enumerations from another point of view and you explained to me what’s the intended behaviour; I never wanted for it to change nor upsetting you, I’m sorry.
[quote=497479:@Arnaud Nicolet] I never wanted for it to change nor upsetting you, I’m sorry.
[/quote]
not sure why you think I’m upset ???
I’m not
Enums dont have great documentation about many things and this topic has come up more than once over the years
[quote=497480:@Norman Palardy]not sure why you think I’m upset???
I’m not[/quote]
Fine, then. I think I misinterpreted what you wrote:
[quote]I think this has been repoted more than once as a bug and its always been closed as NOT a bug
Since this behaviour goes back to the beginning of the product I doubt it will ever be changed
Feel free to submit a bug report though[/quote]
The last line made me read it as If you don’t trust me, you still may submit a bug report [but it’ll be closed anyway], along with the guess I would want the behaviour to be changed (I was just seeking for the correct point of view).
Probably, but since searching this forum is broken, I haven’t found much about it (and it’s a pain to search, so I just reviewed the 1st page of results )
Perhaps. I’ll report the lack of mentioning an enum isn’t a reference type (but rely on its base type (integer)) or something along those lines.
Thank you.