Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 13 May 2018 at 16:23:49 UTC, Nikos wrote:
I'm trying to wrap drepl 
(https://github.com/dlang-community/drepl)


My dub.sdl files is


import autowrap.python;
mixin(
   wrapAll(
   LibraryName("drepl"),
   Modules("drepl.interpreter"),
   )
);


I also flagged `export` the interpreter function

export Interpreter!Engine interpreter(Engine)(return scope 
Engine e) if (isEngine!Engine)

{
   // workaround Issue 18540
   return Interpreter!Engine(() @trusted { return move(e); 
}());

}


I build the library with python35, but when I import it from 
python idle, I cannot access the `interpreter` function at all.
I have the feeling I miss something essential here, but I don't 
know what it is.

Any ideas?


Eg turn this into a function and try wrapping this instead:

auto intp = interpreter(dmdEngine());

[Issue 18815] thread_attachThis crash

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

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

--- Comment #2 from Manu  ---
This is kinda critical...

--

Re: LDC 1.10.0 beta

[master via Digitalmars-d-announce]

On Sunday, 13 May 2018 at 18:12:51 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce the first beta 
for LDC 1.10. The highlights of this version in a nutshell:


* Based on D 2.080.0.
* Supports DragonFly BSD.
* Some fixes, most notably wrt. exception stack traces on Linux.

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.10.0-beta1


Thanks to all contributors!


very good, come on! i mainly use LDC to work now.

Re: Building a standalone druntime for LDC

[Joakim via Digitalmars-d]

On Sunday, 13 May 2018 at 14:59:39 UTC, Seb wrote:

On Sunday, 13 May 2018 at 13:37:06 UTC, A. Nicholi wrote:

Hello,

I am trying to build LDC’s druntime by itself (without 
phobos), but it seems that druntime expects to be built 
alongside DMD, which is strange considering I’m building LDC’s 
version of the druntime. Make says: “No rule to make target 
'../dmd/src/osmodel.mak'”


That means that DMD hasn't been checked out in ../dmd relative 
to druntime as osmodel.mak is in DMD.


More importantly, ldc's druntime fork doesn't use those 
Makefiles, they're just lying around from upstream. You can't use 
them to build a druntime for LDC, as they're missing LDC-specific 
files.


He can use the tool David linked above or investigate the CMake 
targets that LDC uses:


https://wiki.dlang.org/Building_LDC_from_source

Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile

[Jonathan M Davis via Digitalmars-d]

On Monday, May 14, 2018 00:04:20 Uknown via Digitalmars-d wrote:
> On Sunday, 13 May 2018 at 23:53:58 UTC, Vijay Nayar wrote:
> > I encountered a very unexpected error when working on a
> > project.  It seems that the Appender and RefAppender structs
> > created from the std.array.appender() method are sensitive to
> > the mere presence of a method called "init()" on the element
> > type of the array.
> >
> > [...]
>
> init is a reserved function. T.init is the initial value for a
> type. int.init is 0 and float.init is NaN. Try changing your
> function name to initialise or something like that.

Yeah. It's been discussed that it should be illegal to declare a struct or
class member named init, but that change has yet to happen.

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

That mistake was even made in some places in druntime and Phobos (e.g.
TypeInfo in druntime and DirEntry in Phobos), and it caused problems. Those
uses had to be fixed before we could look at actually making it illegal, and
AFAIK, they've all been fixed, but the compiler has yet to be changed. I
don't know if a DIP would be required or not though before it could happen.
It was kind of informally agreed that it should be illegal to declare init,
but I don't think that it was ever officially agreed upon. Regarldless,
declaring init just causes bugs, and code shouldn't do it.

- Jonathan M Davis

Re: Exceptions without GC/Dynamic allocation. New proposal from Herb Sutter for C++

[Uknown via Digitalmars-d]

On Sunday, 13 May 2018 at 17:21:28 UTC, Ben Jones wrote:
I think similar ideas have been discussed around here before 
(https://forum.dlang.org/thread/stlslhjndgugecvmb...@forum.dlang.org) but here's a new C++ proposal for overhauling their exception system to avoid dynamic allocation for exceptions.  I guess it's not surprising that they're dealing with similar issues for exception handing as the D community.

[...]


Worth mentioning that DIP 1008 makes exceptions Ref-counted 
instead of GC managed, so exceptions can now be @nogc in D

Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile

[Uknown via Digitalmars-d]

On Sunday, 13 May 2018 at 23:53:58 UTC, Vijay Nayar wrote:
I encountered a very unexpected error when working on a 
project.  It seems that the Appender and RefAppender structs 
created from the std.array.appender() method are sensitive to 
the mere presence of a method called "init()" on the element 
type of the array.


[...]


init is a reserved function. T.init is the initial value for a 
type. int.init is 0 and float.init is NaN. Try changing your 
function name to initialise or something like that.

Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile

[Vijay Nayar via Digitalmars-d]

I encountered a very unexpected error when working on a project.  
It seems that the Appender and RefAppender structs created from 
the std.array.appender() method are sensitive to the mere 
presence of a method called "init()" on the element type of the 
array.


Here is a minimal example:

```
import std.array;

struct S1 {
  // The mere presence of this method causes the error, deleting 
it fixes the error.

  void init(string p1, int p2, int p3) { }
}

struct S2 {
  S1[] a;
  RefAppender!(int[]) getAppender() {
return appender();
  }
}

void main() { }
```

The compiler produces the following output:
```
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(2907): Error: 
cannot have array of `void(string, int, int)`
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(2976): Error: 
cannot have array of `inout void(string, int, int)`
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3369): Error: 
template instance `std.array.Appender!(S1[])` error instantiating
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3879):
instantiated from here: `RefAppender!(S1[])`
onlineapp.d(12):instantiated from here: `appender!(S1[]*, 
S1)`
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3429): Error: 
cannot have array of `inout void(string, int, int)`

```

Is this a bug or a misunderstanding on my part?

Re: serialport v1.0.0

[Andre Pany via Digitalmars-d-announce]

On Sunday, 13 May 2018 at 18:05:35 UTC, Jonathan M Davis wrote:
On Sunday, May 13, 2018 17:57:56 Andre Pany via 
Digitalmars-d-announce wrote:

On Sunday, 6 May 2018 at 22:02:05 UTC, Oleg B wrote:
> Stable version of serialport package
>
> * Blocking `SerialPortBlk` for classic usage
>
> * Non-blocking `SerialPortNonBlk` and `SerialPortFR` for 
> usage in fibers or in vibe-d

>
> * Variative initialization and configuration
>
> * Hardware flow control config flag
>
> Doc: http://serialport.dpldocs.info/v1.0.0/serialport.html
> Dub: http://code.dlang.org/packages/serialport
> Git: https://github.com/deviator/serialport

Thanks for this library. The announcement is at the right time 
as I want to write a smart home application to control my 
shutters. The application will run on a raspberry pi (ftdi sub 
stick).



So, now we'll be able to hack your shutters? ;)

Do you thought about including your library into phobos? A std 
library really should contain this functionality.


Really? If the consensus is that it should go in, then okay, 
but I don't think that I've ever seen a standard library with 
anything like functionality for talking to serial ports. And 
what would having it be in Phobos buy you over just grabbing it 
from code.dlang.org?


- Jonathan M Davis


Hopefully not:)

For me it is just a convenience reason. I would not have to 
search dub registry for serial libraries and try them out.
For functionality included in Phobos I know they were reviewed by 
several developers and therefore have high code quality and only 
few bugs.


Kind regards
Andre

Re: LDC 1.10.0 beta

[Per Nordlöw via Digitalmars-d-announce]

On Sunday, 13 May 2018 at 18:12:51 UTC, kinke wrote:

* Based on D 2.080.0.


Great!

LDC 1.10.0 beta

[kinke via Digitalmars-d-announce]

Hi everyone,

on behalf of the LDC team, I'm glad to announce the first beta 
for LDC 1.10. The highlights of this version in a nutshell:


* Based on D 2.080.0.
* Supports DragonFly BSD.
* Some fixes, most notably wrt. exception stack traces on Linux.

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.10.0-beta1


Thanks to all contributors!

Re: serialport v1.0.0

[Jonathan M Davis via Digitalmars-d-announce]

On Sunday, May 13, 2018 17:57:56 Andre Pany via Digitalmars-d-announce 
wrote:
> On Sunday, 6 May 2018 at 22:02:05 UTC, Oleg B wrote:
> > Stable version of serialport package
> >
> > * Blocking `SerialPortBlk` for classic usage
> >
> > * Non-blocking `SerialPortNonBlk` and `SerialPortFR` for usage
> > in fibers or in vibe-d
> >
> > * Variative initialization and configuration
> >
> > * Hardware flow control config flag
> >
> > Doc: http://serialport.dpldocs.info/v1.0.0/serialport.html
> > Dub: http://code.dlang.org/packages/serialport
> > Git: https://github.com/deviator/serialport
>
> Thanks for this library. The announcement is at the right time as
> I want to write a smart home application to control my shutters.
> The application will run on a raspberry pi (ftdi sub stick).


So, now we'll be able to hack your shutters? ;)

> Do you thought about including your library into phobos? A std
> library really should contain this functionality.

Really? If the consensus is that it should go in, then okay, but I don't
think that I've ever seen a standard library with anything like
functionality for talking to serial ports. And what would having it be in
Phobos buy you over just grabbing it from code.dlang.org?

- Jonathan M Davis

Re: Module-level privacy

[Jonathan M Davis via Digitalmars-d]

On Sunday, May 13, 2018 17:19:26 rumbu via Digitalmars-d wrote:
> On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote:
> > Also, someone may say: I can see what happens in one and the
> > same file. If there are two classes/structs in one file, they
> > are "friends" and I dont need the "friend"-keyword anymore.
> > Thats an argument, too.
>
> So, when you have 1000 classes, you just create 1000 files just
> to "unfriend" them :)

