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

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

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.

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.