I haven't found this specific topic anywhere in the archives so I'll throw it out there for feedback.

[quote] TDPL pg. 81
 "There is no ambiguity-related danger in using nested 'with's because the language disallows shadowing of a symbol introduced by an outer with by a symbol introduced by an inner with. In brief, in D a local symbol can never shadow another local symbol"
[/quote]

 Technically 'with' blocks can be placed just about anywhere you could run normal code (and sometimes replaces blocks), however there are cases where I'm required to use extra braces. Mind you this is minor syntactical issues, but..

  enum E {}
  enum F {}
  enum G {}

currently:

  void func()
  //in/out contracts
  body {
    with (E) {

    }
  }

block replacement:

  if () {
  } else with(E) {
    //
  }

Theoretically legal...

  void func()
  //in/out contracts
  body with (E) { //with replaces normal block

  }

 The above refuses to compile, however I don't feel I'd need an extra level of indentation, and since it's static data like Enums perhaps you'd want multiples. Last 'with' only accepts one argument, but I wonder if it wouldn't hurt to enter multiple. Mind you it will still error during compiling if there's ambiguity. This makes more sense with enums and statically known data vs variables.

  with(E) {
    with(F) {
      with(G) {
        //code
      }
    }
  }

or (better, TDPL pg. 81)

  with(E) with(F) with(G) {
    //code
  }

vs

  with(E, F, G) {
    //code
  }

 Perhaps a feature request. I know it's not essential so I won't try and push it, but syntactical sugar can't hurt right?

>Theoretically legal...
>
>  void func()
>  //in/out contracts
>  body with (E) { //with replaces normal block
>
>  }

This seems sensible. Multiple with seems like a recipe for confusion and member name clashes.

On Wednesday, 17 October 2012 at 06:07:34 UTC, ixid wrote:
>>Theoretically legal...
>>
>> void func()
>> //in/out contracts
>> body with (E) { //with replaces normal block
>>
>> }
>
> This seems sensible. Multiple with seems like a recipe for confusion and member name clashes.

 True... But if you're planning on going multiple levels of with, then it isn't going to matter much.

 In a project of mine I'll have a few different enum types, each one with their own sets of flags used in a structure. So you're looking at something like.. As an off the wall example.

  enum OnOff {off, on}
  enum Speed {stop, slow, medium, fast, reallyFast, lightspeed}
  enum MemoryType {allocated, stack}
  enum EngineType {internalCombustion, electrical, magical, warp, teleportion}
  enum Size {tiny, small, medium, large, huge}

  struct Vehicle {
    OnOff state;
    Speed speed;
    const MemoryType memAt;
    const EngineType engine;
    const Size size;
  }

 So in this kind of case where none of the enums clash, then manually doing them. True there's a clash from size/speed, but that's fairly easy to fix in the case it's used.

  with (OnOff, Speed, MemoryType, EngineType, Size)
//    or
//  with (OnOff) with(Speed) with(MemoryType)
//      with(EngineType) with(Size)
  {
    Vehicle Enterprise = {off, stop, stack, warp, huge};

    //fully explicit, but doesn't buy you much except clutter
    Vehicle Enterprise2 = {OnOff.off, Speed.stop, MemoryType.stack,
                            EngineType.warp, Size.huge};

    //wrong order, enums complain but is fairly obvious
    //based on types (and the error message) how to reorder it.
    Vehicle ModelT = {stop, allocated, medium, internalCombustion, off};
  }