Feature request:....

[Mr.Tickle]

When setting the [Flags] attribute on an enum, why should I have to specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

 

[Stoyan Damov]

To me, the automatic compiler support is asking for errors. If you reorder
your enum, you break their values, e.g. an enum saved to a file (before the
reordering), won't be read properly (after the reordering). If you are too
lazy to set bit masks, you can always define enums in this way:

[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}

Cheers,
Stoyan

 

[Mr.Tickle]

Well, we have already automatic support for enums, its overridable, so why
not have it consistant to that of non Flag enums?

If we are lazy? Enums currently (for non bitmasks) are already defined.
Youre lazy argument falls flat on its face.

To me, the automatic compiler support is asking for errors. If you reorder
your enum, you break their values, e.g. an enum saved to a file (before the
reordering), won't be read properly (after the reordering). If you are too
lazy to set bit masks, you can always define enums in this way:

[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}

Cheers,
Stoyan

When setting the [Flags] attribute on an enum, why should I have to specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

 

[Stoyan Damov]

I couldn't understand anything. Sorry if I have offended you in any way.

Cheers,
Stoyan

Well, we have already automatic support for enums, its overridable, so why
not have it consistant to that of non Flag enums?

If we are lazy? Enums currently (for non bitmasks) are already defined.
Youre lazy argument falls flat on its face.

To me, the automatic compiler support is asking for errors. If you reorder
your enum, you break their values, e.g. an enum saved to a file (before the
reordering), won't be read properly (after the reordering). If you are too
lazy to set bit masks, you can always define enums in this way:

[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}

Cheers,
Stoyan

When setting the [Flags] attribute on an enum, why should I have to specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

 

[Mr.Tickle]

Simple. Enums are currently automatic, except they are AUTOMATIC INCORRECTLY
when FLAGS attribute is set.

Its INCORRECT behaviour for the Flags attribute. Since when is a bitfield
automaticly set to 1, 2, 3, 4, 5`?? Thats what it does.

What I am asking is if we can have it automatically set to 1, 2, 4, 8, 16...
CORRECTLY.

I couldn't understand anything. Sorry if I have offended you in any way.

Cheers,
Stoyan

Well, we have already automatic support for enums, its overridable, so why
not have it consistant to that of non Flag enums?

If we are lazy? Enums currently (for non bitmasks) are already defined.
Youre lazy argument falls flat on its face.

To me, the automatic compiler support is asking for errors. If you reorder
your enum, you break their values, e.g. an enum saved to a file

(before
the

reordering), won't be read properly (after the reordering). If you are too
lazy to set bit masks, you can always define enums in this way:

[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}

Cheers,
Stoyan

When setting the [Flags] attribute on an enum, why should I have to
specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the

compiler
can

do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

 

[Eric Gunnerson [MS]]

It's fairly common for people to define values that are combinations of the
others:

enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,

}

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mr.Tickle]

So if we just say

[Flags]
enum Test
{
First,
Second,
Third,
Fourth
}

Guess what the compiler generates?

First = 0, Second = 1 , Third = 2, Fourth = 3

So thats correct behaviour for a Flag? Dont make me laugh.

It's fairly common for people to define values that are combinations of the
others:

enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,

}

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

When setting the [Flags] attribute on an enum, why should I have to specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

 

[ozbear]

So if we just say

[Flags]
enum Test
{
First,
Second,
Third,
Fourth
}

Guess what the compiler generates?

First = 0, Second = 1 , Third = 2, Fourth = 3

So thats correct behaviour for a Flag? Dont make me laugh.

It's fairly common for people to define values that are combinations of the
others:

enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,

}

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

When setting the [Flags] attribute on an enum, why should I have to specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

Idiot

 

[ozbear]

Simple. Enums are currently automatic, except they are AUTOMATIC INCORRECTLY
when FLAGS attribute is set.

Its INCORRECT behaviour for the Flags attribute. Since when is a bitfield
automaticly set to 1, 2, 3, 4, 5`?? Thats what it does.

What I am asking is if we can have it automatically set to 1, 2, 4, 8, 16...
CORRECTLY.

I couldn't understand anything. Sorry if I have offended you in any way.

Cheers,
Stoyan

Well, we have already automatic support for enums, its overridable, so why
not have it consistant to that of non Flag enums?

