proposal: allow 'with(Foo):' in addition to 'with(Foo){..}'

[Era Scarecrow via Digitalmars-d]

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).