You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There was a discussion over in #4301 about the value of bitmasks.
It seems to me that bitmasks are often the poor man's way to implement sets. Perhaps we should have real sets, that you can union, intersect, difference, iterate, et cetera.
I don't know what the syntax would look like, especially when you consider object literals and their friends. If object literals end up JavaScript style:
o = { a: 1, b: 2 };
then perhaps a name without a value would mean a set member:
o = { flag1, flag2 };
This might be syntactic sugar that just makes those be boolean members with values of true, which would also allow you to say
if (o.flag1) ...
Or maybe object literals are enough:
o = { flag1: true, flag2: true };
The text was updated successfully, but these errors were encountered:
#4203 is probably being subsumed under #3088, which will probably cover #4294 too.
It may be that sets will be a special case of objects/dictionaries/associative-arrays. You want to ensure that set support has all of the features that you might expect. An object with members set to boolean true behaves a lot like a set, in that you can say if (o.flag), but you want to also make sure that you have intersection, difference, union, et cetera. Some of those might be covered by #4337, which is a general object-manipulation function, but we'd need to look.
There was a discussion over in #4301 about the value of bitmasks.
It seems to me that bitmasks are often the poor man's way to implement sets. Perhaps we should have real sets, that you can union, intersect, difference, iterate, et cetera.
I don't know what the syntax would look like, especially when you consider object literals and their friends. If object literals end up JavaScript style:
then perhaps a name without a value would mean a set member:
This might be syntactic sugar that just makes those be boolean members with values of true, which would also allow you to say
Or maybe object literals are enough:
The text was updated successfully, but these errors were encountered: