Re: A pattern I'd like to see more of - Parsing template parameter tuples

[Dmitry Olshansky via Digitalmars-d]

On Monday, 21 May 2018 at 01:53:20 UTC, Manu wrote:
I don't really like that SomeObject() will be instantiated a 
crap load of times for every possible combination and order of 
options that a user might want to supply. How do you control 
the bloat in a way that people won't mess up frequently?


Just sort types by .stringof in a thin forwarding template, we 
have sort in std.meta now.




On 20 May 2018 at 17:58, Neia Neutuladh via Digitalmars-d 
 wrote:

[...]

[Issue 18891] New: extern(C++) destructor prototype should just link; not generate field/aggregate dtor

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18891
   Summary: extern(C++) destructor prototype should just link; not
generate field/aggregate dtor
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

extern(C++) classes with an extern destructor prototype still attempt to
generate __xdtor locally if they have aggregate members.

This functionality should be subverted in the extern(C++) dtor case, because
C++ destructors always perform a full destruction.

--

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:


I wouldn't consider putting classes into own modules a 
workaround. In my opinion it's more or less the solution.


I'll add your solution into my article - but, I'm not sure it 
really addresses my problem statement.


The Problem Statement (being drafted still):
-
In the D programming language, the semantics of the access-level 
modifier 'private' is likely very different to what a large 
number of programmers from object-oriented, and class-oriented 
languages, might expect.


In D, the module (not the class) is the overarching entity, and 
one that encompasses all other entities within the module.


In D, The module can contain (and typically would contain) a 
variety of types - functions, structs, classes and so on.


If a module contains a class type however, and that class has a 
private access modifier on it's members, then that private access 
modifier becomes moot (within the module), because all the 
surrounding code in that module can directly access (and even 
modify) those private members.


The module implicitly morphs a 'private' access modifier, into a 
'private-but-also-module-public' modifier.


The programmer has no control over this implicit conversion of 
the access modifier.


This would be unfamiliar, and unexpected, to a very large number 
of programmers from languages where 'private' has an established 
and well-defined semantic as being the most restrictive form of 
access to a class member.


Unfortunately, in the D programming language, there is simply no 
way to declare a member of a class to be private, and prevent 
surrounding code (within the module) from accessing it.


The D module, will implicitly change the semantics of your code.


The Implications:

..to do

CI buildbots

[Manu via Digitalmars-d]

This CI situation with the DMD/druntime repos is not okay.
It takes ages... **hours** sometimes, for CI to complete.
It's all this 'auto-tester' one, which seems to lock up on the last few tests.

This makes DMD is a rather unenjoyable project to contribute to.
I had a sudden burst of inspiration, but it's very rapidly wearing off.

[Issue 18890] New: extern(C++) mangles all destructors the same

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18890
   Summary: extern(C++) mangles all destructors the same
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

When a class has __dtor and __xdtor, only __xdtor should be mangled
extern(C++). Currently all DtorDeclaration's are mangled the same, which is
bad.

--

[Issue 18890] extern(C++) mangles all destructors the same

[d-bugmail--- via Digitalmars-d-bugs]

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

Manu  changed:

   What|Removed |Added

   Keywords||C++, industry

--

Re: A pattern I'd like to see more of - Parsing template parameter tuples

[Paul Backus via Digitalmars-d]

On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
But the functions, they're a bit trickier. So I made a new 
trait in Binderoo's traits module called ExtractTupleOf. The 
template prototype is the following:


template ExtractTupleOf( alias TestTemplate, Symbols... )

That first parameter is the interesting one. It's essentially 
an uninstantiated template that doubles as a lambda. The 
template is expected to be an eponymous template aliasing to a 
boolean value, and take one parameter (although, theoretically, 
a CTFE bool function(T)() would also work). ExtractTupleOf will 
static foreach over each symbol in Symbols, and static if( 
TestTemplate!Symbol ) each one. If it returns true, then that 
symbol is extracted and put in a new tuple.


