December 15, 2016
On Wednesday, 14 December 2016 at 23:38:19 UTC, Timon Gehr wrote:
> On 15.12.2016 00:17, Andrej Mitrovic wrote:
>>
>> ubyte[] readSomeBytes ( )
>> {
>>     return read(1024);
>> }
>>
>> It's a non-trivial exercise for the reader to understand where the
>> `read` symbol is coming from.
>
> pragma(msg,fullyQualifiedName!read);

Right, which requires building!
December 15, 2016
On Thursday, 15 December 2016 at 00:44:02 UTC, Andrej Mitrovic wrote:
> On Wednesday, 14 December 2016 at 23:38:19 UTC, Timon Gehr wrote:
>> On 15.12.2016 00:17, Andrej Mitrovic wrote:
>>>
>>> ubyte[] readSomeBytes ( )
>>> {
>>>     return read(1024);
>>> }
>>>
>>> It's a non-trivial exercise for the reader to understand where the
>>> `read` symbol is coming from.
>>
>> pragma(msg,fullyQualifiedName!read);
>
> Right, which requires building!

Also, this wouldn't work with overloads would it? :)
December 14, 2016
On 12/14/16 6:11 PM, H. S. Teoh via Digitalmars-d wrote:
> 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?

That's not a Boolean. One may be adding a little or a lot.

> 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?

That is correct.

> The
> specific syntax is really secondary.

That is also correct, and thanks for bringing it up; discussion of syntax eclipse other aspects. I'll make a pass to integrate your points.


Andrei
December 15, 2016
On Thursday, 15 December 2016 at 00:29:17 UTC, Chris M wrote:
> For the "with" keyword, why is the import statement kept? Seems unnecessary to keep it.
>
> void process(File input) import std.stdio;
> struct Buffered(Range) if (isInputRange!Range)
> with (std.range)
> {
>     ...
> }

to not block future uses of such `with` syntax for different purposes. and (which is more important for me, for example) to make greping easier. and to keep `with` semantics: it should introduce scope over *existing* things. explicit `import` brings the module to the existance. choose any options you like. ;-)
December 14, 2016
how about this:

variant 1 // currently legal D; just need to attach semantics

```
// applies to all below
@deps!({import std.stdio; pragma(lib, "curl"); }):

// applies to 1 below
@deps!({import std.range})
void fun(T)(isInputRange!T){} // depends on both deps

void fun2(File file){}  // depends on 1st deps ending with ':'

```

variant 2: //currently legal if not ending with ':' as above; less noisy
syntax
@deps{import std.stdio; pragma(lib, "curl"); }
@deps{import std.stdio; pragma(lib, "curl"); }: // applies to all below

Advantages:

* no new syntax (just new semantics)
* no nesting inside {}
* allows grouping multiple declarations under a single set of imports
* `grep import` will still work unlike many of the existing proposals
* can use existing traits to query for such imports (eg getSymbolsByUDA)
* allows a more general solution (eg also handles `pragma(lib, "curl");` if
we want that as well)




On Wed, Dec 14, 2016 at 4:54 PM, ketmar via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 15 December 2016 at 00:29:17 UTC, Chris M wrote:
>
>> For the "with" keyword, why is the import statement kept? Seems unnecessary to keep it.
>>
>> void process(File input) import std.stdio;
>> struct Buffered(Range) if (isInputRange!Range)
>> with (std.range)
>> {
>>     ...
>> }
>>
>
> to not block future uses of such `with` syntax for different purposes. and (which is more important for me, for example) to make greping easier. and to keep `with` semantics: it should introduce scope over *existing* things. explicit `import` brings the module to the existance. choose any options you like. ;-)
>


December 15, 2016
On Wednesday, 14 December 2016 at 20:16:29 UTC, Andrei Alexandrescu wrote:
> On 12/14/2016 03:13 PM, bitwise wrote:
>> I think the DIP indicated you may have considered this, but why not just
>> remove the requirement of 'static import ..' for using fully qualified
>> names?
>>
>> struct Buffered(Range) if (std.range.isInputRange!Range)
>> {
>>     import std.range;
>>     // ...
>> }
>>
>> You could then simply qualify any parameters or constraints and use
>> local imports for the body.
>
> We'd like people and simplistic tools such as grep to indicate quickly where imports are present. -- Andrei

