On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
>
> This looks really clean for code modularity.
>
> import io = std.stdio : {writeln, write}, ...

What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;

The following code compiles and the imports are less confusing.

import io = std.stdio : writeln, write;
import std.stdio : writefln;

void main()
{
    io.write("foo");
    io.writeln("bar");
    writefln("My items are %(%s %).", [1,2,3]);
}

On 16-08-17 09:58, Gary Willoughby wrote:
> On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole wrote:
>> On 15/08/2017 2:59 AM, Johnson wrote:
>>> Not only that, but it requires adding more files to the command line.
>>>
>>> I currently have 3 import files to separate the gtk from gdk that and the only reason they exist is to combine them in to one named import ;/
>>>
>>>
>>> Doesn't seem like much but that's 3 extra files that don't really need to exist.
>>>
>>> Hopefully D already implements a way to do what I'm asking.
>>
>> Or instead of a new language feature, the gtk-d guys could have package files ;)
> 
> This! Just create a PR for Gtk-D to add packages.

Wouldn't that just move the problem?

You then get an package that imports gtk.Window and a other package that imports gdk.Window, and if you want to use both you still need to add a renamed import or a static import in your own file.

-- 
Mike Wey

On Wednesday, 16 August 2017 at 14:42:51 UTC, Mike Wey wrote:
>
> Wouldn't that just move the problem?
>
> You then get an package that imports gtk.Window and a other package that imports gdk.Window, and if you want to use both you still need to add a renamed import or a static import in your own file.

I don't know anything about gtkd, but I think he means something like below.

.\gtkd\package.d
module gtkd;
public import gtk;
public import gdk;
...etc

.\gtkd\gtk\package.d
module gtk;
public import gtk.Window;
...etc

.\gtkd\gdk\package.d
module gdk;
public import gdk.Window;
...etc

So you should then be able to do something like
import gtkd : functionThatDoesntOverlap;
import gtk = gtkd.gtk : functionThatDoesOverlap;
import gdk = gtkd.gdk : functionThatDoesOverlap;

A longer-term solution is for something like
import gtkd;
to only pull in the functions/structs/classes/etc that are actually used.

On Wednesday, 16 August 2017 at 17:14:49 UTC, jmh530 wrote:
> On Wednesday, 16 August 2017 at 14:42:51 UTC, Mike Wey wrote:
>>
>> Wouldn't that just move the problem?
>>
>> You then get an package that imports gtk.Window and a other package that imports gdk.Window, and if you want to use both you still need to add a renamed import or a static import in your own file.
>
> I don't know anything about gtkd, but I think he means something like below.
>
> .\gtkd\package.d
> module gtkd;
> public import gtk;
> public import gdk;
> ...etc
>
> .\gtkd\gtk\package.d
> module gtk;
> public import gtk.Window;
> ...etc
>
> .\gtkd\gdk\package.d
> module gdk;
> public import gdk.Window;
> ...etc
>
> So you should then be able to do something like
> import gtkd : functionThatDoesntOverlap;
> import gtk = gtkd.gtk : functionThatDoesOverlap;
> import gdk = gtkd.gdk : functionThatDoesOverlap;
>
> A longer-term solution is for something like
> import gtkd;
> to only pull in the functions/structs/classes/etc that are actually used.

Not really, I'm not doing selective imports.

I want to be able to use an import symbol that contains a whole crapload of imports. Which, the only way now is to create a separate file and public import all those imports one wants, then use that file and name it.

test.d

import _gtk = crapload;
import _gdk = crapload2;

crapload.d

public import gtk.TreeView;
public import gtk.Window;
....


crapload2.d

public import gdk.Window
....


But this requires creating files for every one group one wants.

It would be much nicer and easier, and it is easy if D added the language feature, to do

import _gtk = {gtk.TreeView, gtk.Window, ... }
import _gdk = {gdk.Window, ... }


The semantics are the same, it is just a rewrite rule basically... but all it really solves is not requiring extra files, which means keeping track of more junk.

It's not necessarily all that useful if one uses such imports all the time since it would bloat the files, But we could then add some wildcards:

import _gtk = gtk.*;
import _gdk = gdk.*;

which would be functionally the same but far less verbose.


But as it stands now, there is only one way to do that and that way is the most verbose and hardest to maintain... that really isn't acceptable when it is such an easy problem to fix and doesn't have any downside in implementing it.

On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
> On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole wrote:
> But then that only helps with one specific instance. D is full of language features, I do not see why everyone is so against them. Without them, D would be empty, nothing, and no one would use it. Adding language features should be see as something good, cause without them, we wouldn't get anywhere.

Its an important challenge of software development, and a number of articles out there about it.

https://www.google.com/search?q=the+cost+of+features&ie=utf-8&oe=utf-8

