"with" should be deprecated with extreme prejudice

[Bill Baxter]

On Sun, May 17, 2009 at 9:53 PM, Robert Fraser
<fraserofthenight at gmail.com> wrote:
> Nick Sabalausky wrote:
>>
>> "BCS" <none at anon.com> wrote in message
>> news:a6268ff5f5d8cba54f824da454 at news.digitalmars.com...
>>>
>>> Hello Nick,
>>>
>>>> I'm not a touch-typer, but I've never seen much of a point to "with".
>>>> If I have to access a bunch of members of
>>>> "foo.member.x.bar[17].fizzle", I'll just do "auto fizz =
>>>> foo.member.x.bar[17].fizzle;" and use that, or put it into
>>>
>>> that dosn't work if it's by value and is used as an Lvalue.
>>>
>>>> a function that takes a "typeof(fizze)", or do something else along
>>>
>>> like this? that looks... odd.
>>>
>>> void outer()
>>> {
>>>    void inner(ref T t)
>>>    {
>>>         t.somthing;
>>>         ...
>>>    }
>>>    inner(foo.member.x.bar[17].fizzle);
>>> }
>>>
>>>> those lines. I've yet to come across a case where something like
>>>> that isn't perfectly sufficient.
>>>>
>>
>> Like I said, "or something along those lines". It all depends on the
>> specific code. I just haven't ever had any specific case where I felt like I
>> needed "with".
>
> I mainly use it for initialization of things:
>
> static S opCall(_x, _y)
> {
>        S s;
>        with(s)
>        {
>                x = _x;
>                y = _y;
>                happiness = null;
>        }
>        return s;
> }

I find this to be the most convenient way to transform C++
constructors into struct static opCalls, so I've used it a lot in code
I translated from C++.

But the need there should be eliminated by giving structs real
constructors instead of this static opCall kludge (I thought D2 had
this already, actually...)

One place 'with' is kinda cute is for configuring new objects in a
fire & forget manner:

    with (new WindowWidget) {
              parent = mainWin;
              width = 100;
              height = 100;
    }

That gives you something that works almost like named arguments.

---
On a related note I do think some mechanism similar to C++'s "using"
would be good to have that would let you bring particular namespaces
into the direct lookup scope.  However the same caveats apply --  it
should never be possible to silently change the meaning of code that
has "using foo.bar" by adding or removing something from module
foo.bar.

I think someone proposed allowing aliasing of dot like "alias foo.bar
." to achieve that -- kind of like alias this for structs.

Anyway, I think if you're going to allow co-mingling of module scopes
with top-level imports, then it should also be possible to limit the
mingling to just inner scopes.

--bb