Am I missing something, or is this the same thing as `std.meta: 
Filter`?

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Sunday, 20 May 2018 at 11:19:01 UTC, Dave Jones wrote:

On Sunday, 20 May 2018 at 02:45:25 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 17:38:48 UTC, Gheorghe Gabriel 
wrote:


But in D, everything is your friend - you don't get to manage


You want to be taken seriously and yet you repeat false 
statements over and over again.



There is absolutely no reason why D cannot have both (the 
current way D does it, and the C++ way). It's obviously 
technically possible.


Being technically possible or even easy to implement is not an 
argument for including something.



It's obvious it would attract a great deal more programmers to 
D.


Pure conjecture. You don't know why people choose not to use D, 
you know why you choose not to use it. Assuming your opinion is 
shared by all these supposed people is at best naive at worst 
an indication of narcissism.


I'll assume for now that you are young, idealistic and naive.


It doesn't really complicate the language at all - that's just 
an excuse not to change. And, it's obvious, that protecting 
the interface would result in better quality software. It's a 
core fundamental principle of quality software.


It's just a matter of getting more diverse people into the D 
'community'.


Yes because if a group of people don't accept your argument 
about something obviously there is something wrong with them.


OK it's starting to look more like narcissism.


But I get the feeling that's not what most D people want. The 
status quo is pretty comfortable for many, it seems.


No shit... you're just getting that feeling now? You remind me 
of my teenage son, it takes about 100 times of telling him 
something before it sticks in his head.


Let me ask you this...

How do you get comfortable with something? By using it, trying 
it, and finding that it works. You don't get comfortable with 
having a stone in your shoe, so if this feature was the 
nightmare you say it is all these people using D wouldn't be OK 
with it.


But again it's utterly pointless because you cannot grasp that. 
You are unable to even consider that something "other" might 
work. You are a zealot in that respect, that's why you 
exaggerate, misrepresent the other side of the argument, 
predict doom for the heathens, and never budge on your position.


Anyway... feel free to misrepresent what I've said, engage in 
hyperbole, snip the parts you cant argue with, speak for all 
the people who chose not to use D, tell D it's doomed if they 
don't do what you say, it'll never be popular, that it's all 
idiotic. Etc...


Come on Dave.

18+ years, and still less than 1000 programmers.

As I've said, I can have more that one class in a file in a 
variety of different mainstream languages, which represent about 
20 million developers, and still have the compiler protect that 
interface from abuse, including accidental misuse.


You cannot get this in D, and yet 20 million developers have had 
this for decades.


When they come over to D, their' told, stuff you, we don't do it 
that way in D, and btw, we don't care about your ideas on how we 
could easily get D to do it both ways. We prefer our own way, so 
you get stuffed.


That's kind of what I've hearing from the D community.

Of course, that kind of attitude can only invite the same 
attitude back to the D community.


Let's hope you truly don't represent the D community, cause then 
my comments are not hyperbole, they are fact.

[Issue 18819] DMD compilation crash

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Mike Franklin  ---
>  but I can't reproduce it locally from DMD-Head (Linux 64-bit).

Disregard that; I had code for https://github.com/dlang/dmd/pull/8260 in my
local copy.

That being said https://github.com/dlang/dmd/pull/8260 seems to fix this.

--

[Issue 18889] New: Hovering over the alias of an enum doesn't show it's value

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18889
   Summary: Hovering over the alias of an enum doesn't show it's
value
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

-
enum ENUMTY : int
{
Tstruct = 8
}
alias Tstruct = ENUMTY.Tstruct;

void main()
{
ENUMTY x;
if (x == Tstruct) // PUT BREAKPOINT HERE
return;
return;
}
--

place a breakpoint at that line... if you hover over Tstruct, it would be
really nice to see the value (ie, 8).

--

Re: Temporary file creation for unittests

[Joakim via Digitalmars-d-learn]