At first glance I wasn't finding anything which uniquely tackles compilers and languages.

Backwards compatibility isn't just for programming languages but can be more important.

A good UI can help a user with complexity. So does consistency. Adding a syntax for special meaning can be difficult to remember. My personal example is properties in C#. The syntax is straight forward and clean, but only recently have I been able to remember how to write one: ReturnType Name { get { return a; } set(value) { a = value; } }

As for your specific suggestion I think it would be nice at times but the complexity you haven't specified is how do deal with ambiguities if two modules provide the same symbol name.

D may have a number of features which C++ doesn't and visa versa, the complexity of the language for C++ to have those features means I work with D and not C++.

On Wednesday, 16 August 2017 at 18:38:23 UTC, Johnson Jones wrote:
>
> Not really, I'm not doing selective imports.
> [snip]

I'll preface this by saying that I think Jesse Phillips' point is a good one. The fact that you can already do it with the language (as you note about having a separate file full of imports) suggests that it doesn't have much chance of being part of the language.

Moving on to your point about wildcards, isn't that what package.d is for? I agree with the others that a lot of the pain would be reduced gtkd had package.d files set up.

Nevertheless, you also seem to want to be able to import a limited number of modules of a package and rename them one thing. Here's an example that I think illustrates your point with phobos:

import foo = std.algorithm.searching, std.algorithm.comparison;

void main()
{
    int[] a = [ 1, 2, 4, 3, 2, 5, 3, 2, 4 ];
    auto val = foo.count(a, 2);

    auto result = cmp("abc", "abc");
}

In this, you can have count named with foo, but you can't name cmp with foo. Of course, this isn't a problem with selective imports if there is a package.d file.

I found some interesting stuff on bugzilla related to this stuff
https://issues.dlang.org/show_bug.cgi?id=3603
https://issues.dlang.org/show_bug.cgi?id=12359

The first one has a recommendation to allow something like (and actually the initial suggestion has a version quite similar to yours):
import std.algorithm : searching, comparison;
which is currently not allowed, and would require some changes to how imports work to get it included in the language. However, it is very similar to what you are looking for (why I was so focused on selective imports), except that it does not have renaming, so you'd prefer something like
import foo = std.algorithm : searching, comparison;

The most significant difference between this and what you are suggesting is that your approach is probably more general. You could put anything between the { }, whereas this approach is a bit more limited.

It might the things a little easier to distinguish between a module import and a symbol import (like import std.algorithm :: searching, comparison : count, cmp; instead).

On Wednesday, 16 August 2017 at 19:05:54 UTC, Jesse Phillips wrote:
> On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
>> On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole wrote:
>> But then that only helps with one specific instance. D is full of language features, I do not see why everyone is so against them. Without them, D would be empty, nothing, and no one would use it. Adding language features should be see as something good, cause without them, we wouldn't get anywhere.
>
> Its an important challenge of software development, and a number of articles out there about it.
>
> https://www.google.com/search?q=the+cost+of+features&ie=utf-8&oe=utf-8
>
> At first glance I wasn't finding anything which uniquely tackles compilers and languages.
>
> Backwards compatibility isn't just for programming languages but can be more important.

Yes, but you are choosing a side, like most people. What about the cost of not advancing? How many man hours are wasted because someone won't implement feature because they "think" it will cause problems or because they are too lazy or won't get enough $$$ to do it?

Cost is not a one way street. When you don't do something it is doing something.  The whole problem with backwards compatibility is that it is based on ignorance.  When computers were first hitting the street, people were doing what I am suggesting, as that's all they could do. They screwed up a lot of things and wasted a lot of time. But then 50 years later people use that as an example, out of ignorance, to suggest that the same mistakes will occur. They completely neglect the fact that we wouldn't have what we have without all those mistakes either.

You can argue all you want, until you are purple in the face, but you cannot deny what I have said as being the truth and your arguments are baseless for the same reasons you claim mine is.

If one had to do things blindly and ignorantly, then yes, your arguments are sound. But by using your brain, learning from past mistakes, and moving forward to make progress, the issues can be minimized and a balanced can be made.

You cannot apply some general statement to all specific instances unless that statement is truly general. The backwards compatibility plague is based on ignorance, e.g., "We don't know what will be the ramifications of doing X so we will stick with the status quo!". That is a purely ignorant statement, that is, it is saying the same as "We are ignorant of what will happen if we do X so we won't do anything".

When you apply that logic to something that one doesn't have to be ignorant of, one is missing out on doing X and if X is good and done and improves things then it is a same and real ignorance wins again. No progress could ever be made if people didn't try things. If people try things intelligent then they minimize the problems that people like you are afraid of.