Which is basically what you get in Java, though no one should be putting
1000 classes in a single module anyway. But if you want to make it so that
classes can't access each other's members while still making it possible to
import them together, then all you have to do is have a module which
publicly imports all of those other modules which have one class each.

The only thing that you really lose with D's approach as opposed to friend
is that D doesn't provide a way to mark something from another module as a
friend. package at least partially solves that problem though. Really, what
D went with is similar to what Java did, only it's more flexible, because it
doesn't restrict what can go in a module, whereas Java only allows one
public class per module and doesn't have any free functions.

Ultimately, D's solution simplifies things over what C++ did with friends
while giving you basically the same level of control. It's just that if you
don't want something to be able to access the private members of a class or
struct, that symbol must be in a separate module. So, if you _really_ don't
want anything accessing the internals of your class or struct, but you want
to be able to stick stuff in the same file, then that can get annoying,
because you can't do that. But public imports let you make it so that you
can still import them as one even if they're not actually in the same file,
and many of us have found that having the default be that other stuff in the
module can access the private members to be very useful - especially with
regards to testing.

I fully expect that if we added some sort of "super private" that really
made it so that nothing outside a class or struct could access its members,
almost no one would use it, and it wouldn't really solve much in the way of
real problems, much as I'm sure that a few folks like KingJoffrey would be
quite happy to have something like that.

