August 24, 2018
On Friday, 24 August 2018 at 13:54:51 UTC, Jonathan Marler wrote:
>
> Good to know others are using it.  Of course making it a core part of the language would mean that IDEs would be free to add support for it, whether it was added to `object.d` or with some other means such as a new syntax, i.e.
>
> (import std.stdio).writefln(...)
>
> I didn't quite understand your last point.  Adding `from` to `object.d` wouldn't make it a keyword, it would still be an identifier.  And you could still use it as an identifier in your own code.

haha oops, complete brain fart :p - you're correct on both accounts.
August 24, 2018
On Friday, 24 August 2018 at 20:04:22 UTC, Jonathan Marler wrote:
> I'd gladly fix it but alas, my pull requests are ignored :(

They aren't! It's just that sometimes the review queue is pretty full.
I have told you before that your contributions are very welcome (like they are from everyone else) and if there's anything blocking your productivity you can always ping me on Slack.
August 24, 2018
On Friday, 24 August 2018 at 20:36:06 UTC, Seb wrote:
> On Friday, 24 August 2018 at 20:04:22 UTC, Jonathan Marler wrote:
>> I'd gladly fix it but alas, my pull requests are ignored :(
>
> They aren't! It's just that sometimes the review queue is pretty full.
> I have told you before that your contributions are very welcome (like they are from everyone else) and if there's anything blocking your productivity you can always ping me on Slack.

Don't tempt me to start contributing again :)  I had months where I got almost no attention on a dozen or so PRs...I love to contribute but I'd have to be mad to continue throwing dozens of hours of work away.