The best solution is a balance, wouldn't you agree?

When a "feature" offers no foreseeable issues(essentially nearly mathematically proved to be correct), then it shouldn't be looked as bad.

Again, as I pointed out, where would anything be if everyone had the mentality you state?

Would D have mixins? No, because who knows what kinda problems they could introduce in the language?

Would D have traits? No, because who knows what kinda problems they could introduce in the language?

etc...

etc..

etc..

etc..

And these cause problems not just in programming but in real life. No one wants to fix the problems, say, of America because who knows what kinda problems that will introduce... and given the track record of those that do the "problem fixing" we can be pretty sure of the outcome. But the problem is then not the problem fixing but those that fix the problems.

So, my point is that your argument is baseless and doesn't mean anything in the real world. It is a guide, a parable about the past and potentially the future, but people like you seem to like to make it a law, like gravity, which it is not. The sad fact is that it slows down real progress. One could make arguments about and if progress is a good thing or not in and of itself, but that is a different issue.


> A good UI can help a user with complexity. So does consistency. Adding a syntax for special meaning can be difficult to remember. My personal example is properties in C#. The syntax is straight forward and clean, but only recently have I been able to remember how to write one: ReturnType Name { get { return a; } set(value) { a = value; } }
> As for your specific suggestion I think it would be nice at times but the complexity you haven't specified is how do deal with ambiguities if two modules provide the same symbol name.
>
> D may have a number of features which C++ doesn't and visa versa, the complexity of the language for C++ to have those features means I work with D and not C++.

Then why are you so against adding features? That is what made D better than C++? Walter could have said to himself: "I'm not going to implement this feature that C++ doesn't have because it will break backwards compatibility", but he didn't. He tried something he thought would work because he reasoned it would. He didn't make a blind ignorant leap of faith that you are claiming is done anytime on wants to change something. It was based on experience and reason.

If you can find a specific reason why having such a notation is wrong then that would be a valid point, but generalities that don't apply is not helpful to the cause.

As far as your argument about ambiguities, that already exists, so it is not a problem with a new feature that extends what we have(it might inherit the problem, but it is not the cause of it). So, you should talk to walter about fixing that.

Do you understand? I have no issues with trying to defend the logic of something I say should be implemented, but you have to use proper logic itself instead of going with your gut and then creating baseless arguments against it. My main argument is that your two arguments: 1. Adding language features is bad. 2. The proposed idea creates the issue of ambiguity between identical symbols.

My logical argument against yours:

1. It is irrelevant and has nothing to do with anything. It may or may not be a valid argument in some sense but it is just a safety net/guide rail and by no means used to judge the validity of something. (one can't really reason anything from that argument because as much as it is right it is also wrong)

2. The ambiguity is, at it's root, part of D's module system design and part of D's problem, not the addition of something new on top of it. It cannot be fixed by not adding the addition and can't be fixed by choosing not to have it. So it too is irrelevant. If, it were to complicate the addition and make the addition have new problems, then that is a valid argument, but that is something you have to prove or show, which you haven't done.

So what I have ended up doing, rather than really defend my proposal for what it is and does, is have to correct your logic so that maybe we hopefully get somewhere. Note that none of this is an attack on you so don't get upset.  I simply would like to see this feature get implemented if it is a good idea, and if it not, then I don't want it to... but before we can determine that in a correct way, we first have to judge it for what it is rather than what it is not.

To even make it clearer: You mention your problem with C#'s properties. Your logic is that they shouldn't be implemented the way they are because it confuses you. That is not logical. I got the properties in 2ms because I realize it is just a definition. It is your ignorance(not a personal attack, we are all ignorant, but you are ignorant in that thing which causes you not to get it, which I wasn't... not because I'm better than you are smarter, but because I'm different) that prevents you from doing, not a defect in the properties. But instead of you finding that thing that makes it difficult for you to get, you want to slow everyone else down and make them use the same thing that works for you(which might not work for them)... but in any case, it is not logical, it is an argument based on ignorance.

In fact, I like they say C# does it and it makes complete sense to me... in fact, many things that C# does makes sense and the only reason I don't use it is because of the CLR/IR type of stuff that becomes a hindrance for many things I do. IMO C# is the best designed language I've ever seen out of about 30 languages I've used. (from assembly to pascal, to eel, to D)

But all that is irrelevant, the map is not the territory. My arguments are about the territory while yours, so far is about the map. Hopefully you can get that so we can move on to both at least be on the same topic.  BTW, I'm not in to maps because I think they are irrelevant made up BS and basically based on humans ignorance and are the real waste of time.  (And hopefully by maps you realize I'm not talking about real geographical maps)

