• Johnson (403/403) Aug 14 2017 Why can't we name multiple imports?
• Johnson (8/8) Aug 14 2017 Not only that, but it requires adding more files to the command
• rikki cattermole (3/13) Aug 14 2017 Or instead of a new language feature, the gtk-d guys could have package
• Johnson (7/22) Aug 15 2017 But then that only helps with one specific instance. D is full of
• jmh530 (32/40) Aug 15 2017 In the past, I've thought it would be convenient to have
• aberba (3/21) Aug 16 2017 This looks really clean for code modularity.
• Johnson (6/32) Aug 16 2017 Yes, and also
• jmh530 (12/14) Aug 16 2017 What does this add? A line like below would be confusing.
• aberba (8/24) Aug 17 2017 Its more like this:
• Johnson Jones (2/30) Aug 17 2017 Someone gets it! ;)
• Timon Gehr (10/42) Aug 17 2017 private struct oo{
• jmh530 (7/17) Aug 17 2017 Would not have thought to do that! Very cool.
• Timon Gehr (14/36) Aug 18 2017 It's one way to do it, but the compiler does not necessarily need to
• Johnson Jones (5/49) Aug 17 2017 Wow, that might solve the problem! A little more verbose but it
• Timon Gehr (40/59) Aug 18 2017 - It is more verbose. ;)
• jmh530 (2/13) Aug 18 2017 The static foreach is nice...doesn't depend on phobos.
• Olivier FAURE (5/10) Aug 18 2017 D newbie here: is there a non-negligible cost to creating a
• Joel Nilsson (3/9) Aug 16 2017 This is already in the language:
• jmh530 (7/21) Aug 16 2017 Well I knew that renamed imports were allowed, but I didn't
• rjframe (6/14) Aug 17 2017 It doesn't quite work; it provides access to all names in the module, an...
• jmh530 (10/17) Aug 17 2017 Yeah, I wouldn't have expected the following code to compile
• Jesse Phillips (20/27) Aug 16 2017 Its an important challenge of software development, and a number
• Johnson Jones (133/160) Aug 16 2017 Yes, but you are choosing a side, like most people. What about
• Jesse Phillips (49/84) Aug 17 2017 This was hard to keep reading, but ultimately enjoyable, because
• Gary Willoughby (3/18) Aug 16 2017 This! Just create a PR for Gtk-D to add packages.
• Mike Wey (7/24) Aug 16 2017 Wouldn't that just move the problem?
• jmh530 (24/29) Aug 16 2017 I don't know anything about gtkd, but I think he means something
• Johnson Jones (34/65) Aug 16 2017 Not really, I'm not doing selective imports.
• jmh530 (42/44) Aug 16 2017 I'll preface this by saying that I think Jesse Phillips' point is

Johnson <Johnson Johnson.com> writes:

Why can't we name multiple imports?

import x = a, b, c;

only a is part of x, b and c are not named!

this can cause some major problems(or the lack of a correctly 
solution).

For example,

gdk and gtk both have window. Both imports are needed and both 
define many public imports that create a huge spaghetti of mixed 
imports. In my code, even without gdk.Window imported, I am 
getting variables that are of that time, even though I import 
gtk.Window. I declare the variables as Window because it is 
automatically generated code and I do not know the actual 
import(well, unless I manually create a map from all the D 
imports to the glade types).

But I use gdk in just a few areas.

The only solution is to create a separate pulbic imports file 
that holds all the imports, but this creates extra files.

Why not something like

import x = {a,b,c};

?


It's a natural extension, makes sense, and should be easy to work 
out. Avoids having extra files for no other reason that to do the 
above and should easily solve the conflicts. What's nice about it 
is that we can even do

import x =
{
  a,
  b,
  c
};

which is like

public
{

}

 {att}
{

}


etc...




See what I mean:



public import gtk.AboutDialog;
public import gtk.AccelGroup;
public import gtk.AccelLabel;
public import gtk.AccelMap;
public import gtk.Accessible;
public import gtk.Action;
public import gtk.ActionableIF;
public import gtk.ActionableT;
public import gtk.ActionBar;
public import gtk.ActionGroup;
public import gtk.ActivatableIF;
public import gtk.ActivatableT;
public import gtk.Adjustment;
public import gtk.Alignment;
public import gtk.AppChooserButton;
public import gtk.AppChooserDialog;
public import gtk.AppChooserIF;
public import gtk.AppChooserT;
public import gtk.AppChooserWidget;
public import gtk.Application;
public import gtk.ApplicationWindow;
public import gtk.Arrow;
public import gtk.ArrowAccessible;
public import gtk.AspectFrame;
public import gtk.Assistant;
public import gtk.Bin;
public import gtk.BindingEntry;
public import gtk.BindingSet;
public import gtk.BooleanCellAccessible;
public import gtk.Border;
public import gtk.Box;
public import gtk.BuildableIF;
public import gtk.BuildableT;
public import gtk.Builder;
public import gtk.Button;
public import gtk.ButtonAccessible;
public import gtk.ButtonBox;
public import gtk.Calendar;
public import gtk.CellAccessible;
public import gtk.CellAccessibleParentIF;
public import gtk.CellAccessibleParentT;
public import gtk.CellArea;
public import gtk.CellAreaBox;
public import gtk.CellAreaClass;
public import gtk.CellAreaContext;
public import gtk.CellEditable;
public import gtk.CellEditableIF;
public import gtk.CellEditableT;
public import gtk.CellLayoutIF;
public import gtk.CellLayoutT;
public import gtk.CellRenderer;
public import gtk.CellRendererAccel;
public import gtk.CellRendererClass;
public import gtk.CellRendererCombo;
public import gtk.CellRendererPixbuf;
public import gtk.CellRendererProgress;
public import gtk.CellRendererSpin;
public import gtk.CellRendererSpinner;
public import gtk.CellRendererText;
public import gtk.CellRendererToggle;
public import gtk.CellView;
public import gtk.CheckButton;
public import gtk.CheckMenuItem;
public import gtk.CheckMenuItemAccessible;
public import gtk.Clipboard;
public import gtk.ColorButton;
public import gtk.ColorChooserDialog;
public import gtk.ColorChooserIF;
public import gtk.ColorChooserT;
public import gtk.ColorChooserWidget;
public import gtk.ColorSelection;
public import gtk.ColorSelectionDialog;
public import gtk.ComboBox;
public import gtk.ComboBoxAccessible;
public import gtk.ComboBoxText;
public import gtk.Container;
public import gtk.ContainerAccessible;
public import gtk.ContainerCellAccessible;
public import gtk.ContainerClass;
public import gtk.CssProvider;
public import gtk.CssSection;
public import gtk.Dialog;
public import gtk.DragAndDrop;
public import gtk.DrawingArea;
public import gtk.EditableIF;
public import gtk.EditableT;
public import gtk.Entry;
public import gtk.EntryAccessible;
public import gtk.EntryBuffer;
public import gtk.EntryCompletion;
public import gtk.EventBox;
public import gtk.EventController;
public import gtk.Expander;
public import gtk.ExpanderAccessible;
public import gtk.FileChooserButton;
public import gtk.FileChooserDialog;
public import gtk.FileChooserIF;
public import gtk.FileChooserNative;
public import gtk.FileChooserT;
public import gtk.FileChooserWidget;
public import gtk.FileFilter;
public import gtk.Fixed;
public import gtk.FlowBox;
public import gtk.FlowBoxAccessible;
public import gtk.FlowBoxChild;
public import gtk.FlowBoxChildAccessible;
public import gtk.FontButton;
public import gtk.FontChooserDialog;
public import gtk.FontChooserIF;
public import gtk.FontChooserT;
public import gtk.FontChooserWidget;
public import gtk.FontSelection;
public import gtk.FontSelectionDialog;
public import gtk.Frame;
public import gtk.FrameAccessible;
public import gtk.Gesture;
public import gtk.GestureDrag;
public import gtk.GestureLongPress;
public import gtk.GestureMultiPress;
public import gtk.GesturePan;
public import gtk.GestureRotate;
public import gtk.GestureSingle;
public import gtk.GestureSwipe;
public import gtk.GestureZoom;
public import gtk.GLArea;
public import gtk.Gradient;
public import gtk.Grid;
public import gtk.HandleBox;
public import gtk.HBox;
public import gtk.HButtonBox;
public import gtk.HeaderBar;
public import gtk.HPaned;
public import gtk.HScale;
public import gtk.HScrollbar;
public import gtk.HSeparator;
public import gtk.HSV;
public import gtk.IconFactory;
public import gtk.IconInfo;
public import gtk.IconSet;
public import gtk.IconSize;
public import gtk.IconSource;
public import gtk.IconTheme;
public import gtk.IconView;
public import gtk.IconViewAccessible;
public import gtk.Image;
public import gtk.ImageAccessible;
public import gtk.ImageCellAccessible;
public import gtk.ImageMenuItem;
public import gtk.IMContext;
public import gtk.IMContextSimple;
public import gtk.IMMulticontext;
public import gtk.InfoBar;
public import gtk.Invisible;
public import gtk.Label;
public import gtk.LabelAccessible;
public import gtk.Layout;
public import gtk.LevelBar;
public import gtk.LevelBarAccessible;
public import gtk.LinkButton;
public import gtk.LinkButtonAccessible;
public import gtk.ListBox;
public import gtk.ListBoxAccessible;
public import gtk.ListBoxRow;
public import gtk.ListBoxRowAccessible;
public import gtk.ListStore;
public import gtk.LockButton;
public import gtk.LockButtonAccessible;
public import gtk.Main;
public import gtk.MainWindow;
public import gtk.Menu;
public import gtk.MenuAccessible;
public import gtk.MenuBar;
public import gtk.MenuButton;
public import gtk.MenuButtonAccessible;
public import gtk.MenuItem;
public import gtk.MenuItemAccessible;
public import gtk.MenuShell;
public import gtk.MenuShellAccessible;
public import gtk.MenuToolButton;
public import gtk.MessageDialog;
public import gtk.Misc;
public import gtk.ModelButton;
public import gtk.MountOperation;
public import gtk.NativeDialog;
public import gtk.Notebook;
public import gtk.NotebookAccessible;
public import gtk.NotebookPageAccessible;
public import gtk.NumerableIcon;
public import gtk.OffscreenWindow;
public import gtk.OrientableIF;
public import gtk.OrientableT;
public import gtk.Overlay;
public import gtk.PadController;
public import gtk.PageSetup;
public import gtk.Paned;
public import gtk.PanedAccessible;
public import gtk.PaperSize;
public import gtk.PlacesSidebar;
public import gtk.Plug;
public import gtk.Popover;
public import gtk.PopoverAccessible;
public import gtk.PopoverMenu;
public import gtk.PopupBox;
public import gtk.PrintContext;
public import gtk.PrintOperation;
public import gtk.PrintOperationPreview;
public import gtk.PrintOperationPreviewIF;
public import gtk.PrintOperationPreviewT;
public import gtk.PrintSettings;
public import gtk.ProgressBar;
public import gtk.ProgressBarAccessible;
public import gtk.RadioAction;
public import gtk.RadioButton;
public import gtk.RadioButtonAccessible;
public import gtk.RadioMenuItem;
public import gtk.RadioMenuItemAccessible;
public import gtk.RadioToolButton;
public import gtk.Range;
public import gtk.RangeAccessible;
public import gtk.RcProperty;
public import gtk.RcStyle;
public import gtk.RecentAction;
public import gtk.RecentChooserDialog;
public import gtk.RecentChooserIF;
public import gtk.RecentChooserMenu;
public import gtk.RecentChooserT;
public import gtk.RecentChooserWidget;
public import gtk.RecentFilter;
public import gtk.RecentInfo;
public import gtk.RecentManager;
public import gtk.RendererCellAccessible;
public import gtk.Requisition;
public import gtk.Revealer;
public import gtk.Scale;
public import gtk.ScaleAccessible;
public import gtk.ScaleButton;
public import gtk.ScaleButtonAccessible;
public import gtk.ScrollableIF;
public import gtk.ScrollableT;
public import gtk.Scrollbar;
public import gtk.ScrolledWindow;
public import gtk.ScrolledWindowAccessible;
public import gtk.SearchBar;
public import gtk.SearchEntry;
public import gtk.SelectionData;
public import gtk.Separator;
public import gtk.SeparatorMenuItem;
public import gtk.SeparatorToolItem;
public import gtk.Settings;
public import gtk.ShortcutLabel;
public import gtk.ShortcutsGroup;
public import gtk.ShortcutsSection;
public import gtk.ShortcutsShortcut;
public import gtk.ShortcutsWindow;
public import gtk.SizeGroup;
public import gtk.Socket;
public import gtk.SpinButton;
public import gtk.SpinButtonAccessible;
public import gtk.Spinner;
public import gtk.SpinnerAccessible;
public import gtk.Stack;
public import gtk.StackAccessible;
public import gtk.StackSidebar;
public import gtk.StackSwitcher;
public import gtk.Statusbar;
public import gtk.StatusbarAccessible;
public import gtk.StatusIcon;
public import gtk.StockItem;
public import gtk.Style;
public import gtk.StyleContext;
public import gtk.StyleProperties;
public import gtk.StyleProviderIF;
public import gtk.StyleProviderT;
public import gtk.Switch;
public import gtk.SwitchAccessible;
public import gtk.SymbolicColor;
public import gtk.Table;
public import gtk.TargetEntry;
public import gtk.TargetList;
public import gtk.TearoffMenuItem;
public import gtk.Testing;
public import gtk.TextAttributes;
public import gtk.TextBuffer;
public import gtk.TextCellAccessible;
public import gtk.TextChildAnchor;
public import gtk.TextIter;
public import gtk.TextMark;
public import gtk.TextTag;
public import gtk.TextTagTable;
public import gtk.TextView;
public import gtk.TextViewAccessible;
public import gtk.ThemingEngine;
public import gtk.ToggleAction;
public import gtk.ToggleButton;
public import gtk.ToggleButtonAccessible;
public import gtk.ToggleToolButton;
public import gtk.Toolbar;
public import gtk.ToolButton;
public import gtk.ToolItem;
public import gtk.ToolItemGroup;
public import gtk.ToolPalette;
public import gtk.ToolShellIF;
public import gtk.ToolShellT;
public import gtk.Tooltip;
public import gtk.ToplevelAccessible;
public import gtk.TreeDragDestIF;
public import gtk.TreeDragDestT;
public import gtk.TreeDragSourceIF;
public import gtk.TreeDragSourceT;
public import gtk.TreeIter;
public import gtk.TreeIterError;
public import gtk.TreeModel;
public import gtk.TreeModelFilter;
public import gtk.TreeModelIF;
public import gtk.TreeModelSort;
public import gtk.TreeModelT;
public import gtk.TreeNode;
public import gtk.TreePath;
public import gtk.TreeRowReference;
public import gtk.TreeSelection;
public import gtk.TreeSortableIF;
public import gtk.TreeSortableT;
public import gtk.TreeStore;
public import gtk.TreeView;
public import gtk.TreeViewAccessible;
public import gtk.TreeViewColumn;
public import gtk.UIManager;
public import gtk.VBox;
public import gtk.VButtonBox;
public import gtk.Version;
public import gtk.Viewport;
public import gtk.VolumeButton;
public import gtk.VPaned;
public import gtk.VScale;
public import gtk.VScrollbar;
public import gtk.VSeparator;
public import gtk.Widget;
public import gtk.WidgetAccessible;
public import gtk.WidgetClass;
public import gtk.WidgetPath;
public import gtk.Window;
public import gtk.WindowAccessible;
public import gtk.WindowGroup;
public import gdkpixbuf.PixbufFormat;
public import gdkpixbuf.Pixdata;
public import gio.AsyncResultIF;
public import gio.Cancellable;
public import gio.IconIF;
public import gio.IconT;
public import gio.InputStream;
public import gio.LoadableIconIF;
public import gio.LoadableIconT;
public import gio.OutputStream;
public import glib.Bytes;
public import glib.ConstructionException;
public import glib.ErrorG;
public import glib.GException;
public import glib.HashTable;
public import glib.ListSG;
public import glib.Str;
public import gobject.ObjectG;
public import gtkc.gdkpixbuf;
public import gtkc.gdkpixbuftypes;