If the problem gets solved I'll willingly start working again, but I don't think anything's changed.
August 24, 2018
On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote:
> On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin wrote:
>>
>> I just published it on the dub registry in public domain (I hope Daniel Nielsen is ok with that. After all, it's just 3 lines of code)
>>
>> Package page: https://from.dub.pm/
>>
>
> I'm fine with it, public domain is great! Although I would greatly prefer object.d since I don't use dub myself.
>
> FYI Andrei has an open pull request:
> https://github.com/dlang/druntime/pull/1756
>
> But it's stalled due to a bug:
> https://issues.dlang.org/show_bug.cgi?id=17181

Me too. I've found from meanwhile defined in so many different places, we really need it to be part of standard D. I don't get it why it can't be merged just because of a bug that affects also other local imports. Ok, with the bug it can't be used everywhere in phobos, but it remains useful in so many other places.
August 24, 2018
On 8/24/18 6:29 PM, Jonathan Marler wrote:
> On Friday, 24 August 2018 at 20:36:06 UTC, Seb wrote:
>> On Friday, 24 August 2018 at 20:04:22 UTC, Jonathan Marler wrote:
>>> I'd gladly fix it but alas, my pull requests are ignored :(
>>
>> They aren't! It's just that sometimes the review queue is pretty full.
>> I have told you before that your contributions are very welcome (like they are from everyone else) and if there's anything blocking your productivity you can always ping me on Slack.
> 
> Don't tempt me to start contributing again :)  I had months where I got almost no attention on a dozen or so PRs...I love to contribute but I'd have to be mad to continue throwing dozens of hours of work away.

I thought we were going to get the unittest import problem solved, but then you closed the PR abruptly (we did get phobos to stop compiling with -dip1000 so we could work around the linker errors).

In any case, I can understand the feeling of frustration. I also have no power to force others to review who make important decisions, so I can't guarantee it won't happen again. I myself would love to have the time to get more reps with the compiler code, but I'm hopelessly lost when reviewing dmd stuff currently.

> If the problem gets solved I'll willingly start working again, but I don't think anything's changed.

I'll just be blunt -- I don't think "the problem" is ever going to get solved. This is the world of volunteer OSS development, and nobody has control over anyone's time but themselves. Things could go great for a month and then stagnate. If you hit on something that some VIP is looking to solve, it may get a lot of attention.

But I would recommend letting a PR stay open, pinging reviewers, etc. instead of closing them. Don't give up hope that it will not ever be merged.

-Steve
August 25, 2018
On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote:
> Ever since I read https://dlang.org/blog/2017/02/13/a-new-import-idiom/ I've very much enjoyed using the new `from` template.  It unlocks new idioms in D and have been so useful that I thought it might be a good addition to the core language.  I've found that having it in a different place in each project and always having to remember to import it makes it much less ubiquitous for me.
>
> One idea is we could add this template to `object.d`.  This would allow it to be used from any module that uses druntime without having to import it first.  The template itself is also very friendly to "bloat" because it only has a single input parameter which is just a string, extremely easy to memoize.  Also, unless it is instantiated, adding it to object.d will have virtually no overhead (just a few AST nodes which would dwarfed by what's already in object.d).  It would also be very easy to add, a single PR with 4 lines of code to druntime and we're done.
>
> Of course, if we don't want to encourage use of the `from` template then this is not what we'd want.  Does anyone have any data/experience with from?  All I know is my own usage so feel free to chime in with yours.

What uses does this actually have, I only see one example from the article and it is an oversimplistic example that effectively translates to either phobos being used or not being used. All the extra bloat this template would add to the already bloated if constraints is not welcome at all. The potential small benefit this might add isn't worth the unreadable mess it will turn code into.
August 25, 2018
On Saturday, 25 August 2018 at 00:40:54 UTC, tide wrote:
> On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote:
>> Ever since I read https://dlang.org/blog/2017/02/13/a-new-import-idiom/ I've very much enjoyed using the new `from` template.  It unlocks new idioms in D and have been so useful that I thought it might be a good addition to the core language.  I've found that having it in a different place in each project and always having to remember to import it makes it much less ubiquitous for me.
>>
>> One idea is we could add this template to `object.d`.  This would allow it to be used from any module that uses druntime without having to import it first.  The template itself is also very friendly to "bloat" because it only has a single input parameter which is just a string, extremely easy to memoize.  Also, unless it is instantiated, adding it to object.d will have virtually no overhead (just a few AST nodes which would dwarfed by what's already in object.d).  It would also be very easy to add, a single PR with 4 lines of code to druntime and we're done.
>>
>> Of course, if we don't want to encourage use of the `from` template then this is not what we'd want.  Does anyone have any data/experience with from?  All I know is my own usage so feel free to chime in with yours.
>
> What uses does this actually have, I only see one example from the article and it is an oversimplistic example that effectively translates to either phobos being used or not being used. All the extra bloat this template would add to the already bloated if constraints is not welcome at all. The potential small benefit this might add isn't worth the unreadable mess it will turn code into.

I can't help but laugh when you say "all the extra bloat this template would add..." :)  Sorry, I don't mean to insult but that really gave me a laugh.

I hate to be blunt, but its clear from your response that you failed to grok the original post, which makes anything else I say pointless.  So I'm going to slowly back away from this one...step...step..step....*stp*....*s*...*

August 24, 2018
On Friday, August 24, 2018 7:03:37 PM MDT Jonathan Marler via Digitalmars-d wrote:
> > What uses does this actually have, I only see one example from the article and it is an oversimplistic example that effectively translates to either phobos being used or not being used. All the extra bloat this template would add to the already bloated if constraints is not welcome at all. The potential small benefit this might add isn't worth the unreadable mess it will turn code into.
>
> I can't help but laugh when you say "all the extra bloat this template would add..." :)  Sorry, I don't mean to insult but that really gave me a laugh.
>
> I hate to be blunt, but its clear from your response that you failed to grok the original post, which makes anything else I say pointless.  So I'm going to slowly back away from this one...step...step..step....*stp*....*s*...*

It actually does add more template instantiations - and therefore arguably more bloat. It's just that because it more tightly ties importing to the use of the symbol, it reduces how many symbols you import unnecessarily, which can therefore reduce the bloat. So, if the symbol is used everywhere anyway, then from just adds bloat, whereas if it really is used in a more restricted way, then it reduces compilation times.

The reason that I personally hate from's guts is because of how verbose it is. I'd _much_ rather see lazy importing be added like Walter likes to bring up from time to time. It should get us the reduction in compile times without all of the verbosity. As such, I would hate to see from in a place like object.d (or honestly, anywhere in druntime or Phobos), because then it might be used in Phobos all over the place, and I simply don't want to have to deal with it. It's bad enough that we're using scoped and local imports all over the place. They do help with tying imports to what uses them (and in the case of templated code can actually result in imports only happening when they need to), but it's so painfully verbose. I'd much rather not see the situation get that much worse by from being considered best practice instead of just fixing the compiler so that it's more efficient at importing and thus avoiding all of that extra verbosity in the code.

- Jonathan M Davis



August 25, 2018
On Saturday, 25 August 2018 at 04:25:56 UTC, Jonathan M Davis wrote:
> On Friday, August 24, 2018 7:03:37 PM MDT Jonathan Marler via Digitalmars-d wrote:
>> > What uses does this actually have, I only see one example from the article and it is an oversimplistic example that effectively translates to either phobos being used or not being used. All the extra bloat this template would add to the already bloated if constraints is not welcome at all. The potential small benefit this might add isn't worth the unreadable mess it will turn code into.
>>
>> I can't help but laugh when you say "all the extra bloat this template would add..." :)  Sorry, I don't mean to insult but that really gave me a laugh.
>>
>> I hate to be blunt, but its clear from your response that you failed to grok the original post, which makes anything else I say pointless.  So I'm going to slowly back away from this one...step...step..step....*stp*....*s*...*
>
> It actually does add more template instantiations - and therefore arguably more bloat. It's just that because it more tightly ties importing to the use of the symbol, it reduces how many symbols you import unnecessarily, which can therefore reduce the bloat. So, if the symbol is used everywhere anyway, then from just adds bloat, whereas if it really is used in a more restricted way, then it reduces compilation times.
>
> The reason that I personally hate from's guts is because of how verbose it is. I'd _much_ rather see lazy importing be added like Walter likes to bring up from time to time. It should get us the reduction in compile times without all of the verbosity. As such, I would hate to see from in a place like object.d (or honestly, anywhere in druntime or Phobos), because then it might be used in Phobos all over the place, and I simply don't want to have to deal with it. It's bad enough that we're using scoped and local imports all over the place. They do help with tying imports to what uses them (and in the case of templated code can actually result in imports only happening when they need to), but it's so painfully verbose. I'd much rather not see the situation get that much worse by from being considered best practice instead of just fixing the compiler so that it's more efficient at importing and thus avoiding all of that extra verbosity in the code.
>
> - Jonathan M Davis

Would love to see lazy imports. I actually started implementing them earlier this year.

Just to make sure we're on the same page, normal imports (like import foo.bar;) cannot be lazy (see my notes at https://github.com/marler8997/dlangfeatures#lazy-imports).  There are 3 types of imports that can be lazy:

1. importing specific symbols: `import foo.bar : baz;`
2. static imports `static import foo.bar;`
3. alias imports: `import bar = foo.bar;`

So assuming we're on the same page, you mentioned that the `from` template is too verbose. I can see this point.  To measure this I consider the least verbose syntax for achieving the semantics of the `from` template.  The semantics can be stated as "take symbol X from module Y".  The shortest syntax possible would be the following:

<module-name><special-from-operator-character><identifier>

If we defined ':' as the special "from operator" then the following would be equivalent:

foo.bar:baz
from!"foo.bar".baz

Of course, reserving a special character for such an operator should require that the operation is common enough to warrant the reservation of a character.  Less common operators piggy back on keywords or combinations of special characters.  For example, you could make the syntax a bit more verbose by re-using the import keyword, i.e.

import(foo.bar).baz

but this example is only 1 character less than the `from` template.  In the end I don't know if these semantics warrant a special operator.  Maybe they warrant new syntax, however, the solution that requires the least amount of justification is adding a template to `object.d`.  The overhead will be virtually zero and only requires a few lines of code because it leverages existing D semantics.

In the end, these semantics are a great addition to D that makes lazy imports much easier to accommodate. I've had good success with `from` and think D would do well to implement these semantics in the core part of the language, whether with the template or with new syntax.

August 25, 2018
On Saturday, 25 August 2018 at 08:02:51 UTC, Jonathan Marler wrote:
>
> If we defined ':' as the special "from operator" then the following would be equivalent:
>
> foo.bar:baz
> from!"foo.bar".baz
>

I agree with almost everything you wrote, but I think it would have to be double ::

foo.bar::baz

as otherwise it would be ambiguous with labels, consider the case with a flat hierarchy.

foo:baz