Ultimately, there are tradeoffs between what C++ did and what D did, and
neither approach is perfect, so some folks are likely to be happier with one
approach over the other, but overall, what D has done has worked extremely
well for D.

- Jonathan M Davis

Re: serialport v1.0.0

[Andre Pany via Digitalmars-d-announce]

On Sunday, 6 May 2018 at 22:02:05 UTC, Oleg B wrote:

Stable version of serialport package

* Blocking `SerialPortBlk` for classic usage

* Non-blocking `SerialPortNonBlk` and `SerialPortFR` for usage 
in fibers or in vibe-d


* Variative initialization and configuration

* Hardware flow control config flag

Doc: http://serialport.dpldocs.info/v1.0.0/serialport.html
Dub: http://code.dlang.org/packages/serialport
Git: https://github.com/deviator/serialport


Thanks for this library. The announcement is at the right time as 
I want to write a smart home application to control my shutters. 
The application will run on a raspberry pi (ftdi sub stick).


Do you thought about including your library into phobos? A std 
library really should contain this functionality.


Kind regards
Andre

Exceptions without GC/Dynamic allocation. New proposal from Herb Sutter for C++

[Ben Jones via Digitalmars-d]

I think similar ideas have been discussed around here before 
(https://forum.dlang.org/thread/stlslhjndgugecvmb...@forum.dlang.org) but here's a new C++ proposal for overhauling their exception system to avoid dynamic allocation for exceptions.  I guess it's not surprising that they're dealing with similar issues for exception handing as the D community.


I didn't dig too deep,  but it looks like a pretty reasonable 
approach, except for requiring extra annotations for exceptions 
specification.


Here's the r/cpp thread where they're discussing the paper (with 
a link): 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

Re: Module-level privacy

[rumbu via Digitalmars-d]

On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote:

Also, someone may say: I can see what happens in one and the 
same file. If there are two classes/structs in one file, they 
are "friends" and I dont need the "friend"-keyword anymore.

Thats an argument, too.


So, when you have 1000 classes, you just create 1000 files just 
to "unfriend" them :)

