[Issue 3603] Allow selective import syntax to import several modules from a package

[via Digitalmars-d-bugs]

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

John Hall  changed:

   What|Removed |Added

 CC||john.michael.h...@gmail.com

--- Comment #4 from John Hall  ---
Multiple named imports also discussed here:
https://forum.dlang.org/thread/hashhduapewjhqmwh...@forum.dlang.org



With respect to:

> import really.very.deeply.nested.package: module1, module2, module3;

or

> import std: stdio, algorithm, range, array;

consider:

-[ foo\package.d ]-
module foo;
public import foo.bar;
public import foo.baz;
public import foo.bazinga;

-[ foo\bar.d ]-
module foo.bar;
void bar() { };

-[ foo\baz.d ]-
module foo.baz;
void baz() { };

-[ foo\bazinga.d ]-
module foo.bazinga;
void bazinga() { };



Under your suggestion, if you:

import foo : bar, baz;

how does the compiler know to import the functions or the modules? Under the
current approach, it's not an issue since the selective import only brings in
the symbols.



I think the alternative would be to introduce a new syntax for selective module
imports, where

import foo :: bar, baz;

causes the modules bar and baz to be imported, but not bazinga. This would be
equivalent to

import foo.bar;
import foo.baz;

Static imports should follow a similar pattern.

It gets a little more complicated with re-named imports where something like

import barbaz = foo :: bar, baz;

may be possible. This functionality currently requires a more challenging
workaround, discussed in the above thread, as it is an error to write

import barbaz = foo.bar;
import barbaz = foo.baz;

because barbaz is assigned to two things.

This functionality may also mix with the current functionality for selective
imports, such as

import foo :: bar, baz : bar, baz;

though this depends on the implementation details, for instance, the following
would not compile

import foo.bar : bar, baz;
import foo.baz : bar, baz;

so the compiler would need to do something like search foo.bar for either bar
or baz and only import them if they are there, cross off what is found, then
search foo.baz for the remainder, and give an error if something isn't found.

In addition, one could have a re-named version

import barbaz = foo :: bar, baz : bar, baz;

which should follow from getting the above to work.

Finally, one point I didn't address specifically was about the deeply nested
modules that the OP refers to. The OPs example of

> import really.very.deeply.nested.package: module1, module2, module3;

would become 

> import really.very.deeply.nested.package :: module1, module2, module3;

However, it also would be convenient to be able to write 

> import really :: module1, module2, module3;

assuming the module names are unique. I am not sure if this is possible.

--

Re: How to specify a template that uses unqualified type, like any normal function

[Dominikus Dittes Scherkl via Digitalmars-d-learn]

On Tuesday, 15 August 2017 at 14:24:57 UTC, Steven Schveighoffer 
wrote:


What IFTI would need is a mechanism to change the parameter 
types to mutable similar to how you can do this:


foo(T)(const(T) t);

This now generates one function for int, const(int), 
immutable(int), and t is const within the function.


What we need is something like:

foo(T)(mutable(T) t) // fictitious type constructor, doesn't 
work.

In fact, that was the first thing I tried, but it doesn't exist.
Would be a pretty useful addition anyway, because it would allow 
(some time in the far future) to move from mutable by default to 
immutable by default.


Or a more general mechanism to modify IFTI when it is deciding 
the parameters to use based on the call.


In my case, I've run into this when I'm trying to use short or 
ubyte, and someone uses literals:


void foo(short s) { ...}

void fooT(T)(T t) { foo(s); }

foo(1); // ok
fooT(1); // error.

It would be nice if there was some way to tell IFTI to infer T 
as short in this case.

Yes, that would also be very nice. And would be easy to solve:
A literal should always be assumed to be the smallest type that 
can represent it, not int. May be, if compatibilitpy to old bad C 
is really still so important, integer propagation can be done 
later on if neccessary, but don't start out with int. That's just 
so oldschool and most of the time just annoying and there's no 
technical reason to do so.

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[crimaniak via Digitalmars-d-learn]

On Monday, 14 August 2017 at 03:59:48 UTC, Jonathan M Davis wrote:

The way to handle shared is to protect the section of code 
that's using the shared object with either a mutex or 
synchronized block, and then you cast away shared from the 
object within that section and operate on it as thread-local. 
When you're done, you make sure that you don't have any 
thread-local references to the data, and you release the mutex 
or exit the synchronized block. e.g. something like


shared T sharedObj = getSharedObj();

synchronized(mutex)
{
T nonSharedObj = cast(T)sharedObject

// do stuff...

// make sure that no references to nonSharedObj have escaped
}


Casting objects just to work with it every time is so bad style 
for me that I even didn't consider such possibility. In fact, I 
did make something like this but with __gshared both object and 
mutex. I think I need to review this part of site engine and my 
programming habits too.
I wonder if it possible and usable to make some template to 
support this pattern, where we give mutex(es), shared object(s) 
and delegate to operate with objects as non-shared.

Re: Automatic function body writing howto?

[Meta via Digitalmars-d-learn]

It's hard to tell offhand but I would recommend that you extract 
the inner string into a function that generates that string, 
allowing you to print out the finished product before mixing it 
in.

Re: New Features [was Named multi-imports]

[Johnson Jones via Digitalmars-d]

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=utf-8=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 

Automatic function body writing howto?

[Oleg B via Digitalmars-d-learn]

I want declare only signature of function and build body code by 
CTFE.


module mdl;
import std.stdio;
import std.traits;
import std.string;

enum autofnc;

@autofnc
{
int foo(int);
int bar(int);
}

void main()
{
writeln(foo(12));
}

mixin cfuncR;

mixin template cfuncR()
{
mixin impl!(getSymbolsByUDA!(mdl, autofnc));

mixin template impl(funcs...)
{
static if (funcs.length == 1)
{
mixin("pragma(msg, typeof(%1$s)); // !!! here I get 
_error_
			ReturnType!%1$s %1$s(Parameters!%1$s vals) { return vals[0] * 
2; }".format(__traits(identifier, funcs[0]));

}
else
{
mixin impl!(funcs[0..$/2]);
mixin impl!(funcs[$/2..$]);
}
}
}

I get this output:

/usr/include/dmd/phobos/std/traits.d-mixin-7671(7671): 
Deprecation: mdl.object is not visible from module traits
/usr/include/dmd/phobos/std/traits.d-mixin-7671(7671): 
Deprecation: mdl.std is not visible from module traits
mdl.d-mixin-29(30): Error: template instance 
std.traits.ReturnType!(foo) does not match template declaration 
ReturnType(func...) if (func.length == 1 && isCallable!func)
mdl.d-mixin-29(30): Error: template instance Parameters!foo does 
not match template declaration Parameters(func...) if 
(func.length == 1 && isCallable!func)

_error_
mdl.d(34): Error: mixin mdl.cfuncR!().impl!(foo, bar).impl!(foo) 
error instantiating
mdl.d-mixin-29(30): Error: template instance 
std.traits.ReturnType!(bar) does not match template declaration 
ReturnType(func...) if (func.length == 1 && isCallable!func)
mdl.d-mixin-29(30): Error: template instance Parameters!bar does 
not match template declaration Parameters(func...) if 
(func.length == 1 && isCallable!func)

_error_
mdl.d(35): Error: mixin mdl.cfuncR!().impl!(foo, bar).impl!(bar) 
error instantiating
mdl.d(23): Error: mixin mdl.cfuncR!().impl!(foo, bar) error 
instantiating

mdl.d(19): Error: mixin mdl.cfuncR!() error instantiating
Failed: ["dmd", "-v", "-o-", "mdl.d", "-I."]

I think 'template instance std.traits.ReturnType!(foo) does not 
match template declaration' because 'foo' is '_error_' on it's 
instancing moment. But I don't understand why 'foo' is '_error_'.


But if I replace '%1$s' in building function name to '_%1$s' 
pragma(msg, foo) works normal and compiler behavior is 
predictable (defined '_foo', but 'foo' has no body and can't 
linked):


/usr/include/dmd/phobos/std/traits.d-mixin-7671(7671): 
Deprecation: mdl.object is not visible from module traits
/usr/include/dmd/phobos/std/traits.d-mixin-7671(7671): 
Deprecation: mdl.std is not visible from module traits

int(int)
int(int)
/usr/include/dmd/phobos/std/traits.d-mixin-7671(7671): 
Deprecation: mdl.object is not visible from module traits
/usr/include/dmd/phobos/std/traits.d-mixin-7671(7671): 
Deprecation: mdl.std is not visible from module traits

int(int)
int(int)
/tmp/.rdmd-1000/rdmd-mdl.d-9F3ADBC813DCE463C0EFA2CA038B009E/objs/mdl.o: In 
function `_Dmain':
mdl.d:(.text._Dmain+0xa): undefined reference to `_D3mdl3fooFiZi'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1

But if I wrote this code by hands:

ReturnType!foo foo(Parameters!foo vals) { return vals[0] * 2; }
ReturnType!bar bar(Parameters!bar vals) { return vals[0] * 2; }

all works fine!!

What am I doing wrong?

dmd 2.074
ldc 1.3.0 (main compiler, because can cross compile to arm)

In DUB, how do I conditionally compile code based on optional dependencies?

[Daniel Kozak via Digitalmars-d-learn]

There is a question on SO: 
https://stackoverflow.com/questions/45697469/in-dub-how-do-i-conditionally-compile-code-based-on-optional-dependencies


I have found the answer, but I am interesting is there any doc 
about this?

Re: Named multi-imports

[jmh530 via Digitalmars-d]

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

Re: C++17 Init statement for if/switch

[Sad panda via Digitalmars-d]

On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher 
wrote:

On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
That is correct. After a while it gets tiring to see a 
neverending stream of complexity added to the language while 
things that would actually help (like IDE support) do not get 
any attention.


+1, though I'd go for bug-fixing over IDEs.


I like that.  Feature freeze D until *all* bug reports are 
closed.
While that would mean no more features for several years, I 
think it would benefit the language in the long run, both 
internally (less discussions about incorrect behavior) and 
externally (D is a mature and stable language).


You'd see a fork.

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Arek via Digitalmars-d-learn]

