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

[Walter Bright via Digitalmars-d]

On 8/10/2014 6:52 PM, Era Scarecrow wrote:
> On Monday, 11 August 2014 at 00:23:36 UTC, Walter Bright wrote:
>> I'd suggest simply:
>>
>>    private alias FlagStates FS;
>>
>> then use FS.def, etc.
>
>   The source code has 400 lines (955-1376) where it uses flags of one kind or
> another. Constantly having to add that type of thing in just fills up space
> without telling a lot of information. Aliasing makes it smaller, but the problem
> is still there.
>
>   Feels like backtracking to hungarian notation. In a large bulk data I know the
> data type is of certain types because I need to throw them in a templated/static
> constructor that handles them anyways. Having to do it a second or third time
> just bets uselessly verbose. It's why auto is so nice where you don't have to
> explicitly state everything when you really don't need it to be there. It just
> clutters it, like 1,000 times at least...
>
>   There's no mystery of what data goes where, and the enums can only enter in
> certain formats so having lots of (this boilerplate) code to describe what it is
> and where it's from. Mind you this is a public statically declared global known
> at compile-time...
>
>   Maybe i'm hoping for too much...
>
> Original:  {ValueType.raw, "Height Data", 4228, Flags(FlagStates.noChange,
> FlagStates.noPrintClashes, FlagStates.hashPrint)}]},
>
>   //2 shorthand aliases as you suggest, a bit better
> Becomes:   {VT.raw, "Height Data", 4228, Flags(FS.noChange, FS.noPrintClashes,
> FS.hashPrint)}]},

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.