www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Embrace the from template?

reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Aug 23 2018
next sibling parent reply aliak <something something.com> writes:
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.


One of the first things I do after a dub init is create a file 
called internal.d with the from template in it. My only gripe 
about this template is it's "autocompletion-able-ness" in IDEs 
and if that can be handled.

I would not want it globally imported though, "from" is quite 
popular as an identifier and D doesn't let you use keywords as 
identifiers.

Cheers,
- Ali
Aug 24 2018
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 24 August 2018 at 10:58:29 UTC, aliak 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.


 One of the first things I do after a dub init is create a file 
 called internal.d with the from template in it. My only gripe 
 about this template is it's "autocompletion-able-ness" in IDEs 
 and if that can be handled.

 I would not want it globally imported though, "from" is quite 
 popular as an identifier and D doesn't let you use keywords as 
 identifiers.

 Cheers,
 - Ali


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.
Aug 24 2018
parent aliak <something something.com> writes:
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.
Aug 24 2018
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 24 August 2018 at 10:58:29 UTC, aliak 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. [...]
 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.


 One of the first things I do after a dub init is create a file 
 called internal.d with the from template in it. My only gripe 
 about this template is it's "autocompletion-able-ness" in IDEs 
 and if that can be handled.

 [...]


Assuming you use DCD, even if CTFE is not handled it would be 
possible to detect the signature and to do with "from" what's 
usually done with an import.
But it needs to be in a well defined module. You can open an 
issue in the repository asking for this and the feature will be 
added once the D-runtime PR merged.
Aug 25 2018
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote:


 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.


I don't know.  It's not a bad idea, but I don't consider it a 
major enabler either.  It's easy enough to just cut and paste it 
to one's arsenal, though I understand the inconvenience of having 
to maintain it in multiple projects.

One thing to consider is `from` is a *very* general word, and if 
it's placed in object.d it might cause naming conflicts.  I'd 
like the name to be more specific, but I know how such naming 
discussions tend to go.

Mike
Aug 24 2018
prev sibling next sibling parent reply Anton Fediushin <fediushin.anton yandex.com> writes:
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.


There's no reason to mess with `object.d` or add it to phobos. 
Just make a dub package and use it!

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/


Have a good day and don't overthink simple things,
Anton
Aug 24 2018
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin wrote:

 On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler 
 wrote:

 [...]


 There's no reason to mess with `object.d` or add it to phobos. 
 Just make a dub package and use it!

 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/


 Have a good day and don't overthink simple things,
 Anton


It's good to see there are people who are still optimistic about 
dub. I remember that same feeling so many years ago :)
Aug 24 2018
parent Anton Fediushin <fediushin.anton yandex.com> writes:
On Friday, 24 August 2018 at 13:48:09 UTC, Jonathan Marler wrote:

 On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin 
 wrote:

 On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler 
 wrote:

 [...]


 There's no reason to mess with `object.d` or add it to phobos. 
 Just make a dub package and use it!

 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/


 Have a good day and don't overthink simple things,
 Anton


 It's good to see there are people who are still optimistic 
 about dub. I remember that same feeling so many years ago :)


It got better, I think. It's far from being perfect but there's 
no way I'm building something like vibe-d manually or with 
*shivers* make.
Aug 24 2018
prev sibling parent reply Daniel N <no public.email> writes:
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
Aug 24 2018
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote:I don't 
use dub myself.
On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote:

 FYI Andrei has an open pull request:
 https://github.com/dlang/druntime/pull/1756


