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

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Wed Dec 14 15:11:12 PST 2016


On Wed, Dec 14, 2016 at 04:08:56PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/14/2016 03:33 PM, H. S. Teoh via Digitalmars-d wrote:
> > That's easy to fix:
> > 
> > 	import { a : b, c;  d: e, f; }
> 
> The cost being adding new syntax. -- Andrei

Aren't we already adding new syntax?

On thinking about this again, though, isn't the whole point of this DIP
to add a way of attaching imports X, Y, Z to some declaration such that
the imports are in effect for the scope of the declaration?  The
specific syntax is really secondary.  I think we should rather be more
concerned about the semantics of it, such as:

(1) The scope of the imports: I assume the import would be in effect
until the end of the function body, correct? Or does it only last until
the beginning of the function body?

   (a) Are DCD-imported symbols accessible in in- and out-contracts?

   (b) Are DCD imports permitted in the definition of inner functions?
   What is their effect, if allowed? Will symbols thus imported be
   restricted to the body of the inner function, or will it be visible
   throughout the outer function body?

(2) How overloads are handled:

   (a) If the current module declares symbol X, and a DCD import pulls
   in another module that declares X, which X will it resolve to when
   the declaration references X?  Are there cases of possible symbol
   hijacking here?  What if the function body also declares a local
   symbol X?

   (b) If there are multiple DCD imports that declare symbol X, how
   would overload resolution work?

   (c) How are parameter symbols figured into overload resolution? E.g.,
   if the DCD import pulls in module M that declares a module global
   xyz, and one of the function parameter names is also xyz.

   (d) Will symbols in a DCD imported module that aren't specifically
   imported shadow module globals, parameters, or local variables?
   E.g., you import my.module : X, but my.module also declares Y, and
   there's a {module global (in the current module), parameter, local
   variable} called Y.  How would overload resolution work in this case?

(4) Are DCD imports restricted to function declarations, or template
declarations, or all declarations in general?

   (a) I.e., is it possible to declare a module global of type X, where
   X is defined by another module pulled in via a DCD import?
   
   (b) What about the other eponymous template shorthands, like `enum
   E(X) = ...`: will it be possible to attach DCD imports to that? E.g.,
   if we want to say isInputRange!X in the enum definition.

   (c) Is it possible to attach DCD imports to delegate / lambda
   definitions? If so, what is their scope / interaction with the
   containing scope?

(5) Is it possible to attach DCD imports to individual parameters? E.g.:

	auto myFunc(import.std.stdio.File f) { ... }

	or:

	auto myFunc(scope void delegate(import.std.stdio.File f) dg)
	{ ... }

   Or do such imports have to be attached to the top-level declaration?


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have
biases.  He/She has prejudices. -- Gene Wirchenko


More information about the Digitalmars-d mailing list