Re: serialport v1.0.0

[Oleg B via Digitalmars-d-announce]

On Wednesday, 9 May 2018 at 14:41:45 UTC, Andrea Fontana wrote:

On Sunday, 6 May 2018 at 22:02:05 UTC, Oleg B wrote:

Stable version of serialport package

* Blocking `SerialPortBlk` for classic usage

* Non-blocking `SerialPortNonBlk` and `SerialPortFR` for usage 
in fibers or in vibe-d


* Variative initialization and configuration

* Hardware flow control config flag

Doc: http://serialport.dpldocs.info/v1.0.0/serialport.html
Dub: http://code.dlang.org/packages/serialport
Git: https://github.com/deviator/serialport


I wonder if someone can benchmark serialport lib against this 
test:

http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/


I think it's different things.
serialport is wrap around system calls, it's not control hardware 
directly.
You could be misled by the phrase about 'hardware flow control': 
is't set on or off using of RTS and CTS pins of UART. Firmware 
control RTS and CTS pins directly.

http://www.brainboxes.com/faq/items/what-is-rts--cts-hardware-flow-control-

Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel

[Nikos via Digitalmars-d-announce]

I'm trying to wrap drepl 
(https://github.com/dlang-community/drepl)


My dub.sdl files is


import autowrap.python;
mixin(
   wrapAll(
   LibraryName("drepl"),
   Modules("drepl.interpreter"),
   )
);


I also flagged `export` the interpreter function

export Interpreter!Engine interpreter(Engine)(return scope 
Engine e) if (isEngine!Engine)

{
   // workaround Issue 18540
   return Interpreter!Engine(() @trusted { return move(e); }());
}


I build the library with python35, but when I import it from 
python idle, I cannot access the `interpreter` function at all.
I have the feeling I miss something essential here, but I don't 
know what it is.

Any ideas?

Re: Dependency injection pattern

[Jesse Phillips via Digitalmars-d-learn]

On Sunday, 13 May 2018 at 07:42:10 UTC, Suliman wrote:
Could anybody give small example of Dependency injection 
pattern? I googled about it, but found only C# examples and I 
am not quite sure how to use them.


Also I would like get some explanation/comments for code.


Here is a quick example of the difference, myProgram.execute 
utilizes a database connection.
dInjection.execute utilizes a dependency injected database 
connection.



class dbConnection {}

class myProgram {
void execute() {
auto db = new dbConnection();
//...
}
}

class dInjection {
void execute(dbConnection db) {
//...
}
}


What you should notice from the first execute function is that 
the dependency, in this case dbConnection, is created as part of 
the application execution. While the second the dependency is 
declared at the function's arguments allowing the caller to 
inject the needed dependency.


This could go a step further and accept an interface for DB 
connections, but is not necessary to meat dependency injection.


Dependency injection also applies to magic numbers.

enum maxProcessingTime = 3582;

If this were declared inside a function rather than taken as a 
parameter, then the function would not correctly use dependency 
injection.


Additionally, you could inject the dbConnection as part of the 
class constructor:


--
class preInjection {
dbConnection db;
this(dbConnection data) { db = data}
void execute() {
//...
}
}

--

Now I think what trips a lot of people up is that frameworks are 
created to help you do this. They try to make it easy to define 
all your dependencies in a single location and then you request 
the object you need and the DI framework will do whatever it 
needs to for building that object.

Re: Module-level privacy

[meppl via Digitalmars-d]

On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote:

On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:

[...]


First, this thread was about extending the capabilities of 
classes in D with some new attribute/capability - sealed.


I thought it was first important to point out, in this thread, 
as opposed to a separate thread, that classes in D are already 
problematic, because modules do not respect the encapsulation 
boundaries of classes, and any discussion about further 
extending classes should be approached with great caution - 
because the problem will only become even more entrenched.


Second, writing a DIP is pointless, since Walter likes the idea 
that the module doesn't protect the encapsulation boundary of 
the class. Now if Walter thinks that's fine, what is a DIP 
going to do? I mean really. I have better things to do.


Third, those who responded to my caution are the ones that 
should have created a separate thread, not me.


Finally (and I do mean finally), my concern about the loss of 
the encapsulation boundary of classes in D, has a very real 
impact on the quality and maintainability of software systems 
developed in D. That the designer of D apparently thinks 
otherwise, baffles me.


walter bright was not the only one who liked that idea of "only 
module level encapsulation". Its unfair to imply it like that.
Also, someone may say: I can see what happens in one and the same 
file. If there are two classes/structs in one file, they are 
"friends" and I dont need the "friend"-keyword anymore.

Thats an argument, too.

Re: Building a standalone druntime for LDC

[Seb via Digitalmars-d]

On Sunday, 13 May 2018 at 13:37:06 UTC, A. Nicholi wrote:

Hello,

I am trying to build LDC’s druntime by itself (without phobos), 
but it seems that druntime expects to be built alongside DMD, 
which is strange considering I’m building LDC’s version of the 
druntime. Make says: “No rule to make target 
'../dmd/src/osmodel.mak'”


That means that DMD hasn't been checked out in ../dmd relative to 
druntime as osmodel.mak is in DMD.

Re: Building a standalone druntime for LDC

[David Nadlinger via Digitalmars-d]

On Sunday, 13 May 2018 at 13:37:06 UTC, A. Nicholi wrote:
I am trying to build LDC’s druntime by itself (without phobos) 
[…] Make says: “No rule to make target '../dmd/src/osmodel.mak'”


LDC uses its own CMake-based build system for druntime/Phobos, 
see runtime/CMakeLists.txt I'm the main repository.


The ldc-build-runtime tool streamlines (re)building certain 
runtime versions without having to manually manage the build 
process: https://wiki.dlang.org/Building_LDC_runtime_libraries


 —David

[Issue 18827] scope delegate literal allocates GC closure

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

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

johanenge...@weka.io changed:

   What|Removed |Added

   Keywords||industry
 CC||johanenge...@weka.io

--

Re: Module-level privacy

[bauss via Digitalmars-d]

On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote:

On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:
Nobody's getting worked up about this, and nobody's telling 
you to stop talking about it. There have been suggestions that 
you write up a DIP for it. This is a standard process for 
suggesting improvements to D.


Your complaint is about protection, not about classes. It 
should affect all definitions. Perhaps you simply don't expect 
type-level encapsulation for structs and top-level 
declarations.


First, this thread was about extending the capabilities of 
classes in D with some new attribute/capability - sealed.


I thought it was first important to point out, in this thread, 
as opposed to a separate thread, that classes in D are already 
problematic, because modules do not respect the encapsulation 
boundaries of classes, and any discussion about further 
extending classes should be approached with great caution - 
because the problem will only become even more entrenched.


Second, writing a DIP is pointless, since Walter likes the idea 
that the module doesn't protect the encapsulation boundary of 
the class. Now if Walter thinks that's fine, what is a DIP 
going to do? I mean really. I have better things to do.


Third, those who responded to my caution are the ones that 
should have created a separate thread, not me.


Finally (and I do mean finally), my concern about the loss of 
the encapsulation boundary of classes in D, has a very real 
impact on the quality and maintainability of software systems 
developed in D. That the designer of D apparently thinks 
otherwise, baffles me.


Walter is not the only person who accepts DIP and although he's 
the core head of D, it doesn't mean all his opinions are strictly 
100% how D is going to evolve. I'm sure there are plenty of 
features that has been implemented that he does not entirely 
agree with and the same goes for others.


If you can write a DIP and have a good use case for it, other 
than a very rare usecase, then it would most likely be accepted, 
IF the language would benefit from the addition.


Writing posts about how you don't like feature X is way more 
useless than a DIP, because it will NOT change anything.

Building a standalone druntime for LDC

[A. Nicholi via Digitalmars-d]

Hello,

I am trying to build LDC’s druntime by itself (without phobos), 
but it seems that druntime expects to be built alongside DMD, 
which is strange considering I’m building LDC’s version of the 
druntime. Make says: “No rule to make target 
'../dmd/src/osmodel.mak'”


Is it possible to build druntime by itself for LDC? Must I build 
LDC alongside it for every host platform, or may I just specify 
‘-defaultlib=’ with a distro-provided LDC? How should I go about 
doing this?

[Issue 18856] New: [std.experimental.logger] please add LogLevel.debug

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

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

  Issue ID: 18856
   Summary: [std.experimental.logger] please add LogLevel.debug
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/phobos/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: singingb...@hotmail.com

it would be helpful if the standard logger supported LogLevel.debug, it would
make it easier to hook in to vibe.core.log

https://github.com/mysql-d/mysql-native/issues/113
https://github.com/vibe-d/vibe.d/issues/1530

--

Re: Why The D Style constants are written in camelCase?

[Q. Schroll via Digitalmars-d-learn]

On Wednesday, 9 May 2018 at 09:38:14 UTC, BoQsc wrote:
The D Style suggest to camelCase constants, while Java naming 
conventions always promoted uppercase letter.


Is there an explanation why D Style chose to use camelCase 
instead of all UPPERCASE for constants, was there any technical 
problem that would appear while writing in all UPPERCASE?




Java language references:
https://en.wikipedia.org/wiki/Naming_convention_(programming)#Java
https://www.javatpoint.com/java-naming-conventions
http://www.oracle.com/technetwork/java/codeconventions-135099.html
https://medium.com/modernnerd-code/java-for-humans-naming-conventions-6353a1cd21a1



D lang reference:
https://dlang.org/dstyle.html#naming_constants


It is really helpful to write generic code. E.g. you use 
`myRange.empty` and you do not care what `empty` actually is. The 
range could be infinite and define `enum empty = false;` If you 
use an uppercase identifier like `EMPTY`, generic code breaks; if 
you don't but do otherwise, where is the boundary? The only 
solution is, you don't spell it different if something is a 
compile-time constant or not.
It is even possible that some name can refer to a type, which is 
usually spelled with the first letter uppercase, or a value.
On [1] it reads: `hook` is a member variable [of type `Hook`] if 
it has state, or an alias for `Hook` [the type itself] otherwise.
So, generally, anything is spelled camelCase except declared 
types as classes, interfaces, structs, unions, and aliases for 
things definitely known to be types.


[1] 
https://dlang.org/phobos/std_experimental_checkedint.html#.Checked.hook

[Issue 18855] New: Behavior of Anonymous Union is Undocumented

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

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

  Issue ID: 18855
   Summary: Behavior of Anonymous Union is Undocumented
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: mad...@gmail.com

In the DLang specification here:
https://dlang.org/spec/struct.html#AnonUnionDeclaration

It is said that anonymous unions can be declared, but the ramifications of this
are never clarified. Those coming from C++ will suspect that it makes the
anonymous union members members of the containing object, but for those coming
from Java or another language, this behaviour will seem unexplained.

Example below:
```
void main()
{
  import std.stdio;
  struct Bob {
int a;
union {  // Anonymous union.
  int b;
  int c;
}
union Cat {
  int d;
  int e;
}
Cat cat;
  }

  Bob bob = Bob(1, 2);
  assert(bob.a == 1);
  assert(bob.b == 2);
  assert(bob.c == 2);
  bob.cat = Bob.Cat(3);
  // assert(bob.d == 3); // ERROR, Bob has no property 'd'.
  assert(bob.cat.d == 3);  // OK
}
```

--

Re: Deserialize json on runtime type with vibed

[Stefan Koch via Digitalmars-d-learn]

On Saturday, 12 May 2018 at 20:23:27 UTC, boolangery wrote:

Hi,

I want to do something like that:

The user first register some type associated to a string and a 
callback


registerHandler!Foo("foo", (res) {
  info("message received");
});


I want the callback to be called when a json packet containing 
the string "foo" arrives on a transport layer. Then the full 
json message is deserialized to Foo class using deserializeJson!


The type is known at runtime, so how can I use deserializeJson 
with a runtime type ?


Thanks in advance


via exposing a virtual method which instantiates the template.

Dependency injection pattern

[Suliman via Digitalmars-d-learn]

Could anybody give small example of Dependency injection pattern? 
I googled about it, but found only C# examples and I am not quite 
sure how to use them.


Also I would like get some explanation/comments for code.