Oh well I guess great minds think alike :)  Too bad it's been 
stalled due to a bug. I'd gladly fix it but alas, my pull 
requests are ignored :(
Aug 24 2018
parent reply Seb <seb wilzba.ch> writes:
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.
Aug 24 2018
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Aug 24 2018
parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Aug 24 2018
prev sibling next sibling parent Anton Fediushin <fediushin.anton yandex.com> writes:
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


Thanks. This PR is year and a half old so I'm not sure if we'll 
see it merged this year at all. Fingers crossed.
Aug 24 2018
prev sibling parent Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
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.
Aug 24 2018
prev sibling parent reply tide <tide tide.tide> writes:
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.
Aug 24 2018
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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*...*
Aug 24 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Aug 24 2018
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Aug 25 2018
next sibling parent Daniel N <no public.email> writes:
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
Aug 25 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, August 25, 2018 2:02:51 AM MDT Jonathan Marler via Digitalmars-
d wrote:

 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.


Honestly, I don't want to be doing _anything_ like from with _any_ syntax.
It's not just a question of from itself being too long. It's the fact that
you're having to use the import path all over the place. I don't want to be
putting anything other than the actual symbol name in the function's
signature. IMHO, the ideal is to be able to just put

import blah;

at the top and then just use whatever was in module blah without having to
repeat it everywhere. On the whole, I find this whole trend of constantly
having to list exactly which symbols you're importing / exactly where a
symbol comes from instead of just being able to just slap an import at the
top and use the symbols te be way, way too verbose and a general maintenance
problem. Yes, it can make it easier to figure out where a symbol came from
when reading the code, and sometimes, it can improve compilation speed, but
it means having to add a ton of extra code in comparison to just importing
the module once, and you have to maintain all of that, constantly tweaking
import statements, because you've changed which symbols you've used. It's
like a cancer except that it comes with just enough benefits that some folks
keep pushing for it.

from is not the entire problem, but IMHO, it's definitely the straw that
breaks the camel's back. It's taking all of this specificity way too far. I
don't want to have to write or read code that's constantly putting import
information everywhere. Sadly, it makes C's #include mess start looking
desirable in comparison.

- Jonathan M Davis
Aug 25 2018
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 25 August 2018 at 09:30:27 UTC, Jonathan M Davis 
wrote:

 On Saturday, August 25, 2018 2:02:51 AM MDT Jonathan Marler via 
 Digitalmars- d wrote:

 [...]


 Honestly, I don't want to be doing _anything_ like from with 
 _any_ syntax. It's not just a question of from itself being too 
 long. It's the fact that you're having to use the import path 
 all over the place. I don't want to be putting anything other 
 than the actual symbol name in the function's signature. IMHO, 
 the ideal is to be able to just put

 import blah;

 at the top and then just use whatever was in module blah 
 without having to repeat it everywhere. On the whole, I find 
 this whole trend of constantly having to list exactly which 
 symbols you're importing / exactly where a symbol comes from 
 instead of just being able to just slap an import at the top 
 and use the symbols te be way, way too verbose and a general 
 maintenance problem. Yes, it can make it easier to figure out 
 where a symbol came from when reading the code, and sometimes, 
 it can improve compilation speed, but it means having to add a 
 ton of extra code in comparison to just importing the module 
 once, and you have to maintain all of that, constantly tweaking 
 import statements, because you've changed which symbols you've 
 used. It's like a cancer except that it comes with just enough 
 benefits that some folks keep pushing for it.

 from is not the entire problem, but IMHO, it's definitely the 
 straw that breaks the camel's back. It's taking all of this 
 specificity way too far. I don't want to have to write or read 
 code that's constantly putting import information everywhere. 
 Sadly, it makes C's #include mess start looking desirable in 
 comparison.

 - Jonathan M Davis


I can certainly understand this sentiment.  I personally use both 
styles depending no the situation.  Each has their pros and cons, 
it's verbosity vs specificity.  At least with D I can define the 
`from` template in my own projects even if the core language 
doesn't add it.  I'm just of the opinion that it's useful enough 
to warrant additions to the core language in some form to make it 
easier to use.  Thanks for chiming in.
Aug 25 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, August 25, 2018 3:30:27 AM MDT Jonathan M Davis via 
Digitalmars-d wrote:

 from is not the entire problem, but IMHO, it's definitely the straw that
 breaks the camel's back. It's taking all of this specificity way too far.
 I don't want to have to write or read code that's constantly putting
 import information everywhere. Sadly, it makes C's #include mess start
 looking desirable in comparison.


And honestly, once you also factor in stuff like the ever-increasing number
of attributes that we have to worry about for functions, D in general is
getting pretty ridiculously verbose.

- Jonathan M Davis
Aug 25 2018