On Saturday, November 24, 2018 10:41:56 PM MST H. S. Teoh via Digitalmars-d-
learn wrote:
> On Sat, Nov 24, 2018 at 05:48:16PM +0000, Stanislav Blinov via
Digitalmars-d-learn wrote:
> > On Saturday, 24 November 2018 at 17:43:35 UTC, Jonathan M Davis wrote:
> > > I'm still inclined to think though that it should be legal to just
> > > use version directly in the member list.
> >
> > Yup. UDAs did get in there eventually, and version should too.
>
> I think this would be a trivial DIP, by making it such that a version
> block inside an enum would lower to the above code. Of course, it could
> be taken further: the above trick doesn't quite handle this case:
>
> enum E {
> a,
> version(Windows) {
> b, c
> }
> version(Posix) {
> d
> }
> }
>
> But this looks like such an antipattern that it probably should be
> written differently anyway, or just generated via a string mixin.
It's something that comes up fairly frequently actually when dealing with
system APIs. For instance, if you want your socket API to provide the full
functionality of the underlying C API, then you're going to have to provide
not only differing enum values for things like socket options or socket
family, but you're actually going to have to provide different enum members
in some cases.
So, sure, if you're writing something that's purely D and can be properly
platform-agnostic, then having different enum members for different
platforms would be bad, but once C APIs get involved, I definitely would not
consider it to be an anti-pattern. At that point, it has a tendency to
become a necessity, and I've had several occasions where being able to
version enum members would have made the code shorter. It also would have
eliminated the need for version(D_Ddoc) (or the druntime or Phobos
equivalents).
- Jonathan M Davis