From all ideas I read so far, this is my favorite. It's a really concise syntax.

What is the use case for using "grep" to find all imports? Even for something simplistic as to find all unittest blocks, one already needs to use Dscanner, so I don't see why this is a problem. Just image this case for "grep":

import std.algorithm,
std.range,
std.traits;

Moreover for a list of all imports, there is already a dedicated flag in DMD (-deps).
December 14, 2016
On 12/14/2016 09:21 PM, Seb wrote:
> What is the use case for using "grep" to find all imports?

The main idea here is to use "import" for importing things. -- Andrei
December 15, 2016
On Thursday, 15 December 2016 at 01:59:33 UTC, Timothee Cour wrote:
> how about this:
>
> variant 1 // currently legal D; just need to attach semantics
>
> ```
> // applies to all below
> @deps!({import std.stdio; pragma(lib, "curl"); }):
>
> // applies to 1 below
> @deps!({import std.range})
> void fun(T)(isInputRange!T){} // depends on both deps
>
> void fun2(File file){}  // depends on 1st deps ending with ':'
>
> ```
>
> variant 2: //currently legal if not ending with ':' as above; less noisy
> syntax
> @deps{import std.stdio; pragma(lib, "curl"); }
> @deps{import std.stdio; pragma(lib, "curl"); }: // applies to all below
>
> Advantages:
>
> * no new syntax (just new semantics)
> * no nesting inside {}
> * allows grouping multiple declarations under a single set of imports
> * `grep import` will still work unlike many of the existing proposals
> * can use existing traits to query for such imports (eg getSymbolsByUDA)
> * allows a more general solution (eg also handles `pragma(lib, "curl");` if
> we want that as well)

Really nice idea! Except it's still a little noisy. I would be really happy if this gets accepted...

December 15, 2016
On 15/12/2016 3:16 AM, Andrei Alexandrescu wrote:
> On 12/14/16 6:06 AM, rikki cattermole wrote:
>> On 14/12/2016 11:33 AM, Andrei Alexandrescu wrote:
>>> Destroy.
>>>
>>> https://github.com/dlang/DIPs/pull/51/files
>>>
>>>
>>> Andrei
>>
>> Others have brought up similar syntax to this:
>>
>> import(my.mod).Type!argsT(7)
>>
>> import(Identifier).Identifier
>>
>> It shouldn't be confused with string imports or the like and would be
>> more akin to a selective import.
>>
>> Pros:
>>  - Is an expression
>
> How does it then apply to declarations? -- Andrei

Like this?

import(my.mod).Type!argsT value;

Or?

import(my.mod).Type!argsT func(import(my.mod).Type!argsT arg) {

}
December 15, 2016
On Wednesday, 14 December 2016 at 19:39:55 UTC, Andrei Alexandrescu wrote:
> On 12/14/2016 02:04 PM, Meta wrote:
>> On Wednesday, 14 December 2016 at 17:32:10 UTC, H. S. Teoh wrote:
>>> What about:
>>>
>>>     /* Showing full declaration just for context */
>>>     bool myFunc(R1, R2)(R1 r1, R2 r2)
>>>     import {
>>>         std.range : isInputRange,
>>>         std.traits : isNum = isNumeric
>>>     }
>>>     if (isInputRange!R1 && isInputRange!R2 &&
>>>         isNum!(ElementType!R1))
>>>     in { assert(someCondition!R1); }
>>>     out(result) { assert(result == expectedResult(...)); }
>>>     body
>>>     {
>>>         ...
>>>     }
>>>
>>>
>>> T
>>
>> The fact that declarations like this WILL show up in Phobos or elsewhere
>> if this proposal is implemented triggers my gag reflex. There's got to
>> be a better way than tacking yet another pre-ambulatory clause to the
>> function body.
>
> What I see here is a function definition that has:
>
> * parameters and return types
> * dependencies on other modules
> * the static condition under which arguments are acceptable
> * the dynamic condition under which arguments are acceptable
> * the guarantee made upon successful completion
> * the implementation
>
> ... each of which is:
>
> * easily distinguishable
> * opt-in
>
>
> Andrei

Don't forget "looks awful and cluttered as hell".