and that's just for gtk(well, mainly).

Johnson <Johnson Johnson.com> writes:

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.

rikki cattermole <rikki cattermole.co.nz> writes:

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 ;)

Johnson <Johnson Johnson.com> writes:

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 ;)

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.

jmh530 <john.michael.hall gmail.com> writes:

On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
 Or instead of a new language feature, the gtk-d guys could 
 have package files ;)

 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.

In the past, I've thought it would be convenient to have 
something like

import io = std.stdio : writeln, write;

and allow someone to write

io.write("foo");
io.writeln("bar");

though I don't know if that causes any kinds of problems to 
implement.

That being said, the code you refer to above probably could be 
simplified quite a bit with mixins. I just did a simple version, 
but I imagine it could be extended. It also might be even easier 
to accomplish when static foreach is in the language, that would 
you can just loop through the LowLevels to accomplish it. Some 
kind of hierarchy to the HighLevels/MidLevels/LowLevels would 
also need to be established.

import std.meta : AliasSeq;

alias LowLevels = AliasSeq!("writeln", "write");

template GenImport(string TopLevel, string MidLevel, string 
LowLevel)
{
     const char[] GenImport = "import " ~ TopLevel ~ "." ~ MidLevel
                                                        ~ " : " ~ 
LowLevel ~ ";";
}

