On Monday, 11 August 2014 at 06:29:55 UTC, Walter Bright wrote:
It's not ideal, but it gets the job done. Keep in mind that you
are proposing to use withs to mix up multiple enums with lots
of members - name clashes are very possible, and there's no
visual clue which enum a name belongs to. It merges multiple
scopes together without collision detection.
I'm not so sure it is desirable. It does save some typing, but
at another increase in language complexity, which has costs as
well.
I suppose... Except where i'm using them is in a very controlled
manner, and the likelihood of two having the same enum name is
very very very low. If we assume the enums had a specific meaning
for a specific field, even then it would be fairly obvious which
one they came from unless they reused similar generic messages.
enum FSErrors { isReadOnly, fileLocked, isNetworkFile,
fileCurrupted }
enum NetoworkErrors { packedDeliveryFailed, failedCRC,
unreachableHost, packetSizeMismatch }
enum ZlibCompressionErrors { outsideMemoryRange, crcMismatch,
missingDictionary, compressionTypeMissing, unableToAllocateMemory
}
In most of these it's context as part of it's message type
identifies what it belongs to. Regardless the enum won't transfer
blindly to an incompatible one, so the failedCRC and crcMismatch
are easy to fix and swap. Even if one did duplicate/shadow it,
only if you actually attempted a call did you need to be more
specific to resolve the conflict like you do using with(){} (or
multiple chained withs)
Much like gotos, the feature can easily cause major headaches,
but that's if it's used incorrectly. If there's going to be lots
of name clashing obviously using with is a bad choice, but for a
static declaration of items that has several types in them and
each type has specific fields seems like a perfect example of how
to shrink and clean up code for what's very obvious, easy to look
up, and follows a pattern that doesn't need a huge amount of
verifying to know it's correct. For a couple lines obviously
being highly verbose makes sense. But when you exceed a certain
number, the verboseness just clutters the screen.
Naturally including the feature could be a very bad thing in the
long run, i really don't know. But there could be some good from
it too. How many cases are similar to mine where with(): would be
a heaven-sent? Yeah i can get around it, You can get around
arrays without having the length attached to the pointer too. C's
& C++ are proof it can be done! (just an example).