If we are lazy? Enums currently (for non bitmasks) are already defined.
Youre lazy argument falls flat on its face.



To me, the automatic compiler support is asking for errors. If you reorder
your enum, you break their values, e.g. an enum saved to a file (before
the
reordering), won't be read properly (after the reordering). If you are too
lazy to set bit masks, you can always define enums in this way:

[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}

Cheers,
Stoyan

When setting the [Flags] attribute on an enum, why should I have to
specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler
can
do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

Idiot

 

[ozbear]

It's fairly common for people to define values that are combinations of the
others:

enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,

}

The documentation does seem to be incorrect. I am using the 1.1
framework, if that matters, and given the declaration:

enum answer {yes, no maybe};

i can declare a variable of type -answer- and use the C# OR
operator...

answer test = answer.yes | answer.no;

According to the doco, I need the [Flags] attribute applied to my
-answer- enumeration, yet the C# compiler accepts the above test =
assignment without complaint. In other words...the presence or
absence of [Flags] makes no difference to the /assignment/.

I accept that it will affect other things like ToString(), etc.

Oz

 

[Mr.Tickle]

yankstain

Simple. Enums are currently automatic, except they are AUTOMATIC INCORRECTLY
when FLAGS attribute is set.

Its INCORRECT behaviour for the Flags attribute. Since when is a bitfield
automaticly set to 1, 2, 3, 4, 5`?? Thats what it does.

What I am asking is if we can have it automatically set to 1, 2, 4, 8, 16...
CORRECTLY.

I couldn't understand anything. Sorry if I have offended you in any way.

Cheers,
Stoyan

Well, we have already automatic support for enums, its overridable,

so
why

not have it consistant to that of non Flag enums?

If we are lazy? Enums currently (for non bitmasks) are already defined.
Youre lazy argument falls flat on its face.



To me, the automatic compiler support is asking for errors. If you
reorder
your enum, you break their values, e.g. an enum saved to a file (before
the
reordering), won't be read properly (after the reordering). If you are
too
lazy to set bit masks, you can always define enums in this way:

[Flags]
public enum Whatever
{
None = 0,
Flag1 = 1,
Flag2 = Flag1 << 1,
Flag3 = Flag2 << 1,
// etc.
CheckMask = Flag1 | ... | FlagN
}

Cheers,
Stoyan

When setting the [Flags] attribute on an enum, why should I have to
specify
powers of 2 when the compiler should see this is a bitfield and set
the
range accordingly, why should I have to do the work that the compiler
can
do?


To me this is just asking for errors to be introduced by offloading
this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to
allow
ranges like All = Enum1Val | Enum2Val; etc.

Idiot

 

[Jon Skeet [C# MVP]]

The documentation does seem to be incorrect. I am using the 1.1
framework, if that matters, and given the declaration:

enum answer {yes, no maybe};

i can declare a variable of type -answer- and use the C# OR
operator...

answer test = answer.yes | answer.no;

According to the doco, I need the [Flags] attribute applied to my
-answer- enumeration, yet the C# compiler accepts the above test =
assignment without complaint. In other words...the presence or
absence of [Flags] makes no difference to the /assignment/.

I accept that it will affect other things like ToString(), etc.

It should work as per the above according to sectino 14.10.2 of the
ECMA spec.

The documentation you were talking about is the FlagsAttribute remarks,
presumably? If so, it's quite an interesting case - it's up to a
language to decide what it allows, so I don't think the FlagAttribute
documentation should really be talking about that at all. What it
could/should be talking about is that when [Flags] is applied, bitwise
operations are *expected* to give useful results (whereas they may not
otherwise). A language *could* decide to only allow bitwise operations
on enumerations which are marked with the [Flags] attribute, of course.

 

[Mr.Tickle]

The compiler generates 0, 1, 2, 3, 4, 5, 6 which is NOT bitfield values in
powers of 2, even the flags attributem, thats the issue, its INCORRECT
values by default, sure people set them but its INCORRECT otherwise, so go
ahead and act the egotistical yankstain and ship incorrect products.

I just laugh at thee errors. Im on the other side of the wall dont forget
and will abuse those errors.

It's fairly common for people to define values that are combinations of the
others:

enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,

}

The documentation does seem to be incorrect. I am using the 1.1
framework, if that matters, and given the declaration:

enum answer {yes, no maybe};

i can declare a variable of type -answer- and use the C# OR
operator...

answer test = answer.yes | answer.no;

According to the doco, I need the [Flags] attribute applied to my
-answer- enumeration, yet the C# compiler accepts the above test =
assignment without complaint. In other words...the presence or
absence of [Flags] makes no difference to the /assignment/.

I accept that it will affect other things like ToString(), etc.

Oz

 

[Mr.Tickle]

[Flags]
enum bitfield
{
one,
two,
three,
four,
five,
six,
all = one | two | three | four | five | six
}

man thats gonna throw up some interesting results, thanks to Eric
Gunnarson's ignorance.


Three cheers for da man that supports bad code like the above. Bitfields
should be set to the base of the machine, ie powers of 2, you dumbschmuck.

Flags in reality does jack all, except permit logical operators on enums, so
lets look the other way when it comes to the above and yet claim from the
rooftops that C# is da biz for safe coding, well it aint in the above case.

It's fairly common for people to define values that are combinations of the
others:

enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,

}

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

When setting the [Flags] attribute on an enum, why should I have to specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

 

[Mr.Tickle]

I would like to see you attempt an & operator on those values ROFL

Assuming it starts at 0 for bitfield.one. What if I want to pick off the
value bitfield.four? Im screwed.


Sure sure go ahead, say "but you have to set them all in powers of 2
yourself", well what if i dont want to and just want the following

[Flags]
enum bitfield
{
None = 0,
one,
two,
three,
four,
five,
six,
all = one | two | three | four | five | six
}

Well the above SHOULD work, but it doesnt because you DEFAULT to non base 2
values.

Take yer cranium from yer rectum ye ninney.

[Flags]
enum bitfield
{
one,
two,
three,
four,
five,
six,
all = one | two | three | four | five | six
}

man thats gonna throw up some interesting results, thanks to Eric
Gunnarson's ignorance.


Three cheers for da man that supports bad code like the above. Bitfields
should be set to the base of the machine, ie powers of 2, you dumbschmuck.

Flags in reality does jack all, except permit logical operators on enums, so
lets look the other way when it comes to the above and yet claim from the
rooftops that C# is da biz for safe coding, well it aint in the above case.

It's fairly common for people to define values that are combinations of the
others:

enum Test
{
First = 0x01,
Second = 0x02,
AllBits = 0x03,
NoBits = 0x00,

}

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

When setting the [Flags] attribute on an enum, why should I have to specify
powers of 2 when the compiler should see this is a bitfield and set the
range accordingly, why should I have to do the work that the compiler can
do?


To me this is just asking for errors to be introduced by offloading this
responsibility onto the programmer.

Sure we should be able to override a value in the bitfield enum to allow
ranges like All = Enum1Val | Enum2Val; etc.

 

[ozbear]

The documentation does seem to be incorrect. I am using the 1.1
framework, if that matters, and given the declaration:

enum answer {yes, no maybe};

i can declare a variable of type -answer- and use the C# OR
operator...

answer test = answer.yes | answer.no;

According to the doco, I need the [Flags] attribute applied to my
-answer- enumeration, yet the C# compiler accepts the above test =
assignment without complaint. In other words...the presence or
absence of [Flags] makes no difference to the /assignment/.

I accept that it will affect other things like ToString(), etc.

It should work as per the above according to sectino 14.10.2 of the
ECMA spec.

The documentation you were talking about is the FlagsAttribute remarks,
presumably? If so, it's quite an interesting case - it's up to a
language to decide what it allows, so I don't think the FlagAttribute
documentation should really be talking about that at all. What it
could/should be talking about is that when [Flags] is applied, bitwise
operations are *expected* to give useful results (whereas they may not
otherwise). A language *could* decide to only allow bitwise operations
on enumerations which are marked with the [Flags] attribute, of course.

--

Jon,
Yes, it was in the FlagsAttribute section of the documentation.
I haven't located anything specifically for [Flags]. I also note
that the doco uses the word "OR" rather than the C# "|" operator so
perhaps its remarks are Visual Basic oriented. I don't do VB so
I haven't tried.

Regards, Oz

 

[Stoyan Damov]

I also note

that the doco uses the word "OR" rather than the C# "|" operator so
perhaps its remarks are Visual Basic oriented. I don't do VB so
I haven't tried.

LOL)) You made my day)))))))))