mixin(GenImport!("std", "stdio", LowLevels[0]));
mixin(GenImport!("std", "stdio", LowLevels[1]));

void main()
{
     write("foo");
     writeln("bar");
}

aberba <karabutaworld gmail.com> writes:

On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
 On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
 Or instead of a new language feature, the gtk-d guys could 
 have package files ;)

 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.

 In the past, I've thought it would be convenient to have 
 something like

 import io = std.stdio : writeln, write;

 and allow someone to write

 io.write("foo");
 io.writeln("bar");

 though I don't know if that causes any kinds of problems to 
 implement.

This looks really clean for code modularity.

import io = std.stdio : {writeln, write}, ...

Johnson <Johnson Johnson.com> writes:

On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:
 On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
 On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
 Or instead of a new language feature, the gtk-d guys could 
 have package files ;)

 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.

 In the past, I've thought it would be convenient to have 
 something like

 import io = std.stdio : writeln, write;

 and allow someone to write

 io.write("foo");
 io.writeln("bar");

 though I don't know if that causes any kinds of problems to 
 implement.

 This looks really clean for code modularity.

 import io = std.stdio : {writeln, write}, ...

Yes, and also

import io = {std.stdio : {writeln, write}, ... }

which allows one to create their own "packages" inline. Group the 
best functionality they use often. Should be quick, efficient, 
and easy to implement. D should have this, where do I vote for it?

