syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 14 02:50:18 PST 2017


On Tuesday, February 14, 2017 10:55:51 Jacob Carlborg via Digitalmars-d 
wrote:
> On 2017-02-14 04:49, Timothee Cour via Digitalmars-d wrote:
> > What about allowing syntax sugar as an alternative to relying on the new
> > `from/Module` inline import idiom:
> >
> > ```
> > void fun(T)(std.stdio::File input, T value) if
> > (std.traits::isIntegral!T) {...}
> > ```
> >
> > instead of:
> >
> > ```
> > void fun(T)(Module!"std.stdio".File input, T value) if
> > (Module!"std.traits".isIntegral!T) {...}
> > ```
> >
> > Rationale:
> >
> > * this reads much better (less noise); same as `=>` syntax for lambdas
> >
> > * this is expected to be a very common pattern, so might as well make it
> > as simple as possible
>
> Why? It looks awful. The signatures we already have in Phobos is quite
> ridiculous, this will not improve. Isn't this and the whole idea of DIP
> 1005 just a workaround for the compiler not lazily analyzing the symbols.

Mostly, but not just that. By having something like DIP 1005, all of the
imports required for the function can be associated with the function. So,
people reading the code then have an easier time figuring out where the
symbols come from, and it could be that the compiler could take advantage of
that somehow. It does seem though that the main motivator for DIP 1005 is
the fact that we don't have lazy imports, and Walter has talked before about
wanting to do fully lazy imports. So, I expect that we'll get them at some
point, at which point, any performance improvements from DIP 1005 or the
from template would likely become moot, and the only benefit left is
essentially documentation.

Personally, I might use DIP 1005 in some cases if we end up with it, but I
won't use from unless I'm forced to. As cool as it is that we can do it with
the language as-is, it's far too verbose and far too ugly. As it is, I'm
getting sick of doing local and selective imports all over the place like
everyone seems to think is best practice. I understand why they're
theoretically good, but it results in longer code, and it gets very tedious
to have to try and maintain the list of symbols that are imported instead of
just importing the modules you need at the top of the module and forgetting
about it. Doing what DIP 1005 and from push for just takes that pain to
another level. It might be worth it in code used by tons of people (like
Phobos), but for most code, I'm increasingly of the opinion that it's not
worth it. And having proper lazy imports would largely fix the compilation
cost of simply importing modules. So, I'm very much in favor of getting lazy
imports, and while I do see _some_ value in documenting where stuff comes
from via something like DIP 1005, I seriosuly question that it's worth the
extra pain. And when you have all of those function attributes to worry
about on top of that... It's just getting to be too much.

- Jonathan M Davis



More information about the Digitalmars-d mailing list