Embrace the from template?

[Jonathan Marler]

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.