On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
> On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
>>
>> This looks really clean for code modularity.
>>
>> import io = std.stdio : {writeln, write}, ...
>
> What does this add? A line like below would be confusing.
> import io = std.stdio : {writeln, write}, writefln;
>
> The following code compiles and the imports are less confusing.
>
> import io = std.stdio : writeln, write;
> import std.stdio : writefln;
>
> void main()
> {
>     io.write("foo");
>     io.writeln("bar");
>     writefln("My items are %(%s %).", [1,2,3]);
> }

Its more like this:

import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, …};

oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);

On Thursday, 17 August 2017 at 21:03:33 UTC, aberba wrote:
> On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
>> On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
>>>
>>> This looks really clean for code modularity.
>>>
>>> import io = std.stdio : {writeln, write}, ...
>>
>> What does this add? A line like below would be confusing.
>> import io = std.stdio : {writeln, write}, writefln;
>>
>> The following code compiles and the imports are less confusing.
>>
>> import io = std.stdio : writeln, write;
>> import std.stdio : writefln;
>>
>> void main()
>> {
>>     io.write("foo");
>>     io.writeln("bar");
>>     writefln("My items are %(%s %).", [1,2,3]);
>> }
>
> Its more like this:
>
> import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, …};
>
> oo.writeln();
> oo.write();
> oo.filter(...);
> oo.map(...);

Someone gets it! ;)

On 17.08.2017 23:03, aberba wrote:
> On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
>> On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
>>>
>>> This looks really clean for code modularity.
>>>
>>> import io = std.stdio : {writeln, write}, ...
>>
>> What does this add? A line like below would be confusing.
>> import io = std.stdio : {writeln, write}, writefln;
>>
>> The following code compiles and the imports are less confusing.
>>
>> import io = std.stdio : writeln, write;
>> import std.stdio : writefln;
>>
>> void main()
>> {
>>     io.write("foo");
>>     io.writeln("bar");
>>     writefln("My items are %(%s %).", [1,2,3]);
>> }
> 
> Its more like this:
> 
> import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, …};
> 
> oo.writeln();
> oo.write();
> oo.filter(...);
> oo.map(...);
> 

private struct oo{
    import std.stdio: writeln, write;
    import std.algorithm: filter, map;
    // …
}

void main(){
    oo.write("result: ");
    oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}

On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
>
> private struct oo{
>     import std.stdio: writeln, write;
>     import std.algorithm: filter, map;
>     // …
> }
>
> void main(){
>     oo.write("result: ");
>     oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
> }

Would not have thought to do that! Very cool.

Quick follow up: is there a reason this why renamed selective imports don't work this way? As in the bug from the link below we discussed above

https://issues.dlang.org/show_bug.cgi?id=17756

Re-writing the import like this seems like the perfect bug fix?

On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
> On 17.08.2017 23:03, aberba wrote:
>> On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
>>> On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
>>>>
>>>> This looks really clean for code modularity.
>>>>
>>>> import io = std.stdio : {writeln, write}, ...
>>>
>>> What does this add? A line like below would be confusing.
>>> import io = std.stdio : {writeln, write}, writefln;
>>>
>>> The following code compiles and the imports are less confusing.
>>>
>>> import io = std.stdio : writeln, write;
>>> import std.stdio : writefln;
>>>
>>> void main()
>>> {
>>>     io.write("foo");
>>>     io.writeln("bar");
>>>     writefln("My items are %(%s %).", [1,2,3]);
>>> }
>> 
>> Its more like this:
>> 
>> import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, …};
>> 
>> oo.writeln();
>> oo.write();
>> oo.filter(...);
>> oo.map(...);
>> 
>
> private struct oo{
>     import std.stdio: writeln, write;
>     import std.algorithm: filter, map;
>     // …
> }
>
> void main(){
>     oo.write("result: ");
>     oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
> }

Wow, that might solve the problem! A little more verbose but it does combine everything.

Any downsides?

Thanks.

On 18.08.2017 01:25, jmh530 wrote:
> On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
>>
>> private struct oo{
>>     import std.stdio: writeln, write;
>>     import std.algorithm: filter, map;
>>     // …
>> }
>>
>> void main(){
>>     oo.write("result: ");
>> oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
>> }
> 
> Would not have thought to do that! Very cool.
> 
> Quick follow up: is there a reason this why renamed selective imports don't work this way?

I don't think there is. (I.e. I think it is indeed a bug.)

> As in the bug from the link below we discussed above
> 
> https://issues.dlang.org/show_bug.cgi?id=17756
> 
> Re-writing the import like this seems like the perfect bug fix?

It's one way to do it, but the compiler does not necessarily need to generate a new type. Note that unfortunately, renamed imports don't overload, so this would not work even with the fixed bug:

import oo=std.stdio: writeln, write;
import oo=std.algorithm: filter, map; // error: oo redefined

void main(){
    oo.write("result: ");
    oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}

I think this is working as designed, but IMO they should just overload (using distinct overload sets so the semantics is similar to the case when using the struct), as should named mixins.

On 18.08.2017 03:11, Johnson Jones wrote:
>>>
>>
>> private struct oo{
>>     import std.stdio: writeln, write;
>>     import std.algorithm: filter, map;
>>     // …
>> }
>>
>> void main(){
>>     oo.write("result: ");
>> oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
>> }
> 
> Wow, that might solve the problem! A little more verbose but it does combine everything.
> 
> Any downsides?
> 

- It is more verbose. ;)


- IMAO it shouldn't even work without 'public' on the imports. (So if someone decides to fix that it might break and become more verbose.)


- It introduces a new type that would not really be necessary. This is avoidable, at the cost of a little more verbosity:


private template Imports(){
    public import std.stdio: writeln, write;
    public import std.algorithm: filter, map;
}
private alias oo = Imports!();

void main(){
    oo.write("result: ");
    oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}


The pattern can be abstracted into a utility template:

---
module util;

// ...

template Imports(T...){
    import std.string,std.algorithm;
    mixin([T].map!(x=>"public import "~x~";").join);
    // or, starting from DMD 2.076, you could use static foreach instead:
    // static foreach(x;T) mixin("public import "~x~";");
}

// ...

---

---
module main;

import util: Imports;
private alias oo = Imports!(
    `std.stdio: writeln, write`,
    `std.algorithm: filter, map`
);

void main(){
    oo.write("result: ");
    oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));	
}
---


> Thanks.

np.

On Friday, 18 August 2017 at 09:18:42 UTC, Timon Gehr wrote:
> ---
> module util;
>
> // ...
>
> template Imports(T...){
>     import std.string,std.algorithm;
>     mixin([T].map!(x=>"public import "~x~";").join);
>     // or, starting from DMD 2.076, you could use static foreach instead:
>     // static foreach(x;T) mixin("public import "~x~";");
> }
>
> // ...
>

The static foreach is nice...doesn't depend on phobos.

On Friday, 18 August 2017 at 09:18:42 UTC, Timon Gehr wrote:
>> Any downsides?
>> 
> ...
>
> - It introduces a new type that would not really be necessary. This is avoidable, at the cost of a little more verbosity:
>

D newbie here: is there a non-negligible cost to creating a stateless struct type?

Also, since the struct is private and only used for its aliases, if there a chance the compiler might elide those costs?