On Friday, 18 May 2018 at 15:16:52 UTC, Russel Winder wrote:

Hi,

What's the current official position on how to create temporary 
files for use during a unittest. I found


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

but it seems to be languishing in the "we have discussed all 
the issues that no-one will ever have a problem with" phase.


What to do between now and when there is an LDC release that 
has the result of

the merge?


You could use std.file.deleteme, which is what the Phobos 
unittests use:


https://github.com/dlang/phobos/blob/master/std/file.d#L117

Re: auto: useful, annoying or bad practice?

[Charles Hixson via Digitalmars-d]

auto has its uses, but it's wildly overused, especially in library code 
and documentation, and really, really, *really* much so in documentation 
examples.



On 05/01/2018 06:09 AM, Craig Dillabaugh via Digitalmars-d wrote:

On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
I'll freely admit I haven't put a ton of thought into this post 
(never a good start), however I'm genuinely curious what people's 
feeling are with regards to the auto keyword.


Speaking for myself, I dislike the auto keyword. Some of this is 
because I have a preference for static languages and I find auto adds 
ambiguity with little benefit. Additionally, I find it annoying that 
the phobos documentation relies heavily on auto obscuring return 
types and making it a bit more difficult to follow what is happening 
which gives me a bad taste for it.



clip


So I'm curious, what's the consensus on auto?


As some have pointed out, it certainly has value. For example, in 
functions returning ranges, etc. where you wouldn't want to have to 
write out the whole type.


However, as an infrequent D user I admit I prefer to see the actual 
type where it is feasible, as I find 'auto' is a barrier to 
understanding to someone who isn't familiar with a particular piece of 
code.  I would never use auto in place of a basic type.

Re: C style callbacks fix for member callbacks

[ag0aep6g via Digitalmars-d-learn]

I tried this. Your code crashes in windows dmd x86 x64.


Hm. Works for me in a virtual machine. But I'm not surprised that it's 
fragile. It might be completely wrong, and it just happens to look 
alright on my machine.

[Issue 17035] extern(C) and extern(C++) module ctor/dtor should behave like the C init/fini functions

[d-bugmail--- via Digitalmars-d-bugs]

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

Manu  changed:

   What|Removed |Added

 CC||turkey...@gmail.com

--- Comment #2 from Manu  ---
This please!
I've just run into a case of this.

--

Re: A pattern I'd like to see more of - Parsing template parameter tuples

[Manu via Digitalmars-d]

I don't really like that SomeObject() will be instantiated a crap load
of times for every possible combination and order of options that a
user might want to supply. How do you control the bloat in a way that
people won't mess up frequently?

On 20 May 2018 at 17:58, Neia Neutuladh via Digitalmars-d
 wrote:
> On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
>>
>> Code for context:
>> https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d
>
>
> This looks good. One small caveat:
>
> alias DocumentType = SomeDocument!(ObjectVersion._1_0, ObjectEncoding.UTF8);
> alias DocumentType2 = SomeDocument!(ObjectEncoding.UTF8,
> ObjectVersion._1_0);
>
> These are not the same type; they're two identical types with different
> mangles. You can fix that with a layer of indirection:
>
> template SomeDocument(Options...)
> {
>   alias SomeDocument = SomeDocumentImpl!(OptionsOf!(DocumentParams,
> Options));
> }

Re: Help with DMD internals

[Manu via Digitalmars-d]

On 20 May 2018 at 17:14, Walter Bright via Digitalmars-d
 wrote:
> On 5/20/2018 12:28 PM, Manu wrote:
>>
>>Is re-initialisation to 'init' part of destruction,
>
>
> No.
>
>> or is it a
>> separate post-process? (I feel it's a post-process)
>
>
> Yes, and only for delete.

destroy() also seems to do it.

Re: C style callbacks fix for member callbacks

[IntegratedDimensions via Digitalmars-d-learn]

On Sunday, 20 May 2018 at 23:05:47 UTC, ag0aep6g wrote:

On 05/20/2018 06:48 PM, IntegratedDimensions wrote:
alias callback = extern(C) int function(const(void) a, void 
*b, uint c, void* context);


(I'm assuming that `a` is supposed to be a `const(void)*`.)


Where context acts as this.

I would like to assign a D method to this callback.

class
{
    callback c;
    /*extern(C) static*/ int foo(const(void) a, void *b, uint 
c, void* context);


    this() { c = cast(callback) }
}


Unless I'm misunderstanding it, the spec seems to say that the 
`this` pointer is passed as if it was an additional parameter 
past the last one [1].


But that doesn't seem to be true in the implementation. At 
least on Linux x86-64, `this` seems to be a hidden first 
parameter. So when a method is called as a `callback`, `a` 
becomes `this`, `b` becomes the first explicit parameter, `c` 
the second, and `context` the third. So this works:



import std.stdio;

alias Callback = extern(C) int function(const(void)* a, void* 
b, uint c,

void* context);

class C
{
int field = 43;
extern(C) int foo(void* b, uint c, C this_)
{
const(void)* a = cast(void*) this;
writeln(a, " ", b, " ", c, " ", this_.field);
return 0;
}
}

void main()
{
void* a = new int;
void* b = new int;
uint c = 42;
auto obj = new C;
Callback cb = cast(Callback) ().funcptr;
cb(a, b, c, cast(void*) obj);
writeln(a, " ", b, " ", c, " ", obj.field);
/* For comparison. Should print the same. */
}


This is all very hacky, of course. And I don't really know what 
I'm doing there. So obviously, I don't recommend doing this.


But other than hacking it like that, I don't think you can pass 
a method as a `callback` directly.



[1] https://dlang.org/spec/abi.html#parameters


I tried this. Your code crashes in windows dmd x86 x64.

It really shouldn't be hacky. The only difference is the "this" 
is implicit normally when in this case it is explicit and 
possibly in a different location than one expects.

Re: A pattern I'd like to see more of - Parsing template parameter tuples

[Neia Neutuladh via Digitalmars-d]

On Monday, 21 May 2018 at 00:13:26 UTC, Ethan wrote:
Code for context: 
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d


This looks good. One small caveat:

alias DocumentType = SomeDocument!(ObjectVersion._1_0, 
ObjectEncoding.UTF8);
alias DocumentType2 = SomeDocument!(ObjectEncoding.UTF8, 
ObjectVersion._1_0);


These are not the same type; they're two identical types with 
different mangles. You can fix that with a layer of indirection:


template SomeDocument(Options...)
{
  alias SomeDocument = 
SomeDocumentImpl!(OptionsOf!(DocumentParams, Options));

}

A pattern I'd like to see more of - Parsing template parameter tuples

[Ethan via Digitalmars-d]

Code for context: 
https://github.com/GooberMan/binderoo/blob/master/binderoo_client/d/src/binderoo/util/enumoptions.d


Something struck me at DConf. I was watching the dxml talk and 
hearing about all these things that weren't being implemented for 
one reason or another. And I was thinking, "But what if I want 
those things?" Being D, it'd be pretty easy to opt in to them 
with template parameters and static if controlling what code gets 
executed at runtime.


But that brings up a bit of an annoying thing. Namely, the old 
school way of doing such things:


class SomeObject( bool option1, bool option2, Flags iHateBools = 
Flags.Default, int 
ohIDontWantThisToBeDefaultedButRefactoringSucks = -1 )

{
}

Pretty obnoxious design pattern.

But we're in D. We can do much better. It makes sense to do the 
following:


class SomeObject( LooseOptions... )
{
}

Much nicer. But how do we go about dealing with that? Static 
foreach each time we want something? One time parse and cache the 
values? Both are laborious in their own way. What we want is some 
helper objects to make sense of it all.


This is where my EnumOptions struct comes in. The idea here is 
that all the options you want as booleans, you put them in an 
enum like so:


enum SomeOptions
{
  Option1,
  Option2,
  Option5,
  Option3Sir,
  Option3
}

And then instantiate your class like so:

alias SomeInstantiatedObject = SomeObject!( SomeOptions.Option1, 
SomeOptions.Option2, SomeOptions.Option3 );


And inside your class definition, you clean it up automagically 
with a nice little helper function I made:


class SomeObject( LooseOptions... )
{
  enum Options = OptionsOf( SomeOptions, LooseOptions );
}

This resolves to an EnumOptions struct that parses all members of 
an enumeration, and generates bits in a bitfield for them and 
wraps it all up with properties. So now the following is possible:


static if( Options.Option1 )
{
  // Do the slow thing that I would like supported
}

Now, if you've been able to keep up here, you might have noticed 
something. Your class has a variable template parameter list. 
Which means we can throw anything in there. The plot thickens. 
This means you can go one step further and make your options 
actually human readable:


enum ObjectVersion
{
  _1_0,
  _1_1,
  _2_0,
}

enum ObjectEncoding
{
  UTF8,
  UTF16,
  UTF32,
  PlainASCII,
  ExtendedASCII,
}

class SomeDocument( Options... )
{
  enum Version = OptionsOf( ObjectVersion, Options );
  enum Encoding = OptionsOf( ObjectVersion, Options );
}

alias DocumentType = SomeDocument!( ObjectVersion._1_0, 
ObjectEncoding.PlainASCII );
alias DocumentType2 = SomeDocument!( ObjectEncoding.UTF8, 
ObjectVersion._2_0 );


Pretty, pretty, pretty good.

With this in the back of my mind, I've been able to expand 
Binderoo's module binding to be a bit more user friendly. I've 
got a new BindModules mixin, which unlike the existing mixins are 
more of a pull-in system rather than a push-in system. Basically, 
rather than BindModule at the bottom of each module, you put a 
single BindModules at the bottom of one module and list every 
module you want as a parameter to it.


The mixin needs to do a few things though. The list of modules is 
one thing. A bunch of behaviour options is another. And, since 
the mixin adds a static shared this, a list of functions that 
need to be executed for module initialisation. The first two are 
pretty easy to deal with:


enum Modules = ExtractAllOf!( string, Options );
enum BindOptions = OptionsOf!( BindOption, Options );

But the functions, they're a bit trickier. So I made a new trait 
in Binderoo's traits module called ExtractTupleOf. The template 
prototype is the following:


template ExtractTupleOf( alias TestTemplate, Symbols... )

That first parameter is the interesting one. It's essentially an 
uninstantiated template that doubles as a lambda. The template is 
expected to be an eponymous template aliasing to a boolean value, 
and take one parameter (although, theoretically, a CTFE bool 
function(T)() would also work). ExtractTupleOf will static 
foreach over each symbol in Symbols, and static if( 
TestTemplate!Symbol ) each one. If it returns true, then that 
symbol is extracted and put in a new tuple.


What does this mean? It means I can do this:

import std.traits : isSomeFunction;
mixin BindModuleStaticSetup!( ExtractTupleOf!( isSomeFunction, 
Options ) );


All of this is very definitely well in the real of "Let's see you 
do that in the hour it took me to throw it all together, C++!" 
territory. And I'd really like to see people pick up this pattern 
rather than emulate the old ways.

Re: Help with DMD internals

[Walter Bright via Digitalmars-d]

On 5/20/2018 12:28 PM, Manu wrote:

   Is re-initialisation to 'init' part of destruction,


No.


or is it a
separate post-process? (I feel it's a post-process)


Yes, and only for delete.

[Issue 18888] New: extern(C++) template arg/alias arg mangling issue

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 1
   Summary: extern(C++) template arg/alias arg mangling issue
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

This C++ code:
--
template 
struct TemplateName
{
void fun() {}
};

template