On Tuesday, 15 August 2017 at 21:54:23 UTC, Steven Schveighoffer 
wrote:

On 8/15/17 5:27 PM, Arek wrote:

On Tuesday, 15 August 2017 at 10:37:08 UTC, Kagamin wrote:

Well, no wrapper is actually needed here:


[...]
The issue is that send cannot handle shared value types due to 
a bug in the implementation. In essence, there is no reason to 
send a shared A -- it's an unrelated copy and not actually 
shared.


You can send a shared reference to an A just fine:

static shared A a;

send(tid, ); // works

You *should* be able to send a shared(A). There is no reason to 
disallow it. But again, it's not super useful.


Yes, I absolutely agree. The object may be shared due to other 
requirements and there is no reason to reject 'share' qualifier 
what I want to send/receive it.



This very simple code also doesn't compile:

shared struct S
{
 int i;

 ~this()
 {
 }
}

void main()
{
 shared s = shared S();
}

In general, shared structs with postblit and destructor make 
problems.


postblit should work.

It does look like destructors are a problem. It appears the 
compiler attempts to call the destructor while unshared.


-Steve


But I have no idea how and when the object loses its shared 
nature. Yes, it looks like a bug in dmd. ldc 1.3 doesn't complain 
in this case.


Arek

Re: Debugging Visual D using Visual D

[Johnson Jones via Digitalmars-d-debugger]

On Wednesday, 16 August 2017 at 17:54:39 UTC, Rainer Schuetze 
wrote:



On 16.08.2017 16:48, Johnson wrote:
On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze 
wrote:



On 16.08.2017 08:32, Rainer Schuetze wrote:



On 16.08.2017 04:49, Johnson wrote:
 VisualD.dllC:\Program Files 
(x86)\VisualD\Debug\VisualD.dll N/AYesSymbols 
loaded.
   C:\Program Files (x86)\VisualD\Debug\VisualD.pdb229 
0.45.1-rc212/31/1969 7:00 PM13FB-143C* 
[8972] devenv.exe
 VisualD.dllC:\Program Files 
(x86)\VisualD\VisualD.dllN/A YesCannot find or open 
the PDB file.2710.45.1-rc2 12/31/1969 7:00 PM 
18D4-1904E000*[8972] devenv.exe



I was finally able to get it to work. Something is wonky. I 
think it's when I use a normal VS side by side with the 
experimental that the experimental can't find the symbols 
and somehow the registry changes I made got reset.