jmh530 <john.michael.hall gmail.com> writes:

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]);
}

aberba <karabutaworld gmail.com> writes:

On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
 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]);
 }

Its more like this:

import oo = {std.stdio : {writeln, write}, std.algorithm: 
{filter, map}, …};

oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);

Johnson Jones <JJ Dynomite.com> writes:

On Thursday, 17 August 2017 at 21:03:33 UTC, aberba wrote:
 On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
 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]);
 }

 Its more like this:

 import oo = {std.stdio : {writeln, write}, std.algorithm: 
 {filter, map}, …};

 oo.writeln();
 oo.write();
 oo.filter(...);
 oo.map(...);

Someone gets it! ;)

Timon Gehr <timon.gehr gmx.ch> writes:

On 17.08.2017 23:03, aberba wrote:
 On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
 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]);
 }

 
 Its more like this:
 
 import oo = {std.stdio : {writeln, write}, std.algorithm: {filter, map}, 
 …};
 
 oo.writeln();
 oo.write();
 oo.filter(...);
 oo.map(...);
 

private struct oo{
     import std.stdio: writeln, write;
     import std.algorithm: filter, map;
     // …
}

void main(){
     oo.write("result: ");
     oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}

jmh530 <john.michael.hall gmail.com> writes:

On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
 private struct oo{
     import std.stdio: writeln, write;
     import std.algorithm: filter, map;
     // …
 }

 void main(){
     oo.write("result: ");
     
 oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
 }

Would not have thought to do that! Very cool.

Quick follow up: is there a reason this why renamed selective 
imports don't work this way? As in the bug from the link below we 
discussed above

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

Re-writing the import like this seems like the perfect bug fix?

Timon Gehr <timon.gehr gmx.ch> writes:

On 18.08.2017 01:25, jmh530 wrote:
 On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
 private struct oo{
     import std.stdio: writeln, write;
     import std.algorithm: filter, map;
     // …
 }

 void main(){
     oo.write("result: ");
 oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
 }

 
 Would not have thought to do that! Very cool.
 
 Quick follow up: is there a reason this why renamed selective imports 
 don't work this way?

I don't think there is. (I.e. I think it is indeed a bug.)

 As in the bug from the link below we discussed above
 
 https://issues.dlang.org/show_bug.cgi?id=17756
 
 Re-writing the import like this seems like the perfect bug fix?

It's one way to do it, but the compiler does not necessarily need to 
generate a new type. Note that unfortunately, renamed imports don't 
overload, so this would not work even with the fixed bug:

import oo=std.stdio: writeln, write;
import oo=std.algorithm: filter, map; // error: oo redefined

void main(){
     oo.write("result: ");
     oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}

I think this is working as designed, but IMO they should just overload 
(using distinct overload sets so the semantics is similar to the case 
when using the struct), as should named mixins.

Johnson Jones <JJ Dynomite.com> writes:

