DIP10005: Dependency-Carrying Declarations is now available for community feedback

Joseph Rushton Wakeling via Digitalmars-d digitalmars-d at puremagic.com
Wed Dec 14 01:01:30 PST 2016


On Wednesday, 14 December 2016 at 07:17:57 UTC, Jacob Carlborg 
wrote:
> On 2016-12-14 03:23, Andrei Alexandrescu wrote:
>> On 12/13/16 9:22 PM, Hatem Oraby wrote:
>
>>> with(import std.range)
>>> bool equal(R1, R2) if (isInputRange!R1 && isInputRange!R2)
>>> { ... }
>>
>> I considered this, then figured with is superfluous. -- Andrei
>
> It could allow to have a better control of the scope which the 
> import affects, i.e.:
>
> with(import std.range)
> {
>   void foo(T) if (isInputRange!T)
>   void bar(T) if (isInputRange!T)
> }

Trouble is, there's no real difference between doing that, vs. 
creating a standalone module containing `foo` and `bar` with 
`import std.range;` as a top-level import.

The `with` syntax could also be used internally in functions to 
narrow the functionality that has access to the imported symbols, 
but something like:

void foo(T)(T input)
{
     with (import some_module)
     {
         // only stuff in here has access
         // to some_module's symbols
     }

     // nothing here has access to
     // some_module's symbols
}

... doesn't give you anything that you can't already get using:

void foo(T)(T input)
{
     {
         import some_module;
         // only stuff in here has access
         // to some_module's symbols
     }

     // nothing here has access to
     // some_module's symbols
}

In fact that's a good argument against the `with` syntax 
entirely, because in typical usage AFAIR, it creates a scope, 
whereas one wouldn't want the symbols defined in Hatem's proposal 
to be scoped relative to the module.

It's a shame, because unlike Andrei I don't feel use of `with` is 
in principle superfluous: it has a value in clarifying intention, 
while allowing the use of traditional `import something` syntax.  
But special-casing of where `with` does and doesn't create a 
scope seems ... less good.


More information about the Digitalmars-d mailing list