RE: passing enum value as an argument

Madestro <me_no_like_spam_juanDOTromero@bowneDOTcom> wrote:
> > You mentioned it in an earlier post, but not in the post which
> > specifically said that a call to TakeFirstEnum(SecondEnum.Fred)
> > succeeds. You didn't even mention it in the post before that. How was
> > anyone supposed to work out that you were talking about the (hopefully
> > unusual) situation of working with Option Strict off in a post made 16
> > hours after your only previous reference to Option Strict?
>
> Understandable. I should not expect you to remember and be more clear on my
> answers.

It's not a case of not remembering, so much as you did nothing to
indicate that you intended any other posts to assume that Option Strict
would be off in any code you referred to.

> > No it wouldn't - because unless you declare a new type for each
> > constant (in which case you've basically got an enum anyway) you would
> > have to use the same type (eg Int32) for different types of constant,
> > at which point you *have* lost type safety.
>
> Actually you would have to declare the SAME type for each constant, and
> indeed you would have an Enum, and you WOULD have to use the same type on the
> function that receives them so you really DON'T loose type safety.

In that case, you just didn't explain yourself clearly in the first
place. I thought you meant getting rid of the enum entirely and *just*
having three variables, eg of type Int32.

If you're just suggesting creating three variables of the same type as
the enum but within the class which wishes to use them, that would
indeed still be type safe - but much less convenient than the compiler
inferring it for you.

> > I think you'll agree that 5 is outside the range of the enum, and yet
> > it works. How do you explain that?
>
> You could not be more right. I actually missread the documentation. The
> limit is in the value size. For example, if you have an Enum defined as
> integer, then you could still use other values so long as they are within the
> range of an integer.
> Totally my fault, I take it back.

Goodo.

> > It can't. So in this case, the compiler would force you to
> > disambiguate. That doesn't mean there aren't many, many cases where
> > there *isn't* any ambiguity, and where the compiler could infer the
> > type.
>
> The compiler may infer the type, but not the value. The value has to be
> resolved by a fully qualified name. The compiler cannot possibly resolve that.

Yes it can - by seeing what type is expected! What is to stop the
compiler from seeing that the expected type for a parameter, or
assignment, or whatever, is the enum, and looking up the expression as
a member of the enum?

It certainly wouldn't be unambiguous all the time, but it doesn't need
to be.

In C# it would present some interesting "purity" discussions in the
same way that people sometimes propose overloading by return type - I
don't know if the same would be true in VB.NET. However, whether it's
"pure" or not doesn't affect whether it's *possible*.

> > Please explain how the code which you claim won't work works perfectly
> > fine then.
>
> I am not sure what code you refer to.

The code you took back, which you said would fail due to the range of
the enum.

> > By the way, your test code also fails to compile because you haven't
> > declared the return type of your Test function, and because the enum
> > you declared was called "Juan" but you declared the parameter to the
> > function to be of type "JuanEnum". Here's your code tidied up. It
> > doesn't fail where you claimed it would, by the way.
>
> I turned Option Strict OFF to test this, which is why the function had no
> return type.
> JuanEnum is just a typo when copying back to here. I don't copy and paste.

Why don't you copy and paste? It makes life much easier for people who
want to try your code, because it means they can try the *actual* code
that you wrote.

> Yes, the code will not fail. This relates to my first answer in this posting.

Indeed.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Problems with enums across a dll interface?
    ... > on compiler settings the size of an enum could change and lead to memory ... the enum size could change. ... You need to be careful when adding enumerators. ...
    (comp.lang.cpp)
  • RE: passing enum value as an argument
    ... > hours after your only previous reference to Option Strict? ... indeed you would have an Enum, and you WOULD have to use the same type on the ... the compiler would force you to ... >> Public sub New ...
    (microsoft.public.dotnet.general)
  • Re: enum?
    ... It being a particular C compiler, it gave an error stating that I would have ... You are right, in all my samples using enum, is shown as you say! ... void doErrorBlink; //Function declaration ... enumeration variable of type ERROR_CODES then it would be usefull, ...
    (microsoft.public.vc.language)
  • Re: Compiler resolves to wrong overloaded constructor or method
    ... > guess would be that the Enum cast doesn't check type, ... As far as I can see, that's the only place the implicit conversion should ... >> compiler implementation, rather than being derivable from the language ... > the spec entirely, so I can't state that the spec doesn't define this. ...
    (microsoft.public.dotnet.languages.csharp)