On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:
 On 17.08.2017 23:03, aberba wrote:
 On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:
 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]);
 }

 
 Its more like this:
 
 import oo = {std.stdio : {writeln, write}, std.algorithm: 
 {filter, map}, …};
 
 oo.writeln();
 oo.write();
 oo.filter(...);
 oo.map(...);
 

 private struct oo{
     import std.stdio: writeln, write;
     import std.algorithm: filter, map;
     // …
 }

 void main(){
     oo.write("result: ");
     
 oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
 }

Wow, that might solve the problem! A little more verbose but it 
does combine everything.

Any downsides?

Thanks.

Timon Gehr <timon.gehr gmx.ch> writes:

On 18.08.2017 03:11, Johnson Jones wrote:

 private struct oo{
     import std.stdio: writeln, write;
     import std.algorithm: filter, map;
     // …
 }

 void main(){
     oo.write("result: ");
 oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
 }

 
 Wow, that might solve the problem! A little more verbose but it does 
 combine everything.
 
 Any downsides?
 

- It is more verbose. ;)


- IMAO it shouldn't even work without 'public' on the imports. (So if 
someone decides to fix that it might break and become more verbose.)


- It introduces a new type that would not really be necessary. This is 
avoidable, at the cost of a little more verbosity:


private template Imports(){
     public import std.stdio: writeln, write;
     public import std.algorithm: filter, map;
}
private alias oo = Imports!();

void main(){
     oo.write("result: ");
     oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}


The pattern can be abstracted into a utility template:

---
module util;

// ...

template Imports(T...){
     import std.string,std.algorithm;
     mixin([T].map!(x=>"public import "~x~";").join);
     // or, starting from DMD 2.076, you could use static foreach instead:
     // static foreach(x;T) mixin("public import "~x~";");
}

// ...

---

---
module main;

import util: Imports;
private alias oo = Imports!(
     `std.stdio: writeln, write`,
     `std.algorithm: filter, map`
);

void main(){
     oo.write("result: ");
     oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));	
}
---


 Thanks.

np.

jmh530 <john.michael.hall gmail.com> writes:

On Friday, 18 August 2017 at 09:18:42 UTC, Timon Gehr wrote:
 ---
 module util;

 // ...

 template Imports(T...){
     import std.string,std.algorithm;
     mixin([T].map!(x=>"public import "~x~";").join);
     // or, starting from DMD 2.076, you could use static 
 foreach instead:
     // static foreach(x;T) mixin("public import "~x~";");
 }

 // ...

The static foreach is nice...doesn't depend on phobos.

Olivier FAURE <olivier.faure epitech.eu> writes:

On Friday, 18 August 2017 at 09:18:42 UTC, Timon Gehr wrote:
 Any downsides?
 

 ...

 - It introduces a new type that would not really be necessary. 
 This is avoidable, at the cost of a little more verbosity:

D newbie here: is there a non-negligible cost to creating a 
stateless struct type?

Also, since the struct is private and only used for its aliases, 
if there a chance the compiler might elide those costs?

Joel Nilsson <nilserikjoel96 hotmail.com> writes:

On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
 In the past, I've thought it would be convenient to have 
 something like

 import io = std.stdio : writeln, write;

 and allow someone to write

 io.write("foo");
 io.writeln("bar");

This is already in the language: 
http://dlang.org/spec/module.html#renamed_imports

jmh530 <john.michael.hall gmail.com> writes:

On Wednesday, 16 August 2017 at 10:12:01 UTC, Joel Nilsson wrote:
 On Tuesday, 15 August 2017 at 21:12:24 UTC, jmh530 wrote:
 In the past, I've thought it would be convenient to have 
 something like

 import io = std.stdio : writeln, write;

 and allow someone to write

 io.write("foo");
 io.writeln("bar");

 This is already in the language: 
 http://dlang.org/spec/module.html#renamed_imports

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.

rjframe <dlang ryanjframe.com> writes:

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

jmh530 <john.michael.hall gmail.com> writes:

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
}

Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:

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. 

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++.

Johnson Jones <JJ Dynomite.com> writes:

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 

 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.


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.



only reason I don't use it is because of the CLR/IR type of stuff 

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)

Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:

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 

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.

Gary Willoughby <dev nomad.so> writes:

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.

Mike Wey <mike-wey example.com> writes:

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

jmh530 <john.michael.hall gmail.com> writes:

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.

Johnson Jones <JJ Dynomite.com> writes:

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.

jmh530 <john.michael.hall gmail.com> writes:

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).