On Wed, 16 Aug 2017 12:04:13 +0000, jmh530 wrote:
> 
> Well I knew that renamed imports were allowed, but I didn't realize you
> could do re-named selective imports (the " : writeln,
> write" part of it). I just double-checked and it worked. I don't recall
> it working in the past.
> 
> I see that there's an example in the spec, but it is a little more complicated than my example.

It doesn't quite work; it provides access to all names in the module, and
write/writeln is introduced into the global namespace; e.g., it's
interpreted as
`import io = std.stdio; import std.stdio : write, writeln;`

https://issues.dlang.org/show_bug.cgi?id=17756

On Thursday, 17 August 2017 at 11:40:11 UTC, rjframe wrote:
>
> It doesn't quite work; it provides access to all names in the module, and
> write/writeln is introduced into the global namespace; e.g., it's
> interpreted as
> `import io = std.stdio; import std.stdio : write, writeln;`
>
> https://issues.dlang.org/show_bug.cgi?id=17756

Yeah, I wouldn't have expected the following code to compile without error

import io = std.stdio : writeln;

void main()
{
    io.write("foo"); //expect error here, but none
    writeln("blah"); //expect error here, but none
    io.writeln("bar"); //no error
}

This was hard to keep reading, but ultimately enjoyable, because your arguments stem from interpretations and opinions of my point rather than the points I was making.

It is interesting that you feel I've claimed your point is baseless when I made no attempt to say such. Would help if I confirm that you do have valid arguments?

I provided a general response to a general question. You asked why people would be against features, which in your response has changed it to why people would be against features nearly mathematically proven to be correct.

I'm not saying we shouldn't look at the feature suggestion and way the pros and cons, but when you make a statement like "Adding language features should be see as something good, cause without them, we wouldn't get anywhere." it sounds more like your stating "Language features provide benefits, ignore the harm they cause it can't out weigh the harm it does."

On Wednesday, 16 August 2017 at 22:19:31 UTC, Johnson Jones wrote:
> Cost is not a one way street. When you don't do something it is doing something.  The whole problem with backwards compatibility is that it
> is based on ignorance.

But it isn't, your examples are all new, unestablished products which have no market to keep. There is a reason C++, Java, C#, C, Go, and countless other products keep backwards compatibility and it has nothing to do with ignorance. There is evidence even within the D community and Python, that breaking backwards compatibility does enough harm that it could be argued the change wasn't worth it (especially if done routinely).

>> D may have a number of features which C++ doesn't and visa versa, the complexity of the language for C++ to have those features means I work with D and not C++.
>
> Then why are you so against adding features? That is what made D better than C++?

I didn't say that D features made it better than C++. I did say that the complexity of C++ has kept me away from it.


> If you can find a specific reason why having such a notation is wrong then that would be a valid point, but generalities that don't apply is not helpful to the cause.

I did which you know since that is the very next thing you touch on.

> As far as your argument about ambiguities, that already exists, so it is not a problem with a new feature that extends what we have(it might inherit the problem, but it is not the cause of it). So, you should talk to walter about fixing that.

But ambiguities don't exist. If I name an import the compiler knows exactly which symbols I'm referring to. In fact named imports is one of the solutions Walter put in place to fix the ambiguity problem which you're now wanting to introduce into one of the approaches to solving the problem.

> My main argument is that your two arguments: 1. Adding language features is bad. 2. The proposed idea creates the issue of ambiguity between identical symbols.

But I didn't make the argument that "adding language features is bad." I made the argument that "adding language features has a cost." And to be more explicit, "it has a cost and you should be aware of the cost making the choices based on what the pros are with the costs and the weight of those pros and costs."

> 2. The ambiguity is, at it's root, part of D's module system design and part of D's problem, not the addition of something new on top of it. It cannot be fixed by not adding the addition and can't be fixed by choosing not to have it. So it too is irrelevant. If, it were to complicate the addition and make the addition have new problems, then that is a valid argument, but that is something you have to prove or show, which you haven't done.

D has facilities for handling ambiguity, it is at the root of D, part of D's module system design. This argument only shows you are not aware or understand D's approach to solving the problem.

> So what I have ended up doing, rather than really defend my proposal for what it is and does, is have to correct your logic so that maybe we hopefully get somewhere. Note that none of this is an attack on you so don't get upset.  I simply would like to see this feature get implemented if it is a good idea, and if it not, then I don't want it to... but before we can determine that in a correct way, we first have to judge it for what it is rather than what it is not.

Right, that is why I started with the general arguments, we have to be using the same decision making logic. Your view of features suggested that your approach to decision making differs from that of the top D contributors and a portion of the community. My logic could be wrong, but reflecting back to my first paragraph, you aren't going to be able to correct my logic if you don't understand what that logic is and instead go on a rampage of a view some fictitious person has in your head.