Code says more than 1000 words:

enum StreamFeature { ISREADABLE = 1, ISWRITABLE = 2, ISSEEKABLE = 4 };
// ...
class Stream {
  StreamFeature features();
  // ...
}
// ...
if ((someStream.features() && StreamFeatures.ISREADABLE) != 0)
  // ...

Pros: works now
Cons: What is more than 32 features, ugly even if != 0 is dropped.

enum StreamFeature { ISREADABLE, ISWRITEABLE, ISSEEKABLE };
set StreamFeatures { StreamFeature };
//..
class Stream {
  StreamFeatures features();
  // ...
}
// ...
if (StreamFeature.ISREADABLE in stream.features())
  // ...

Pros: No limit, looks good, is self commenting, focus is on
      functionality not implementation
Cons: Well... requires set support or at the very least a standard
      set lib.

// Fredrik Olsson

Fredrik Olsson wrote:
> Code says more than 1000 words:
> 
> enum StreamFeature { ISREADABLE = 1, ISWRITABLE = 2, ISSEEKABLE = 4 };
> // ...
> class Stream {
>   StreamFeature features();
>   // ...
> }
> // ...
> if ((someStream.features() && StreamFeatures.ISREADABLE) != 0)
>   // ...
> 
> Pros: works now
> Cons: What is more than 32 features, ugly even if != 0 is dropped.
> 
> enum StreamFeature { ISREADABLE, ISWRITEABLE, ISSEEKABLE };
> set StreamFeatures { StreamFeature };
> //..
> class Stream {
>   StreamFeatures features();
>   // ...
> }
> // ...
> if (StreamFeature.ISREADABLE in stream.features())
>   // ...
> 
> Pros: No limit, looks good, is self commenting, focus is on
>       functionality not implementation
> Cons: Well... requires set support or at the very least a standard
>       set lib.
> 
> // Fredrik Olsson

Just write a set class. It's not /that/ hard.

A very good point though! What if a "set" was nothing more than a enum whose values are shifted, rather than incremented. The type of the "set" would as big as needed for the set's values to fit:

set StreamFeature { ISREADABLE, ISWRITABLE, ISSEEKABLE };
// could be identical to:
enum StreamFeature { ISREADABLE = 1, ISWRITABLE = 2, ISSEEKABLE = 4 };

L.

Hasan Aljudy skrev:
> Fredrik Olsson wrote:
<snip>
> Just write a set class. It's not /that/ hard.

That I already have, two implementations: Set and SmallSet, the first using a hash table and the second a bit field for speed.

But that is sort of not the point, if D did not have arrays I am quite sure no one would suggest "Write an array class", it is how Java and .net have solved it, but it is not the best solution, proved by both Java, C# and others "knows" about arrays anyway.
Same goes for strings "write a string class", the C++ crowd have settled for that, the D crowd have not, and I think we all feel better off that way.

My argument is the same with sets, it is such a useful, beautiful and natural part of programming that it should not be treated as a second class citizen in some backwater library.

// Fredrik

Fredrik Olsson wrote:
> Hasan Aljudy skrev:
> 
>> Fredrik Olsson wrote:
> 
> <snip>
> 
>> Just write a set class. It's not /that/ hard.
> 
> 
> That I already have, two implementations: Set and SmallSet, the first using a hash table and the second a bit field for speed.
> 
> But that is sort of not the point, if D did not have arrays I am quite sure no one would suggest "Write an array class", it is how Java and .net have solved it, but it is not the best solution, proved by both Java, C# and others "knows" about arrays anyway.
> Same goes for strings "write a string class", the C++ crowd have settled for that, the D crowd have not, and I think we all feel better off that way.
> 
> My argument is the same with sets, it is such a useful, beautiful and natural part of programming that it should not be treated as a second class citizen in some backwater library.
> 
> // Fredrik

I like the way Java implements String in a class.
If D had a _standard_ array class, I think I'd use it.

C++ std::string just sucks, the whole STL sucks, but that's another issue.

You raise a valid point, but, for D, all we need is a standard Set class. It doesn't need to be built in.

If you've writte a set class as you say, submit it to Walter, it might end up in phobos!

Hasan Aljudy skrev:
> Fredrik Olsson wrote:
> 
>> Hasan Aljudy skrev:
>>
>>> Fredrik Olsson wrote:
>>
<snip>
> You raise a valid point, but, for D, all we need is a standard Set class. It doesn't need to be built in.
> 
> If you've writte a set class as you say, submit it to Walter, it might end up in phobos!

Perhaps you are right, but _I_ have found myself yearning for sets fifty times as often than I have felt the need for imaginary and complex reals.

I will make them public shortly after gdc 0.18 is out, I think I can make it much neater with the template additions added after dmd 0.140. But then again, releasing it and making it part of Phobos might be a bad thing(tm), as if people would find it very usable there is a threat of a library implementation becoming the standard, when I still firmly think it is something that should be part of the language. For looks, optimization, and flexibility.

// Fredrik