So far it is working(I can hit BP's) but it's still 
basically the same scenario in that I have to completely 
shut down VS in order to reload visualD. Before I could 
automate because the normal visual studio instance could 
stay open... but it seems like it screws up the debugging 
symbols and such.


I could try to use another, different exp 
instance(different registry) but I feel the same problem 
might occur.


But I guess it's better than nothing.



Good to hear it (kind of) works now. VS2015 also resets the 
configuration rather often, so it's good to automate the 
patching.


I don't have troubles with exchanging the debug DLL while 
having the normal VS instance running. Maybe you have 
experimented with registry changes that now cause the debug 
DLL to be loaded there, too? Reinstalling Visual D should 
help in that case (though that will trigger rebuilding the 
user configuration).


I've tried to figure out why both DLLs are actually loaded 
(it has been bugging me before, too), but could not find the 
cause yet.


I managed to load the Debug DLL into the "experimental" VS 
without any (explicit) registry patching:


1. delete 
HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\privateregistry.bin to make sure to start from scratch


2. copy "c:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\Extensions\Rainer 
Schuetze\VisualD" to 
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\Extensions\Rainer Schuetze\VisualD"


3. replace paths in Extensions\Rainer 
Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL


4. start "devenv /RootSuffix Exp"

5. enable "Visual D" in the "Extensions and Updates..." dialog

6. restart VS

This even doesn't load the DLL twice for me.


This isn't working for me, even though it looks like it 
should. Those values in the pkgdef are exactly the ones I 
replaced in the privateregistry hive, but it seems that for 
some reason it is not being used ;/ (since my changes are not 
propagating to it)


This should work as this is really no different that what I 
was doing except it is more of the correct way.  I'm not sure 
what's going on but I'll try and figure it out. I probably 
need to use a clean instance of VS


It seems I have something weird going on. I have

15.0
15.0_4d0b469e
15.0_4d0b469eExp
15.0Exp which is empty except for a path containing 
VSTemplateStore.pkgdef and I don't believe this existed 
yesterday. I think I just created it with the util I used as I 
was trying to reset the exp instance(which I thought was the 
3rd one).


I'm not sure where the others came from but I'm going to 
create a new rootsuffix and try everything on that. I guess 
the 15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm 
not loading it ;/



Ok, I ran CreateExpInstance /create /VSInstance=15.0 
/RootSuffix=VisualDExp and it created a 15.0VisualDExp dir.


So, looks like the 15.0Exp was what I just created and it 
wasn't being used when I ran /RootSuffix=Exp.. which I guess, 
because it didn't exist, just used the original data.


I ran devenv.exe /RootStuffix VisualDExp

and it created

15.0_4d0b469eVisualDExp

So, something is funky. I guess 15.0_4d0b469e is the version. 
It loads, though, Visual D, so it is picking up the extensions 
from the original.


This seems to be a problem with Visual Studio ;/

Yeah, so, tried with a fresh exp copied all the stuff you 
mentioned, checked the files and same thing. I'm using 
enterprise on windows 10 creators so there might be bugs. It's 
clearly not loading the package changes I made so either it's 
bugged or it's loading them from a different place.


I'll try again tomorrow and see if things change ;/



Starting with VS2017, it's supposed to be possible to have 
different copies of VS installed. I guess the additional hex 
value after 15.0 is represents each of these different 
installations.


I don't run "CreateExpInstance", I just start "devenv 
/RootSuffix Exp" (or another suffix) which creates 
15.0_ade21380Exp for me. There is no 15.0 folder on my AppData 

New Features [was Named multi-imports]

[Jesse Phillips via Digitalmars-d]

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=utf-8=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++.

Re: struct field initialization

[bitwise via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 18:17:36 UTC, kinke wrote:

On Wednesday, 16 August 2017 at 18:11:05 UTC, bitwise wrote:
If I define a non-default constructor for a struct, are the 
fields initialized to T.init by the time it's called?


The struct instance is initialized with T.init before invoking 
the constructor.


Thanks for the quick response.

In regards to my second question, the "value = T(args);" variant 
seems to work, even with a const T, without calling a postblit - 
so I guess that's what I'll use.

Re: Named multi-imports

[Johnson Jones via Digitalmars-d]

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.

[Issue 17757] Wrongly reported deprecated message

[via Digitalmars-d-bugs]

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

johanenge...@weka.io changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||johanenge...@weka.io
 Resolution|--- |DUPLICATE

--- Comment #1 from johanenge...@weka.io ---


*** This issue has been marked as a duplicate of issue 17193 ***

--

Re: How to fix wrong deprecation message - dmd-2.075.1

[Johan Engelen via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 16:54:04 UTC, Pham wrote:
On Wednesday, 16 August 2017 at 13:55:31 UTC, Steven 
Schveighoffer wrote:

On 8/16/17 9:12 AM, Daniel Kozak via Digitalmars-d-learn wrote:
It should not be print? AIAIK std.utf.toUTF16 is not 
deprecated: http://dlang.org/phobos/std_utf.html#toUTF16


OK this one 
is:https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2760 (but this one is not in doc)


but this one should not be deprecated: 
https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2777




Hm.. that's a bug in the compiler. Only one is marked, but 
both are treated as deprecated.


Issue 17757 is created


I ran into this too the other day, and found that the issue was 
already filed:

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

- Johan

[Issue 17193] selective imports -> deprecation warnings even if symbol is not used

[via Digitalmars-d-bugs]

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

johanenge...@weka.io changed:

   What|Removed |Added

 CC||ap...@hotmail.com

--- Comment #2 from johanenge...@weka.io ---
*** Issue 17757 has been marked as a duplicate of this issue. ***

--

Re: struct field initialization

[bitwise via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 18:11:05 UTC, bitwise wrote:

[...]


I'm asking this because I need to forward args to a container's 
node's value.


Something like this:


struct Node(T)
{
int flags;
T value; // maybe const

this(Args...)(int flags, auto ref Args args)
{
this.flags = flags;

// this?
emplace(, args);

// or this?
value = T(args);

// ?
}
}

struct Container(T)
{
Node!T[] nodes;

void add(Args...)(auto ref Args args)
{
int flags = 1234;
auto p = cast(Node!T*)malloc(Node!T.sizeof);
nodes ~= emplace(p, flags, args);
}
}

Re: struct field initialization

[kinke via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 18:11:05 UTC, bitwise wrote:
If I define a non-default constructor for a struct, are the 
fields initialized to T.init by the time it's called?


The struct instance is initialized with T.init before invoking 
the constructor.

Re: SpaceD - a racing game written in D

[Dukc via Digitalmars-d-announce]

On Wednesday, 28 June 2017 at 07:20:08 UTC, Murzistor wrote:
The spaceship is completely uncontrollable! It obviously lacks 
of some sort of brakes (with jet engines directed forward).


Don't try to drive it like a car. Imagine you're piloting a boat. 
That's roughly how it behaves.

struct field initialization

[bitwise via Digitalmars-d-learn]

If I define a non-default constructor for a struct, are the 
fields initialized to T.init by the time it's called? or am I 
responsible for initializing all fields in that constructor?


..or do structs follow the same rules as classes?
https://dlang.org/spec/class.html#field-init

  Thanks

Re: Debugging Visual D using Visual D

[Rainer Schuetze via Digitalmars-d-debugger]

On 16.08.2017 16:48, Johnson wrote:

On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze wrote:



On 16.08.2017 08:32, Rainer Schuetze wrote:



On 16.08.2017 04:49, Johnson wrote:
 VisualD.dllC:\Program Files (x86)\VisualD\Debug\VisualD.dll 
N/AYesSymbols loaded.
   C:\Program Files (x86)\VisualD\Debug\VisualD.pdb229 
0.45.1-rc212/31/1969 7:00 PM13FB-143C* [8972] 
devenv.exe
 VisualD.dllC:\Program Files (x86)\VisualD\VisualD.dll
N/A YesCannot find or open the PDB file.271
0.45.1-rc2 12/31/1969 7:00 PM 18D4-1904E000*[8972] devenv.exe



I was finally able to get it to work. Something is wonky. I think 
it's when I use a normal VS side by side with the experimental that 
the experimental can't find the symbols and somehow the registry 
changes I made got reset.


So far it is working(I can hit BP's) but it's still basically the 
same scenario in that I have to completely shut down VS in order to 
reload visualD. Before I could automate because the normal visual 
studio instance could stay open... but it seems like it screws up 
the debugging symbols and such.


I could try to use another, different exp instance(different 
registry) but I feel the same problem might occur.


But I guess it's better than nothing.



Good to hear it (kind of) works now. VS2015 also resets the 
configuration rather often, so it's good to automate the patching.


I don't have troubles with exchanging the debug DLL while having the 
normal VS instance running. Maybe you have experimented with registry 
changes that now cause the debug DLL to be loaded there, too? 
Reinstalling Visual D should help in that case (though that will 
trigger rebuilding the user configuration).


I've tried to figure out why both DLLs are actually loaded (it has 
been bugging me before, too), but could not find the cause yet.


I managed to load the Debug DLL into the "experimental" VS without any 
(explicit) registry patching:


1. delete 
HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\privateregistry.bin 
to make sure to start from scratch


2. copy "c:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" 
to 
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\Extensions\Rainer 
Schuetze\VisualD"


3. replace paths in Extensions\Rainer 
Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL


4. start "devenv /RootSuffix Exp"

5. enable "Visual D" in the "Extensions and Updates..." dialog

6. restart VS

This even doesn't load the DLL twice for me.


This isn't working for me, even though it looks like it should. Those 
values in the pkgdef are exactly the ones I replaced in the 
privateregistry hive, but it seems that for some reason it is not being 
used ;/ (since my changes are not propagating to it)


This should work as this is really no different that what I was doing 
except it is more of the correct way.  I'm not sure what's going on but 
I'll try and figure it out. I probably need to use a clean instance of VS


It seems I have something weird going on. I have

15.0
15.0_4d0b469e
15.0_4d0b469eExp
15.0Exp which is empty except for a path containing 
VSTemplateStore.pkgdef and I don't believe this existed yesterday. I 
think I just created it with the util I used as I was trying to reset 
the exp instance(which I thought was the 3rd one).


I'm not sure where the others came from but I'm going to create a new 
rootsuffix and try everything on that. I guess the 15.0_4d0b469eExp is a 
_4d0b469eExp suffix and hence I'm not loading it ;/



Ok, I ran CreateExpInstance /create /VSInstance=15.0 
/RootSuffix=VisualDExp and it created a 15.0VisualDExp dir.


So, looks like the 15.0Exp was what I just created and it wasn't being 
used when I ran /RootSuffix=Exp.. which I guess, because it didn't 
exist, just used the original data.


I ran devenv.exe /RootStuffix VisualDExp

and it created

15.0_4d0b469eVisualDExp

So, something is funky. I guess 15.0_4d0b469e is the version. It loads, 
though, Visual D, so it is picking up the extensions from the original.


This seems to be a problem with Visual Studio ;/

Yeah, so, tried with a fresh exp copied all the stuff you mentioned, 
checked the files and same thing. I'm using enterprise on windows 10 
creators so there might be bugs. It's clearly not loading the package 
changes I made so either it's bugged or it's loading them from a 
different place.


I'll try again tomorrow and see if things change ;/



Starting with VS2017, it's supposed to be possible to have different 
copies of VS installed. I guess the additional hex value after 15.0 is 
represents each of these different installations.


I don't run "CreateExpInstance", I just start "devenv /RootSuffix Exp" 
(or another suffix) which creates 15.0_ade21380Exp for me. There is no 
15.0 folder on my AppData directories.


I'm on Win10.0.14393 (pre-creator), VS 2017 community.

Re: Named multi-imports

[jmh530 via Digitalmars-d]

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.

Re: Formated Output and file creation time

[H. S. Teoh via Digitalmars-d-learn]

On Wed, Aug 16, 2017 at 03:30:18PM +, Vino.B via Digitalmars-d-learn wrote:
[...]
> Current Output
> C:\Test1\Test2\T.txt 1234 2017-Aug-16 19:10:54.0618385
> C:\Test1\Test2\TX.txt 1234 2017-Aug-16 19:10:54.0618385
> C:\Test1\Test2\TXXX.txt 1234 2017-Aug-16 19:10:54.0618385
> 
> Required Output
> (1) Alain in Table Format like below
> (2) Remove the msec from the date part (0618385)
> 
> C:\Test1\Test2\T.txt   1234   2017-Aug-16 19:10:54
> C:\Test1\Test2\TX.txt  1234   2017-Aug-16 19:10:54
> C:\Test1\Test2\TXXX.txt1234   2017-Aug-16 19:10:54
> 
> I tried the below but no luck
> writefln("%s %10d %10s", d, d.size, d.timeCreated());

Try this:

writefln("%-36s %8s %.20s", d, d.size, d.timeCreated());


T

-- 
"You know, maybe we don't *need* enemies." "Yeah, best friends are about all I 
can take." -- Calvin & Hobbes

Re: How to fix wrong deprecation message - dmd-2.075.1

[Pham via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 13:55:31 UTC, Steven 
Schveighoffer wrote:

On 8/16/17 9:12 AM, Daniel Kozak via Digitalmars-d-learn wrote:
It should not be print? AIAIK std.utf.toUTF16 is not 
deprecated: http://dlang.org/phobos/std_utf.html#toUTF16


OK this one 
is:https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2760 (but this one is not in doc)


but this one should not be deprecated: 
https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2777




Hm.. that's a bug in the compiler. Only one is marked, but both 
are treated as deprecated.


I'm wondering if just resolving the overload triggers the 
message.


Please file an issue.

-Steve


Issue 17757 is created

[Issue 17757] New: Wrongly reported deprecated message

[via Digitalmars-d-bugs]

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

  Issue ID: 17757
   Summary: Wrongly reported deprecated message
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ap...@hotmail.com

Discussion: https://forum.dlang.org/post/on1isk$2rpm$1...@digitalmars.com

There are two toUTF16 (one template and one function), the function one is
deprecated but the template one is not. Same issue with toUTF8 ones

Test on dmd-2.075.1

void main()
{
 import std.utf : toUTF16; // Same problem with toUTF8
 wstring s = toUTF16!string("abc");
}

Compilation output:
/d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated - To
be removed November 2017. Please use std.utf.encode instead.
/d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated - To
be removed November 2017. Please use std.utf.encode instead.

--

Formated Output and file creation time

[Vino.B via Digitalmars-d-learn]

Hi,

 I have a small program which will list the file names, size and 
creation date and time, the output of the program is as below and 
required your help to print the output as per "Required Output"


Current Output
C:\Test1\Test2\T.txt 1234 2017-Aug-16 
19:10:54.0618385

C:\Test1\Test2\TX.txt 1234 2017-Aug-16 19:10:54.0618385
C:\Test1\Test2\TXXX.txt 1234 2017-Aug-16 19:10:54.0618385

Required Output
(1) Alain in Table Format like below
(2) Remove the msec from the date part (0618385)

C:\Test1\Test2\T.txt   1234   2017-Aug-16 19:10:54
C:\Test1\Test2\TX.txt  1234   2017-Aug-16 19:10:54
C:\Test1\Test2\TXXX.txt1234   2017-Aug-16 19:10:54

I tried the below but no luck
writefln("%s %10d %10s", d, d.size, d.timeCreated());

From,
Vino.B

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/16/17 8:58 AM, Steven Schveighoffer wrote:
However, I have found a better way to call postblit that involves the 
qualifiers than the way Variant currently does it. I'm going to submit a 
PR to fix these issues.


https://github.com/dlang/phobos/pull/5694

-Steve

[Issue 13262] Cannot send certain shared data to another thread

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Assignee|and...@erdani.com   |schvei...@yahoo.com

--- Comment #4 from Steven Schveighoffer  ---
PR: https://github.com/dlang/phobos/pull/5694

--

Re: If structures places data to stack why we do not getting stackoverflow on array of structures?

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/16/17 10:32 AM, Suliman wrote:

On Wednesday, 16 August 2017 at 13:41:29 UTC, Biotronic wrote:

On Wednesday, 16 August 2017 at 12:50:07 UTC, Suliman wrote:

MyStruct[] is actually a struct similar to this:

struct MyStruct[] {
MyStruct* ptr;
size_t length;
}

That struct is placed on the stack, but the data it points to, via 
the ptr field, is heap allocated.


What is struct? Just name and size?


I'm sorry, I don't understand what you're asking. Can you please 
repeat with more information?


--
  Biotronic


I am trying to understand what structure is. It's name + associated with 
this name data? I can't understand for my self what mean no put 
structure to stack. Just put it's name to it or something another?


The structure is just a pointer and length. What it points at is not on 
the stack, it's in the heap.


This is how a dynamic array works. Indeed:

auto x = new int[1];
pragma(msg, x.sizeof); // 16LU

-Steve

[Issue 14893] std.concurrency: can't send shared arrays or shared structs

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Steven Schveighoffer  ---
This really has the same root causes as 13262.

*** This issue has been marked as a duplicate of issue 13262 ***

--

Re: Stefan Koch: New CTFE fix

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 16 August 2017 at 13:53:40 UTC, Johnson wrote:
On Wednesday, 16 August 2017 at 10:03:56 UTC, Moritz Maxeiner 
wrote:

On Wednesday, 16 August 2017 at 07:24:36 UTC, Biotronic wrote:


When Moritz commented on your use of 'do' as a function name, 
that may have been unnecessary for a discussion of your 
problem.


I would contend that when discussing semantics (that is the 
PL's syntax is not open for change as part of the discussion) 
it's common courtesy to use valid syntax.
You're right in that it was unnecessary to discuss the issue 
he was describing, but it was relevant to me as a matter of 
principle.


No, it wasn't.


Refer to my post clarifying that (ambiguous) sentence.

It was a matter of you ego... and I see your buddies have 
joined the game.


I see ad hominem attacks remain your favorite response :)



What if I did

void Do() { }

Would you bitch and complain about that?


If you actually bothered to not only read my post but actually 
think about it, then you would realize that the answer to that 
question is "I neither bitched nor complained about the first 
one, I wouldn't about the second one, either".




Maybe the original was a syntax error then and not a "semantic" 
error as you like to call it?


I have not written about semantic errors so far. Regardless, yes, 
as I pointed out it was a syntax error.




The fact is, the name of the function is completely irrelevant 
to the discussion


As I pointed out, I consider it common courtesy to use valid PL 
syntax when discussing semantic issues.

Even if I didn't, it was still an error.


and you had to make a big deal out of it


Interesting (and frankly amusing) how you attempt to twist things 
around. All I did was neutrally point out the invalid syntax; the 
disproportionate emotional response including ad hominem attacks 
(also known as "making a big deal out of it") was all you.



because of your ego.


Again with the ad hominem, also pure speculation.



What if it were pseudo code?


Then I wouldn't have pointed it out as a syntax error. The 
context, however, made it quite clear it was not pseudo code :)




Again, instead proof that either you are an idiot(which I 
doubt) or that you have some need to prove something and will 
find anything to nitpick on.


You emotional outburst is misplaced. If you don't want factual 
mistakes pointed out, refrain from engaging in technical 
discussions.


This is far more childish than those morons that say I'm 
childish,


Ad hominem.


and they even agree with me that what you did was nonsense...


a) So far one other person has responded, not multiple
b) Did you read the same post I did? Because that post wrote "may 
have been unnecessary", which is not the same as "was 
unnecessary". Even assuming that he did mean "was unnecessary" is 
not the same as "nonsense". Even assuming he did mean "nonsense", 
I already explained my reasoning.



completely irrelevant to the discussion.


See above.



That is, until we have a functioning __ctfeWrite in druntime. 
The function is already in druntime's object.d, and is just 
awaiting an implementation[2]. That implementation will 
possibly have to wait for Stefan's CTFE makeover to complete.


Well, my implementation attempt I linked to earlier [1] passes 
the auto tester for the test in Stefan's original PR and so 
far it works as expected in all my personal cases. If you find 
something wrong with it, please comment on the PR's page :)


[1] https://github.com/dlang/dmd/pull/7082



So, if the people already want what I want,


They don't, you *explicitly* wanted `pragma(msg, ...)` to work.

and you already did your own pull, why the hell are you saying 
it can't be done?


pragma(msg, ...) != __ctfeWrite
Which you would know, if you actually read the compile time page 
by H. S. Teoh I linked you earlier :)


Again, because you are looking for something to prove, and 
calling you out on it is the right thing to do regardless what 
idiots think.


Ad hominem.



You can make the claim that pragma(msg, ...) happens before the 
ctfe is ran, but again, which pragma(msg, ...)?


It's not a claim, it's a fact.

With CTFE there are two levels, the compiler is ran twice, once 
on the original code and once on the CTFE to actually compile 
it. Just because the compiler run's it the first time DOES not 
mean that should be the only way. You talk about semantics but 
you seem not to understand the term well.  A single symbolic 
name for something can have many interpretations. When one, 
someone like yourself or the D compiler, only interprets it one 
way, it leads to problems.


You really should read that page I linked to earlier.



How out pragmaCTFE(msg, ...)? Is that good enough for you, or 
you will find something wrong with that too?


Renaming pragma to pragmaCTFE doesn't change anything, because 
it's still a pragma and pragmas in a function body are handled 
before the function body is interpreted at CTFE.


Do you realize that 

[Issue 13262] Cannot send certain shared data to another thread

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #3 from Steven Schveighoffer  ---
*** Issue 14893 has been marked as a duplicate of this issue. ***

--

Re: Debugging Visual D using Visual D

[Johnson via Digitalmars-d-debugger]

On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze 
wrote:



On 16.08.2017 08:32, Rainer Schuetze wrote:



On 16.08.2017 04:49, Johnson wrote:
 VisualD.dllC:\Program Files 
(x86)\VisualD\Debug\VisualD.dll N/AYesSymbols loaded.
   C:\Program Files (x86)\VisualD\Debug\VisualD.pdb229
0.45.1-rc212/31/1969 7:00 PM13FB-143C*
[8972] devenv.exe
 VisualD.dllC:\Program Files 
(x86)\VisualD\VisualD.dllN/A YesCannot find or open 
the PDB file.2710.45.1-rc2 12/31/1969 7:00 PM
18D4-1904E000*[8972] devenv.exe



I was finally able to get it to work. Something is wonky. I 
think it's when I use a normal VS side by side with the 
experimental that the experimental can't find the symbols and 
somehow the registry changes I made got reset.


So far it is working(I can hit BP's) but it's still basically 
the same scenario in that I have to completely shut down VS 
in order to reload visualD. Before I could automate because 
the normal visual studio instance could stay open... but it 
seems like it screws up the debugging symbols and such.


I could try to use another, different exp instance(different 
registry) but I feel the same problem might occur.


But I guess it's better than nothing.



Good to hear it (kind of) works now. VS2015 also resets the 
configuration rather often, so it's good to automate the 
patching.


I don't have troubles with exchanging the debug DLL while 
having the normal VS instance running. Maybe you have 
experimented with registry changes that now cause the debug 
DLL to be loaded there, too? Reinstalling Visual D should help 
in that case (though that will trigger rebuilding the user 
configuration).


I've tried to figure out why both DLLs are actually loaded (it 
has been bugging me before, too), but could not find the cause 
yet.


I managed to load the Debug DLL into the "experimental" VS 
without any (explicit) registry patching:


1. delete 
HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\privateregistry.bin to make sure to start from scratch


2. copy "c:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\Extensions\Rainer 
Schuetze\VisualD" to 
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\Extensions\Rainer Schuetze\VisualD"


3. replace paths in Extensions\Rainer 
Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL


4. start "devenv /RootSuffix Exp"

5. enable "Visual D" in the "Extensions and Updates..." dialog

6. restart VS

This even doesn't load the DLL twice for me.


This isn't working for me, even though it looks like it should. 
Those values in the pkgdef are exactly the ones I replaced in the 
privateregistry hive, but it seems that for some reason it is not 
being used ;/ (since my changes are not propagating to it)


This should work as this is really no different that what I was 
doing except it is more of the correct way.  I'm not sure what's 
going on but I'll try and figure it out. I probably need to use a 
clean instance of VS


It seems I have something weird going on. I have

15.0
15.0_4d0b469e
15.0_4d0b469eExp
15.0Exp which is empty except for a path containing 
VSTemplateStore.pkgdef and I don't believe this existed 
yesterday. I think I just created it with the util I used as I 
was trying to reset the exp instance(which I thought was the 3rd 
one).


I'm not sure where the others came from but I'm going to create a 
new rootsuffix and try everything on that. I guess the 
15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm not 
loading it ;/



Ok, I ran CreateExpInstance /create /VSInstance=15.0 
/RootSuffix=VisualDExp and it created a 15.0VisualDExp dir.


So, looks like the 15.0Exp was what I just created and it wasn't 
being used when I ran /RootSuffix=Exp.. which I guess, because it 
didn't exist, just used the original data.


I ran devenv.exe /RootStuffix VisualDExp

and it created

15.0_4d0b469eVisualDExp

So, something is funky. I guess 15.0_4d0b469e is the version. It 
loads, though, Visual D, so it is picking up the extensions from 
the original.


This seems to be a problem with Visual Studio ;/

Yeah, so, tried with a fresh exp copied all the stuff you 
mentioned, checked the files and same thing. I'm using enterprise 
on windows 10 creators so there might be bugs. It's clearly not 
loading the package changes I made so either it's bugged or it's 
loading them from a different place.


I'll try again tomorrow and see if things change ;/

Re: Named multi-imports

[Mike Wey via Digitalmars-d]

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

Re: If structures places data to stack why we do not getting stackoverflow on array of structures?

[Suliman via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 13:41:29 UTC, Biotronic wrote:

On Wednesday, 16 August 2017 at 12:50:07 UTC, Suliman wrote:

MyStruct[] is actually a struct similar to this:

struct MyStruct[] {
MyStruct* ptr;
size_t length;
}

That struct is placed on the stack, but the data it points 
to, via the ptr field, is heap allocated.


What is struct? Just name and size?


I'm sorry, I don't understand what you're asking. Can you 
please repeat with more information?


--
  Biotronic


I am trying to understand what structure is. It's name + 
associated with this name data? I can't understand for my self 
what mean no put structure to stack. Just put it's name to it or 
something another?

Re: C++17 Init statement for if/switch

[SrMordred via Digitalmars-d]

On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler 
wrote:


Without alot of usage, it will just be an esoteric construct 
that looks confusing to the average developer.


That is correct. After a while it gets tiring to see a 
neverending stream of complexity added to the language while 
things that would actually help (like IDE support) do not get 
any attention. As a general rule, if it's being added to C++, 
it's probably a bad idea.


There are two thinks of c++ that I miss a little on D:
- Structured binding
- Uniform initialization

But in general, I agreed with you.

Re: Stefan Koch: New CTFE fix

[Stefan Koch via Digitalmars-d]

On Wednesday, 16 August 2017 at 13:55:51 UTC, Johnson wrote:

You know, if you people actually focused on the real issues ...


I agree.
Please apply said focus.

Reflection is not limited to compile-time.

[Issue 17731] dman fails to build due to more than 32767 symbols

[via Digitalmars-d-bugs]

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

--- Comment #11 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/b64a108e7866874d172f9b05fd82716997a1
chmgen: Emit d.tag in JSON syntax too

--

[Issue 17458] [std.regex] Assertion failure in package.d

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/7a51c0e24eea6c02336d2aa897c608974ea2ac57
Fix issue 17458 add messages to asserts

https://github.com/dlang/phobos/commit/008a8a3ef3fab4e1f51f2bf65d3f6b42dc152f78
Merge pull request #5660 from DmitryOlshansky/issue-17458

--

[Issue 17735] AssertError@ddmd/target.d(357): unhandled op using fish operators

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/984a4fa44acf8818b1c42eddabac33add7cad5e9
fix Issue 17735 - AssertError@ddmd/target.d(357): unhandled op using fish
operators

https://github.com/dlang/dmd/commit/a46998371503f68f3a867206c63578d7ab3f6d7d
Merge pull request #7075 from ibuclaw/vectorfish

--

[Issue 12260] Improve error of std.stdio.readf when involving whitespace

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/afc732661a5cbdd69b22d5bffa57fddab76172ad
Fix Issue 12260 - Improve error of std.stdio.readf when involving whitespace

https://github.com/dlang/phobos/commit/63de27b5308b6bdb4e0489cc53e87e603f0c95cf
Merge pull request #5591 from RazvanN7/Issue_12260

--

[Issue 17695] [Reg 2.076] ICE with vector negation

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/7ceb34a633518c75e61f858fde1fa3eb4d7c6300
fix Issue 17695 - [Reg 2.076] ICE with vector negation

https://github.com/dlang/dmd/commit/6dc8c01c246c3633077ed2e7bc9d17fb0a79d896
Merge pull request #7035 from WalterBright/fix17695

--

[Issue 15771] FileLogger should create the output directory if it does not exist

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/e85381ee42652029a8b1c8d8397aee78c2ae7139
Fix Issue 15771 - FileLogger should create the output directory if it does not
exist

https://github.com/dlang/phobos/commit/d27a3bf9d53c9b0dd35f70c5060891d68dd6ce6a
Merge pull request #5594 from RazvanN7/Issue_15771

--

[Issue 17428] [scope] class field assignment allows to escape scope parameters

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/16a922f0864569b669b65448cf647de0c605e41d
fix Issue 17428 - [scope] class field assignment allows to escape scope
parameters

https://github.com/dlang/dmd/commit/d61411be90d36439ab91418434f900cdf1bf5ade
Merge pull request #7025 from WalterBright/fix17428

--

[Issue 17688] ICE with static foreach directly inside switch

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/7ebda47f6a162ce3de774a042207eb883908b650
fix Issue 17688 - ICE with static foreach directly inside switch

https://github.com/dlang/dmd/commit/e1e68148e0cd0eb1cfa21a8c0b24afcf7f3781f9
Merge pull request #7023 from tgehr/fix17688

--

[Issue 17594] Define DDOC_BLANKLINE as an empty HTML paragraph, thus obviating the need to wrap text in $(P ...)

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/1040dd920cf18c7ce0ca2fcde963f90853084cd9
Fix Issue 17594 - Define DDOC_BLANKLINE as an empty HTML paragraph, thus
obviating the need to wrap text in $(P ...)

https://github.com/dlang/dlang.org/commit/a54adeca33341dd92cf090160e19a6a100f6a652
Merge pull request #1795 from andralex/DDOC_BLANKLINE

--

[Issue 9287] DMD should read from stdin when an input file is "-"

[via Digitalmars-d-bugs]

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

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/7d1813309a8c89c8349672ba37a8c15f9d5a42a2
Fix issue 9287 - implement reading source from stdin.

https://github.com/dlang/dmd/commit/28daf534a405e9a07d42afb8f978d8746be7b89a
Merge pull request #6880 from quickfur/stdin

--

[Issue 17430] [scope] delegate can escape context ptr

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/7f3af47c742e6ec30b69e4ad4064d2474ca31769
fix Issue 17430 - [scope] delegate can escape context ptr

https://github.com/dlang/dmd/commit/d8e010ffb89d8569f10a95a3d2fcb95dad6b29a6
Merge pull request #7027 from WalterBright/fix17430

--

[Issue 17722] Wrong diagnostic using __traits(compiles, e1 && e2) expressions.

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/ec3494661edce54b2e72efd762247532e433cec1
fix Issue 17722 - Wrong diagnostic using __traits(compiles, e1 && e2)
expressions

https://github.com/dlang/dmd/commit/bfee6b36fbcf2752e3c94d8bd8089779bad807e6
Merge pull request #7067 from ibuclaw/issue17722

--

[Issue 17640] std.concurrenct writeln conflicts with std.stdio writeln in unittests

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/a5afe1609feed83f2233cad80a54201dccdd4b1e
Fix Issue 17640 - std.concurrenct writeln conflicts with std.stdio writeln in
unittests

https://github.com/dlang/phobos/commit/72c1c2bc3a27f529128a453bc8327a76cd162e2f
Merge pull request #5600 from wilzbach/fix-17640

--

[Issue 4014] CodeView debug type info not linked in from library

[via Digitalmars-d-bugs]

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/9d2eeda0383fa55a8dea58f4d6960bb110e77c56
fix issue 4014 - add option to add debug info for all referenced types

https://github.com/dlang/dmd/commit/8aeca3c24e742eff8a5a72c27ea6ebd61a167582
Merge pull request #6908 from rainers/cv_symdebref

--

[Issue 17629] package.di files cannot be used

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/e205f8947bfb099dd12556cc5c3343cdee479eae
fix Issue 17629: Try loading package.di prior to package.d

https://github.com/dlang/dmd/commit/0bd1739fdd8b87e57f4886555f27a8e07e98c643
add test for Issue 17629 - package.di files not supported

--

[Issue 13153] dlang.org: provide version-specific documentation of the language and stdlib

[via Digitalmars-d-bugs]

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/b0a06c7deab4b8093d6e1fe7f592001d60a3e7c1
Fix issue 13153 - Add a version chooser to DDoc pages

--

[Issue 17697] Ddoc: automatically highlight URLs outside of macro arguments

[via Digitalmars-d-bugs]

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/f100182bbde9496063c223fab2880a901be29880
fix Issue 17697 - Ddoc: automatically highlight URLs outside of macro arguments

https://github.com/dlang/dmd/commit/d15072fc64c1d59ac107834a3c2738919a243002
Merge pull request #7043 from WalterBright/fix17697

--

[Issue 6718] "nWayUnion" => "nWayMerge", plus true nWayUnion

[via Digitalmars-d-bugs]

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

--- Comment #16 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/9efa504bdca2b2644375e86d3b1527170512b726
Fix Issue 6718 - nWayUnion => nWayMerge, plus true nWayUnion

https://github.com/dlang/phobos/commit/bdae5f08f3cf4ed153063ad1d9a07fbb5aa12668
Merge pull request #5620 from RazvanN7/Issue_6718

--

[Issue 16997] Integral promotion rules not being followed for unary + - ~ expressions

[via Digitalmars-d-bugs]

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

--- Comment #10 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/47d9a09e66d7fde929b596a72450a92d51d0b3e1
bigint: fix dependency on broken Issue 16997

https://github.com/dlang/phobos/commit/c1832981e3818a151ee25805d47d472633a218ad
Merge pull request #5646 from WalterBright/bigint-cast

--

[Issue 17250] ProcessPipes (std.process) should provide a test for a null pid

[via Digitalmars-d-bugs]

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

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/b4284db1f937e90fec6ffe4a9e4e2bf4783799bb
Fix Issue 17250 - ProcessPipes (std.process) should provide a test for a null
pid

https://github.com/dlang/phobos/commit/1e296c11d8f8083402f8611d495cdcd015ff6fb3
Merge pull request #5621 from RazvanN7/Issue_17250

--

[Issue 17690] [REG2.066.0] scope guards leak declarations

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/978490aca27e374141607369389f6694d78af182
fix Issue 17690 - scope guards leak declarations

https://github.com/dlang/dmd/commit/5049277bb3f48c19cc7327c0db40c5097ba35f62
Merge pull request #7026 from tgehr/fix17690

--

[Issue 17650] [REG v2.075.0 b1-b4] std.getopt range violation

[via Digitalmars-d-bugs]

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

--- Comment #13 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/296184f5419e1a7f8748688606950e747338f8f1
Fix issue 17650: std.getopt range violation when option value is a hyphen.

https://github.com/dlang/phobos/commit/603e406b60cedd199b7bb2b6f9167438ec452307
Merge pull request #5612 from jondegenhardt/issue-17650-getopt-range-violation

--

[Issue 16397] missing coverage from template instances when using separate compilation

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/1f7e59980539fe0f9ba352b258e8266db6bdff01
fix test coverage

--

[Issue 17616] makeIndex cannot fully use range of index type

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/54bda1e5bcb98f898342c51186f659293f73aa86
fix Issue 17616 - makeIndex cannot fully use range of index type

--

Re: Named multi-imports

[jmh530 via Digitalmars-d]

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

Re: Stefan Koch: New CTFE fix

[Johnson via Digitalmars-d]

On Wednesday, 16 August 2017 at 07:24:36 UTC, Biotronic wrote:

On Tuesday, 15 August 2017 at 16:10:40 UTC, Johnson wrote:
I'm sorry, but you are obviously someone in *need* to prove 
something. No need to respond, ever.


You need to grow up.

When Moritz commented on your use of 'do' as a function name, 
that may have been unnecessary for a discussion of your 
problem. Your vitriolic and childish reaction to that though, 
was not just unnecessary, but has done you a massive disservice 
and is more than unlikely to garner goodwill from others on the 
forum.




Oh, your such a bad boy. How bout you grow up. If I'm childish, 
you are just a smaller child because you are doing the exact same 
thing... getting on the internet, pretending to be some bad boy 
with something to say... like anyone will listen to you. That 
goes for your buddy too. Probably all the same person that has 
nothing real to say.


But at least we agree on Mortimer.

You know, if you people actually focused on the real issues 
instead of trying to show how bit your (tiny)dick was then there 
would be less problems in the world.

Re: How to fix wrong deprecation message - dmd-2.075.1

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/16/17 9:12 AM, Daniel Kozak via Digitalmars-d-learn wrote:
It should not be print? AIAIK std.utf.toUTF16 is not deprecated: 
http://dlang.org/phobos/std_utf.html#toUTF16


OK this one 
is:https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2760 (but 
this one is not in doc)


but this one should not be deprecated: 
https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2777




Hm.. that's a bug in the compiler. Only one is marked, but both are 
treated as deprecated.


I'm wondering if just resolving the overload triggers the message.

Please file an issue.

-Steve

[Issue 16993] Documentation for toSimpleString and toString does not explain how they differ

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/57ef9199632b8cb5451f9d7d8c76aad29410db84
Fix issue 16993: Clarify documentation of std.datetime's toString functions.

https://github.com/dlang/phobos/commit/3324796a2972a2f62ac3f1b73727a5d9e3d5e011
Merge pull request #5592 from jmdavis/issue_16993

--

[Issue 16191] std/digest/digest.d should be renamed to package.d

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/5774d017eb4fa154491385a91f590abc2f66b964
Fix issue 16191 - std/digest/digest.d should be renamed to package.d

--

[Issue 17702] codemirror hangs firefox for several seconds

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/fb777cdb28b81c07cf9343103c61fb6eeffccbd2
Fix Issue 17702 - codemirror hangs firefox for several seconds

https://github.com/dlang/dlang.org/commit/a9065a2dc39d60c028622a4de1c2e8ae4103757b
Merge pull request #1849 from wilzbach/fix-17702

--

[Issue 17590] Unnecessary GC alloc on returning static local struct

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/9940f4ce5e82f783b3c41c260c32b56b11e37f8a
Fix Issue 17590 - Unnecessary GC alloc on returning static local struct

https://github.com/dlang/dmd/commit/c3c8a71e085c16d56a359d5007590e4737292ee4
Merge pull request #6963 from JohanEngelen/closurenonstatic

--

[Issue 16062] Add 'clear' method to OutBuffer (std.outbuffer)

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/09ab8e96e33e8a41b735928f38629536fba883b6
Fix Issue 16062 - Add 'clear' method to OutBuffer (std.outbuffer)

https://github.com/dlang/phobos/commit/a1f274dca6da79d5cfed2382ec9cae867cf25a9c
Merge pull request #5593 from RazvanN7/Issue_16062

--

[Issue 17680] Broken ddmd source links in documentation

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/2501a047179eba522a73a91bd049d63772d5f48f
Use DDoc syntax for license links

https://github.com/dlang/dmd/commit/1d2bf7149eba8ad8d8bb262234c23cbaaefc2b7b
Use DDoc syntax for source links

--

[Issue 17587] JSONOptions: No forward slash encoding

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/0503b9b4a55512335ce038a34aa57a137b76753d
add JSONOptions.doNotEscapeSlashes

https://github.com/dlang/phobos/commit/987ebc54baffe1d8cf41a560ab7a746721e1c7de
Merge pull request #5552 from aG0aep6G/17587

--

[Issue 14085] Broken links on dlang.org

[via Digitalmars-d-bugs]

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

--- Comment #11 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/5677e55763e30550ec77bbf3f9e2255f8ab63084
Fix broken link to cpp0x

--

[Issue 17539] std.parallellism.parallel triggers 'statement not reachable' warnings in the rdmd_test suite

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/f3770ba1d675ed952012cbfc8dd38b823e1d3ca7
Fix Issue 17539 - std.parallellism.parallel triggers 'statement not reachable'

https://github.com/dlang/phobos/commit/c0652345e992a312d3df2005f56e1b9b7eb1e8c3
Merge pull request #5502 from wilzbach/fix-17539

--

[Issue 17689] finally clause leaks declarations

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/d3a39e3aaaf6c976c9a678524e2ecdee4ee63052
fix Issue 17689 - finally clause leaks declarations

https://github.com/dlang/dmd/commit/cc3187d6f1e529b5db77098479a3d3091d70ffaa
Merge pull request #7024 from tgehr/fix17689

--

Re: Stefan Koch: New CTFE fix

[Johnson via Digitalmars-d]

On Wednesday, 16 August 2017 at 10:03:56 UTC, Moritz Maxeiner 
wrote:

On Wednesday, 16 August 2017 at 07:24:36 UTC, Biotronic wrote:


When Moritz commented on your use of 'do' as a function name, 
that may have been unnecessary for a discussion of your 
problem.


I would contend that when discussing semantics (that is the 
PL's syntax is not open for change as part of the discussion) 
it's common courtesy to use valid syntax.
You're right in that it was unnecessary to discuss the issue he 
was describing, but it was relevant to me as a matter of 
principle.


No, it wasn't. It was a matter of you ego... and I see your 
buddies have joined the game.


What if I did

void Do() { }

Would you bitch and complain about that?

Maybe the original was a syntax error then and not a "semantic" 
error as you like to call it?


The fact is, the name of the function is completely irrelevant to 
the discussion and you had to make a big deal out of it because 
of your ego.


What if it were pseudo code?

Again, instead proof that either you are an idiot(which I doubt) 
or that you have some need to prove something and will find 
anything to nitpick on. This is far more childish than those 
morons that say I'm childish, and they even agree with me that 
what you did was nonsense... completely irrelevant to the 
discussion.





That is, until we have a functioning __ctfeWrite in druntime. 
The function is already in druntime's object.d, and is just 
awaiting an implementation[2]. That implementation will 
possibly have to wait for Stefan's CTFE makeover to complete.


Well, my implementation attempt I linked to earlier [1] passes 
the auto tester for the test in Stefan's original PR and so far 
it works as expected in all my personal cases. If you find 
something wrong with it, please comment on the PR's page :)


[1] https://github.com/dlang/dmd/pull/7082



So, if the people already want what I want, and you already did 
your own pull, why the hell are you saying it can't be done? 
Again, because you are looking for something to prove, and 
calling you out on it is the right thing to do regardless what 
idiots think.


You can make the claim that pragma(msg, ...) happens before the 
ctfe is ran, but again, which pragma(msg, ...)? With CTFE there 
are two levels, the compiler is ran twice, once on the original 
code and once on the CTFE to actually compile it. Just because 
the compiler run's it the first time DOES not mean that should be 
the only way. You talk about semantics but you seem not to 
understand the term well.  A single symbolic name for something 
can have many interpretations. When one, someone like yourself or 
the D compiler, only interprets it one way, it leads to problems.


How out pragmaCTFE(msg, ...)? Is that good enough for you, or you 
will find something wrong with that too? Do you realize that 
there are two levels of compilation going in with ctfe? 
Essentially two DMD's? If there are two dmd's then there are two 
pragma's, is there not? So the arguments you make may be correct, 
you are missing half of the equation and fail to realize that 
because you are trying to prove something rather than enlighten 
yourself.

Re: C++17 Init statement for if/switch

[jmh530 via Digitalmars-d]

On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher 
wrote:


I like that.  Feature freeze D until *all* bug reports are 
closed.
While that would mean no more features for several years, I 
think it would benefit the language in the long run, both 
internally (less discussions about incorrect behavior) and 
externally (D is a mature and stable language).


Seems a bit much. How about new features can only be added in one 
of every N releases (Where N > 1)?

[Issue 17484] high penalty for vbroadcastsd with -mcpu=avx

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/1f11aa0eb8f6087b7dbadeb770e4526ec9808ccc
fix Issue 17484 - high penalty for AVX-256 instructions with AVX-128 regs

--

[Issue 15750] net/isemail uses lots of redundant helper methods

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/5c31dd26ed289b397a4bad32ac29af6e77247ef7
Issue 15750 - remove substr from std.net.isemail

https://github.com/dlang/phobos/commit/e9ff980095462ee88713bcea3cc9852de5081e5b
Merge pull request #5585 from wilzbach/remove-substr

--

[Issue 17159] Behavior of unions at compile time is not documented

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/e6085cb8faa58a8dcf243aacd3bc93f3ac89d8b2
Fix Issue 17159 - Behavior of unions at compile time is not documented

https://github.com/dlang/dlang.org/commit/eefbd0fd9aedce5c063e135a295e84f183d0e62a
Merge pull request #1702 from wilzbach/fix-17159

--

[Issue 17560] Enhancement: view and copy full code example for offline compile/play

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/72f109646392dd412e77dc6db1a2cbe34285c9a2
Add 'Open in editor' button for runnable code examples

--

[Issue 17480] [Downloads]

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/4848d71051dbe2e2178b51f7252b03607edda338
Fix Issue 17480 - Update file contents of the release archives

--

[Issue 15432] Win64: bad code offset in debug line number info

[via Digitalmars-d-bugs]

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

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/399b12d8d6feaf43ced88c2559404f29ab70c496
fix issue 15432: Win64: bad code offset in debug line number info

https://github.com/dlang/dmd/commit/a7867ca72bf51a6db9e3ed44428e142a21d3de75
Merge pull request #6979 from rainers/issue15432

--

[Issue 17660] ICE with `static foreach`: AssertError@ddmd/visitor.d(39)

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/425f129192605d53288190762ebd75a50a300a26
fix Issue 17660 - ICE with : AssertError@ddmd/visitor.d(39)

https://github.com/dlang/dmd/commit/af3eacf44280c8f368e6938c09cfae68e6489ee1
Merge pull request #7005 from tgehr/fix17660

--

[Issue 17680] Broken ddmd source links in documentation

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/fc7a8aeadeaf3782ffd60e802d705bf7ac0f3e0d
Issue 17680 - fix DMDSRC

https://github.com/dlang/dlang.org/commit/f2ecd76842a28bfa15acf72460a77f93010bcfdd
Merge pull request #1843 from wilzbach/fix-17680

--

[Issue 17262] Better docs for rdmd

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/5a598f92996981b72ac497fc601b1e9e2b0597ea
Fix Issue 17262 - Better docs for rdmd

https://github.com/dlang/dlang.org/commit/7f5d85e916578ae1505ba9a94e6b62f278de075c
Merge pull request #1700 from wilzbach/fix-17262

Fix Issue 17262 - Better docs for rdmd

--

[Issue 14085] Broken links on dlang.org

[via Digitalmars-d-bugs]

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

--- Comment #10 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/c266aa9087829d34d00a0140be524c73e04c906c
index.d: Use MREF to fix broken DDox links

Partial fix for issue 14085.

--

[Issue 17392] Add Dub file for the lexer and parser

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/b5e6ed443db8246e98beec64f55f7717dbe45989
Fix issue 17392 - Add Dub file for the lexer and parser

https://github.com/dlang/dmd/commit/196760c92aeb05fd1df9789214a1d5805c004d03
Merge pull request #6771 from jacob-carlborg/issue-17392-dub

--

[Issue 17612] [REG2.063] Segmentation fault with bad object.d

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/9e486c36fc76b7ccf45e3d9f19fa9115e7986d19
fix Issue 17612 - [REG2.063] Segmentation fault with bad object.d

https://github.com/dlang/dmd/commit/49c0625f305907aa4f9d81aff3370598aac2f5b7
Merge pull request #6975 from WalterBright/fix17612

--

[Issue 17224] Foreach documentation still refers to TypeTuples, rather than AliasSequences

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/2df413227674c312cd48100046472c220d51fac7
Fix Issue 17224 - Foreach documentation still refers to TypeTuples, rather than
AliasSequences

https://github.com/dlang/dlang.org/commit/456e5cd1da516683a90f4ff0a24d45f33f21196e
Merge pull request #1701 from wilzbach/fix-17224

--

[Issue 8680] Provide additional iteration modes for dirEntries

[via Digitalmars-d-bugs]

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

--- Comment #14 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/efd740e55132a7c0fce4de4263104d599233e066
Improve documentation of std.file.SpanMode (issue 8680)

https://github.com/dlang/phobos/commit/8fadb88f8d3c279cc0595ca4167a28aacf7d184e
Merge pull request #5569 from CyberShadow/pull-20170707-153926

--

[Issue 17711] std.array.byPair should be usable with const AA

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/0c0aed8662dcd3579de4521c98ce0facbfd774fe
Fix issue 17711: std.array.byPair ought to work with const AA's.

https://github.com/dlang/phobos/commit/e4e858bf50e01f7bc9566b6fd56d9e3ff867d1a8
Merge pull request #5668 from quickfur/issue17711

--

[Issue 13512] Allow non-UTF-8 encoding in shebang line

[via Digitalmars-d-bugs]

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

--- Comment #20 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/9f50d033696d686f00527a8b5f8efbb358fc2245
Fix Issue 13512 - Allow non-UTF-8 encoding in shebang line

https://github.com/dlang/dmd/commit/c25d606e7d8db7ed36218328eb37853c79902f39
Add test case for issue 13512

https://github.com/dlang/dmd/commit/48d5ef139b4d1aa874a3094bcccd16114c3f3349
Merge pull request #6959 from CyberShadow/pull-20170702-145440

Fix Issue 13512 - Allow non-UTF-8 encoding in shebang line 
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 17369] [Module std.traits] Documentation lists ditto in table

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/43eadc38e3e31258470b53237db4176876ad54c5
Fix Issue 17369 - [Module std.traits] Documentation lists ditto in table

https://github.com/dlang/phobos/commit/0d7ce7f65969af6cb7c06f1a48ed4ead77194d80
Merge pull request #5558 from RazvanN7/Issue_17369

--

[Issue 9731] Ddoc should output per-paragraph macro instead of $(DDOC_BLANKLINE)

[via Digitalmars-d-bugs]

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/f197169c5a573a3dcef72fac503a35b724775082
Fix Issue 9731 - Ddoc should output per-paragraph macro instead of
$(DDOC_BLANKLINE)

--

[Issue 17540] std.net.curl: HTTP no possibillity to set CURLOPT_NOPROXY

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/e40a35675a89ec9346ba90cf973a423ff8e5d973
Fix Issue 17540 - std.net.curl: HTTP no possibillity to set CURLOPT_NOPROXY

https://github.com/dlang/phobos/commit/1a5ae4aee5a0c4c509ea55dd88e1a26941f932d3
Merge pull request #5538 from RazvanN7/Issue17540

--

[Issue 16744] We should have a TypeOf template so that typeof can be used with templates like staticMap

[via Digitalmars-d-bugs]

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

--- Comment #13 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/d39cc3ff43501a753c14dc1d7461603dc77640ba
Fix Issue 16744: Add Typeof

https://github.com/dlang/phobos/commit/674f87e061ad55a2a2d312b099d32e58404d92ab
Merge pull request #5662 from dlang/MetaLang-patch-1-3

https://github.com/dlang/phobos/commit/be351ebe20df55b72e7441e43b84cfacee42f8ea
Revert "Fix Issue 16744: Add Typeof"

https://github.com/dlang/phobos/commit/f0eaf4456355f3ed68e4fe078663fbb7ccaf46de
Merge pull request #5664 from dlang/revert-5662-MetaLang-patch-1-3

--

[Issue 17388] [scope] e[] should be treated like as far as scope goes

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/fc9c84ba1722c02f0c1877ffa39134c84a5e13e0
fix Issue 17388 - [scope] e[] should be treated like  as far as scope goes

https://github.com/dlang/dmd/commit/09cd19d51b1e000dc81a61d167dc559480958f3e
Merge pull request #7076 from WalterBright/fix17388

--

Re: Named multi-imports

[Johnson via Digitalmars-d]

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?

Re: C++17 Init statement for if/switch

[Guillaume Boucher via Digitalmars-d]

On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
That is correct. After a while it gets tiring to see a 
neverending stream of complexity added to the language while 
things that would actually help (like IDE support) do not get 
any attention.


+1, though I'd go for bug-fixing over IDEs.


I like that.  Feature freeze D until *all* bug reports are closed.
While that would mean no more features for several years, I think 
it would benefit the language in the long run, both internally 
(less discussions about incorrect behavior) and externally (D is 
a mature and stable language).