date:20170824

Web servers in D

2017-08-24 Thread Hasen Judy via Digitalmars-d-learn

What libraries are people using to run webservers other than 
vibe.d?


Don't get me wrong I like the async-io aspect of vibe.d but I 
don't like the weird template language and the fact that it 
caters to mongo crowd.


I think for D to a have good web story it needs to appeal to 
serious backend developers, not hipsters who go after fads 
(mongodb is a fad, jade/haml is a fad).


I probably need to combine several libraries, but the features 
I'm looking for are:


- Spawn an HTTP server listening on a port, and routing requests 
to functions/delegates, without hiding the details of the http 
request/response objects (headers, cookies, etc).


- Support for websockets

- Runs delegates in fibers/coroutines

- Basic database connectivity (No "orm" needed; just raw sql).

- When iterating the result set of a sql query, has the ability 
to automatically map each row against a struct, and throw if the 
structure does not match.


- More generally, map any arbitrary object (such as json) to a 
struct. Something like Zewo/Reflection package for swift[0].


[0]: https://github.com/Zewo/Reflection

I feel like Vibe.d satisfies my first 3 requirements, but for the 
rest I will probably have to look for something else.

Re: D IDE Coedit - version 3, update 3 released

2017-08-24 Thread user1234 via Digitalmars-d-announce


On Friday, 14 July 2017 at 06:10:08 UTC, Basile B. wrote:
Better integration of D-Scanner. D-Scanner binary is itself 
included from now, in addition to DCD.


See https://github.com/BBasile/Coedit/releases/tag/3_update_3 
for the download links and a complete changelog.


update 4 is available too:

https://github.com/BBasile/Coedit/releases/tag/3_update_4

mostly fixes at first glance.

OpenMAX bindings

2017-08-24 Thread Johnson via Digitalmars-d-learn


Anyone?

Re: SMTP Mail

2017-08-24 Thread Adam D. Ruppe via Digitalmars-d-learn


On Tuesday, 22 August 2017 at 12:52:24 UTC, Vino.B wrote:
  Request your help on sending Mails, I am able to receive 
mails with empty body the line "smtp.message ="Example Message" 
doesn't seem to be working and also please let me know how do i 
send a file as a attachment in a email.


The message there needs to be the complete message, including 
headers. The SMTP struct is pretty low-level.


My email.d (plus its dependencies, characterencodings.d, dom.d, 
and htmltotext.d) has the code to form a full message. It isn't 
very documented though.


https://github.com/adamdruppe/arsd


auto message = new EmailMessage();
message.to ~= "some@email";
message.subject = "Subject"
message.setTextBody("hi");
message.send(RelayInfo("smtp://whatever", "user", "pass"));

Re: Compile Imported Modules

2017-08-24 Thread Jonathan Marler via Digitalmars-d

On Thursday, 24 August 2017 at 17:37:12 UTC, Jonathan Marler 
wrote:

On Thursday, 24 August 2017 at 16:49:08 UTC, Seb wrote:
On Thursday, 24 August 2017 at 16:32:32 UTC, Jonathan Marler 
wrote:

On Thursday, 24 August 2017 at 15:56:32 UTC, H. S. Teoh wrote:
On Thu, Aug 24, 2017 at 03:53:05PM +, Jonathan Marler 
via Digitalmars-d wrote:
Wanted to get peoples thoughts on this.  The idea is to 
have a way to tell the compiler (probably with a command 
line option) that you'd like to "compile imported modules".

[...]

Isn't this what rdmd already does?


T


That is one thing that rdmd does (as I mentioned in the 
original post).


I just looked through the rdmd code 
(https://github.com/dlang/tools/blob/master/rdmd.d) and it 
looks like it invokes the compiler using "dmd -v" to get the 
list of modules and then invokes the compiler again with the 
modules it found to perform the full compile.  So my original 
thought that the logic to find modules is duplicated was 
incorrect.  Instead we just pay a performance hit to get the 
correct list of imports since running "dmd -v" seems to take 
almost as long as the actual compile itself.  So this method 
comes close to doubling the time it takes to compile than if 
the feature was implemented in the compiler itself.


In any case, the idea is to allow the compiler to resolve 
this on it's own without help from rdmd.  This would remove 
the need to invoke the compiler twice, once to find the 
imports and once to compile.  It would also allow some 
projects/applications that don't use rdmd to take advantage 
of this feature, this may or may not include dub (not sure on 
that one).


rdmd is really bad in terms of performance. If you call a 
single D file with rdmd, it will always compile it twice. 
There was an attempt to fix this 
(https://github.com/dlang/tools/pull/194), but this has been 
reverted as it introduced a regression and no one had time to 
look at the regression.
Moving rdmd into DMD has been on the TODO list for quite a 
while and there is a consensus that the performance overhead 
if rdmd isn't nice. However, IIRC there was no clear consensus 
on how the integration should happen. I recall that the plan 
was to do try this with "dmd as a library", but I'm not sure 
whether that's really feasible ATM.


Well this should solve the rdmd performance problem as well as 
make other user cases easier that don't necessarilly use rdmd.


I had another thought that instead of making this an "opt-in" 
feature, it would probably make more sense to be an "opt-out" 
feature.  So by default the compiler would compile missing 
imported modules unless you indicate otherwise, maybe a command 
line switch like "-dont-compile-imports".  And I don't see how 
this would break anything.  Everything should work the same as 
it did before, it's just now you can omit imported module files 
from the command line and it should just work.


I've looked through the DMD code to see how this could be 
implemented and I've run into a problem.  The solution I came up 
with was to go through all the imported modules and then 
determine which ones need to be compiled that haven't been given 
on the command line. The problem is, I don't know how to 
determine whether a module was already compiled and given in an 
obj/lib file.  For example,


dmd something.obj anotherthing.lib prog.d

As far as I know, the compiler has no idea which modules are 
contained in "something.obj" and "anotherthing.lib".  It just 
compiles the source given on then command line, then passes all 
the object files and libraries to the linker, at which point the 
concept of modules is lost.


Am I correct in saying that the compiler has no idea which 
modules an obj/lib file contains?

Re: newCTFE Status August 2017

2017-08-24 Thread Ryion via Digitalmars-d


On Monday, 14 August 2017 at 11:25:14 UTC, Stefan Koch wrote:

Release is coming closer!


Nice, keep up the good work.

Re: Article: Writing Julia style multiple dispatch code in D

2017-08-24 Thread data pulverizer via Digitalmars-d-announce


On Friday, 25 August 2017 at 00:35:24 UTC, jmh530 wrote:
What you seem concerned about here is how to produce a 
meaningful error message for distribution that you do not have 
implementations for. A slightly more elegant solution would be 
to pack the structs into an AliasSeq and then use something 
like !allSatisfies to test them all. I'm sure there's a more 
elegant solution, but that's the first thing I thought of.




Andrei suggested allSatisfies that as an alternative approach to 
a Union keyword similar to Julia, at the time I was still stuck 
on how cool having a Union keyword like Julia's in D would be.




immutable class(T...){...}


What you're looking for is an immutable constructor:

class C
{
this() immutable;
}


Aha, thanks!

Re: HTOD

2017-08-24 Thread Walter Bright via Digitalmars-d


On 8/24/2017 12:08 PM, Jacob Carlborg wrote:
D can already link with C++, but not all features are supported. Like lambdas, 
for example, are not supported.


I have no idea how that would even work. Since lambdas are nested functions, how 
would one write one in D and have it nested inside C++ code?

Re: HTOD

2017-08-24 Thread Walter Bright via Digitalmars-d


On 8/24/2017 12:53 AM, lobo wrote:

 D had 1 ICE that was a known
issue with core team member comments on the bug report.


What's the bugzilla issue number?

Re: Article: Writing Julia style multiple dispatch code in D

2017-08-24 Thread jmh530 via Digitalmars-d-announce

On Thursday, 24 August 2017 at 23:50:21 UTC, data pulverizer 
wrote:


```
double density(D: UnivariateDistribution!Discrete, U = 
getVariateType!D, T = GetDistributionParameterType!D)(D d, U x)

if(!is(D == Poisson!T))
{
assert(false, "density function unimplemented for this 
distribution: " ~ D.stringof);

}

double density(D: UnivariateDistribution!Continuous, U = 
getVariateType!D, T = GetDistributionParameterType!D)(D d, U x)
if(!is(D == Gamma!T) && !is(D == Gaussian!T) && !is(D == 
Uniform!T) && !is(D == Exponential!T))

{
assert(false, "density function unimplemented for this 
distribution: " ~ D.stringof);

}



What you seem concerned about here is how to produce a meaningful 
error message for distribution that you do not have 
implementations for. A slightly more elegant solution would be to 
pack the structs into an AliasSeq and then use something like 
!allSatisfies to test them all. I'm sure there's a more elegant 
solution, but that's the first thing I thought of.




immutable class(T...){...}

that this class can only create immutable objects without 
having to write immutable everywhere and or a UDA, but making 
every member immutable accomplishes the same thing.




What you're looking for is an immutable constructor:

class C
{
this() immutable;
}

Re: D as a Better C

2017-08-24 Thread Michael V. Franklin via Digitalmars-d-announce


On Thursday, 24 August 2017 at 19:21:31 UTC, Walter Bright wrote:

On 8/24/2017 11:56 AM, Walter Bright wrote:
I find -betterC to be somewhat of a copout for avoiding the 
hard work of improving D's implementation.


On the contrary, I view it as providing motivation for dealing 
with those issues. The PR above is stalled for lack of 
motivation.


-betterC also brings into sharp focus exactly what the issues 
are.


Great! I look forward to seeing improvements and hope to help.

Allow me to point out a recent pull request that should have 
resulted in an improvement in the full-featured D implementation 
rather than the -betterC implementation.


https://github.com/dlang/dmd/pull/6918

DMD should never link in Phobos or druntime automatically. 
Rather, I think such dependencies should be specified on a 
platform-by-platform basis using a dmd.conf, linker script, or 
some other configuration file that is distributed with the 
toolchain's package.


This puts the power in the hands of the user to avoid linking in 
Phobos and druntime without having to use the -betterC switch 
which is especially useful if the user is providing their own 
minimal runtime implementation to support features of D that are 
excluded with the heavy hand of -betterC.


Mike

Re: D as a Better C

2017-08-24 Thread Michael V. Franklin via Digitalmars-d-announce


On Thursday, 24 August 2017 at 18:26:37 UTC, H. S. Teoh wrote:

For instance, a D project targeting STM board, makes heavy use 
of classes and templates, resultant code segment is 3k.


https://github.com/JinShil/stm32f42_discovery_demo#the-good


To be fair, though, the above-mentioned project did have to 
create a stub druntime in order to get things to work.  Not 
everyone may have the know-how required to construct a minimal 
druntime that works for their purposes.


Those runtime stubs are needed precisely because of problems in 
D's implementation.  If the implementation were fixed, none of 
those stubs would be required, and neither would the -betterC 
switch.


Because the project above is not using any feature provided by 
those runtime stubs, those stubs should not be required, and 
neither should the -betterC switch.


GDC has made some improvements here, and that is why the project 
above only compiles with GDC.


LDC doesn't even display an error message when those stubs aren't 
created.  Instead it enters a codegen loop generating a 
gargantuan multi-gigabyte file, ultimately crashing my VM 
(https://github.com/ldc-developers/ldc/issues/781).


Sometimes, however, it is not known whether a runtime feature 
will be needed until link-time.  In that case, it's OK for the 
compiler to emit TypeInfo, ModuleInfo, etc..., but it should do 
so in a way that the linker (with either LTO or --gc-sections) 
can determine what is needed and what isn't and discard that 
which isn't needed.  Once unneeded object code is discarded, the 
linker errors disappear, and you get a functioning executable 
without linking in the runtime and without a -betterC switch.


GDC recently implemented such an improvement 
(https://github.com/D-Programming-GDC/GDC/pull/505).  It brought 
my binary size from 600kB to 6KB, so now I can get back to 
microcontroller programming in D.  This is the kind of work 
that's needed.


Mike

Re: Article: Writing Julia style multiple dispatch code in D

2017-08-24 Thread data pulverizer via Digitalmars-d-announce


On Thursday, 24 August 2017 at 21:13:10 UTC, jmh530 wrote:
On UDAs, at least in the current implementation, I think that 
the actual issue you are trying to address is to force the type 
in the distribution to be convertible to double in the 
continuous case and convertible to long in the discrete case. 
All things considered, that can be implemented with template 
constraints, as in


class Gamma(T):
if(isFloatingPoint!T)
{
immutable(T) shape;
immutable(T) scale;
this(T shape, T scale)
{
this.shape = shape;
this.scale = scale;
}
}



Okay, I admit that I try to avoid using template constraints 
whenever I can - i.e. unless the code breaks! It's a habit I am 
trying to break. In reality I will have to have them everywhere 
and the code will end up looking much less pretty, in reality, I 
know I'll probably need one or two catchall functions that look 
something like this


```
double density(D: UnivariateDistribution!Discrete, U = 
getVariateType!D, T = GetDistributionParameterType!D)(D d, U x)

if(!is(D == Poisson!T))
{
assert(false, "density function unimplemented for this 
distribution: " ~ D.stringof);

}

double density(D: UnivariateDistribution!Continuous, U = 
getVariateType!D, T = GetDistributionParameterType!D)(D d, U x)
if(!is(D == Gamma!T) && !is(D == Gaussian!T) && !is(D == 
Uniform!T) && !is(D == Exponential!T))

{
assert(false, "density function unimplemented for this 
distribution: " ~ D.stringof);

}

```

She's not so pretty anymore captain! This is why some time ago I 
suggested introducing the Union keyword that Julia has 
https://forum.dlang.org/post/lkcmqlpsdcopfebwg...@forum.dlang.org


though you could probably take a more abstract approach. (I'm 
also not 100% on having immutable member variables).


I am 100% sure that I want either the instantiated distribution 
object to be immutable, or the parameters to be immutable once 
instantiated. Its a safety feature that I don't see a need for 
mutable distribution objects. Once the parameters change, its not 
the same distribution. Ideally I want to be able to say


immutable class(T...){...}

that this class can only create immutable objects without having 
to write immutable everywhere and or a UDA, but making every 
member immutable accomplishes the same thing.


Also, density's signature could then avoid the template 
constraint.


auto density(D: Gamma!T, U : T, T)(D d, U x)


Sorry U is not T, T is the type of the parameters, U is the type 
of the variate.


Even better, if you're calling the dstats functions, you could 
re-write density as something like


auto pdf(D: Dist!T, U : T, Dist, T)(U x, D d) {
mixin("return x." ~ lookupdstatdensity!Dist ~ "(" ~ 
stringmembersofd ~ ")";

}

and create a lookupdstatdensity function that returns a string 
of the relevant dstats function at compile-time (and a function 
returning a string of the members of d) (I also would re-name 
density to pdf and switch the order of x and d). This would 
probably be the most DRY approach.


Sounds like a reasonable approach, though I haven't looked at the 
dstats package in great detail.


Julia is a scripting language with a JIT compiler. So if you 
call a function with some types known at compile time and the 
overload exists, it will compile the correct version of the 
function for the relevant types.


Yes, I guess you could say that Julia is an interactive compiler, 
where you can create new compiled types and methods in the same 
session.


So it's similar to what you're doing on that respect. However, 
there is a runtime dispatch component that would take something 
like openmethods to implement, I think.


I find OOP-polymorphic types ultimately unsatisfying, but I don't 
know of anyway to write, compile and load a D script with new 
types and methods on the fly into the same session.

Re: Choosing between enum arrays or AliasSeqs

2017-08-24 Thread Meta via Digitalmars-d-learn


On Thursday, 24 August 2017 at 19:41:46 UTC, Nordlöw wrote:

Given

   enum e = ['a', 'b', 'c'];

   import std.meta : AliasSeq;
   enum a = AliasSeq!['a', 'b', 'c'];

is it somehow possible to convert (at compile-time) `e` to `a`?

Is it cheaper CT-performance wise to use AliasSeq instead of 
enum static arrays?


My use case is expressed by the TODOs in the following code 
snippet



import std.algorithm : among;

/** English indefinite articles. */
enum englishIndefiniteArticles = [`a`, `an`];

/** English definite articles. */
enum englishDefiniteArticles = [`the`];

/** English definite articles. */
enum englishArticles = englishIndefiniteArticles ~ 
englishDefiniteArticles;


/** Check if $(D c) is a Vowel. */
bool isEnglishIndefiniteArticle(C)(C c)
if (isSomeChar!C)
{
return cast(bool)c.among!(`a`, `an`); // TODO reuse 
englishIndefiniteArticles

}

/** Check if $(D c) is a Vowel. */
bool isEnglishDefiniteArticle(C)(C c)
if (isSomeChar!C)
{
return cast(bool)c.among!(`the`); // TODO reuse 
englishDefiniteArticles

}

/** Check if $(D c) is a Vowel. */
bool isEnglishArticle(C)(C c)
if (isSomeChar!C)
{
return cast(bool)c.among!(`a`, `an`, `the`); // TODO reuse 
englishArticles

}


https://dlang.org/phobos/std_meta.html#aliasSeqOf

Re: D as a Better C

2017-08-24 Thread jmh530 via Digitalmars-d-announce


On Thursday, 24 August 2017 at 18:56:25 UTC, Walter Bright wrote:


There is a PR to make it only on demand,

  https://github.com/dlang/dmd/pull/6561

but it is mired in problems that are not in the D test suite 
and for which no test cases exist.


C++ compilers also have a switch, like -fno-rtti, for 
de-activating RTTI. BetterC seems like a combination of several 
pieces of underlying functionality. There is not yet any ability 
to have any kind of granularity. For instance,

-betterC=[flag]
where [flag] might be something like "off-dassert" which calls 
the C assert function instead of the D one.

Re: Visual Studio Code code-d serve-d beta release

2017-08-24 Thread WebFreak001 via Digitalmars-d-announce

On Thursday, 24 August 2017 at 08:21:41 UTC, Paolo Invernizzi 
wrote:

On Wednesday, 23 August 2017 at 20:10:01 UTC, WebFreak001 wrote:

[...]


Can you check?
If I want to build it, what repo and revision should I use?

[...]


git clone https://github.com/Pure-D/serve-d.git
cd serve-d
dub build --build=release

Re: Article: Writing Julia style multiple dispatch code in D

2017-08-24 Thread jmh530 via Digitalmars-d-announce

On Thursday, 24 August 2017 at 20:11:32 UTC, data pulverizer 
wrote:


Thanks. I think most of that is down to D's nice syntax and how 
it easily and clearly emulates Julia. I think that there is 
certainly more to say on this especially around strategies of 
how represent concrete types. David Gileadi's point about UDAs 
could add an interesting spin on things, and Ali's point on 
dynamic dispatching.




On UDAs, at least in the current implementation, I think that the 
actual issue you are trying to address is to force the type in 
the distribution to be convertible to double in the continuous 
case and convertible to long in the discrete case. All things 
considered, that can be implemented with template constraints, as 
in


class Gamma(T):
if(isFloatingPoint!T)
{
immutable(T) shape;
immutable(T) scale;
this(T shape, T scale)
{
this.shape = shape;
this.scale = scale;
}
}

though you could probably take a more abstract approach. (I'm 
also not 100% on having immutable member variables). Also, 
density's signature could then avoid the template constraint.


auto density(D: Gamma!T, U : T, T)(D d, U x)

Even better, if you're calling the dstats functions, you could 
re-write density as something like


auto pdf(D: Dist!T, U : T, Dist, T)(U x, D d) {
mixin("return x." ~ lookupdstatdensity!Dist ~ "(" ~ 
stringmembersofd ~ ")";

}

and create a lookupdstatdensity function that returns a string of 
the relevant dstats function at compile-time (and a function 
returning a string of the members of d) (I also would re-name 
density to pdf and switch the order of x and d). This would 
probably be the most DRY approach.


On Ali's point on dynamic dispatching, Julia is a scripting 
language with a JIT compiler. So if you call a function with some 
types known at compile time and the overload exists, it will 
compile the correct version of the function for the relevant 
types. It will then cache that so that if you need it again you 
don't pay any additional cost. So it's similar to what you're 
doing on that respect. However, there is a runtime dispatch 
component that would take something like openmethods to 
implement, I think.

Re: very odd directx 11 error

2017-08-24 Thread maarten van damme via Digitalmars-d-learn

zeroMemory(, scd.sizeof);

void zeroMemory(void* ad,size_t size){
(cast(byte*)& ad)[0 .. size] = 0;
}


I was totally corrupting my stack and it's not even needed in D, the
compiler zero's it out automatically.
Mystery solved, thanks a lot irc (adam,wolfgang,...)


2017-08-24 17:26 GMT+02:00 maarten van damme :

> I should probably add that the error is a hresult, being 0 when it works
> but -2005270527 when it fails.
>
> 2017-08-24 17:24 GMT+02:00 maarten van damme :
>
>> Hi all.
>>
>> This works (dub --arch=x86_mscoff) http://dpaste.com/1XCJEX7 but this
>> fails : http://dpaste.com/1C7WMB7 .
>>
>> Notice that all I've done is manually inlined init3d...
>>
>> You can compile this with the following dub.json
>>
>> http://dpaste.com/2QBQFSX
>>
>> Any help would be appreciated, it make absolutely no sense to me.
>>
>
>

Re: Article: Writing Julia style multiple dispatch code in D

2017-08-24 Thread data pulverizer via Digitalmars-d-announce

On Thursday, 24 August 2017 at 18:16:21 UTC, jmh530 wrote:
I think at one point I had actually suggested that dstats or
something be re-written in a Julia-like way (before I realized
how much work that would be!). It looks very pretty.

Thanks. I think most of that is down to D's nice syntax and how
it easily and clearly emulates Julia. I think that there is
certainly more to say on this especially around strategies of how
represent concrete types. David Gileadi's point about UDAs could
add an interesting spin on things, and Ali's point on dynamic
dispatching.

Nevertheless, you might be re-inventing the wheel a bit if you
want to build a whole library in this style.

True. I have found a couple of projects that fresh targets that I
am working on and writing code in this style.

My recommendation would be to write a front-end for the
dstats.distrib and dstats.random submodules in this style. That
way you won't need to re-write all the functions, you can just
call ones from dstats that have already been tested.

True code reuse is important, especially when you want to get
something working quickly.

More generally, I prefer the structs because they don't rely on
the garbage collector, but the class/interface version is
prettier.

Aha! I was wandering why I see people avoid classes even when
using them is clearly the best way to represent their objects.
For some reason it never occurred to me that they where just
trying to avoid the GC. I just thought they didn't want to use
reference objects.

Atila's concepts library has implements, which you might find
helpful. I have gently nudged him to work on something that
also can tell if a type is a subtype of another type more
generally (like a struct being a subtype of another struct). I
think this would really be a good use case for that
functionality.

I was thinking about this article for some time, it was Atila's
article
(https://atilanevesoncode.wordpress.com/2017/08/23/on-the-novelty-factor-of-compile-time-duck-typing/) that was a trigger for me writing it.

Re: Compile Imported Modules

2017-08-24 Thread Jonathan Marler via Digitalmars-d

On Thursday, 24 August 2017 at 18:12:03 UTC, H. S. Teoh wrote:
On Thu, Aug 24, 2017 at 06:00:15PM +, Jonathan Marler via 
Digitalmars-d wrote:

On Thursday, 24 August 2017 at 17:49:27 UTC, H. S. Teoh wrote:
> Uh, no.  This will definitely break separate compilation, 
> and some people will be very unhappy about that.

I couldn't think of a case that it would break.  Can you share 
the cases you thought of?

Suppose you have main.d and module.d, and you want to compile 
them separately:

dmd -c main.d
dmd -c module.d
dmd -ofmyprogram main.o module.o

If dmd defaulted to auto-importing, then `dmd -c main.d` would 
also compile module.d (assuming main.d imports `module`), 
contrary to what was intended in a separate compilation 
scenario, and the last command will produce a linker error from 
duplicated symbols.

This is just a simple case, of course. But in general, changing 
the meaning of `dmd -c source.d` will break existing build 
scripts.  Sure, you could ask people to update their build 
scripts to include `-no-auto-imports`, but that requires effort 
from users, who will be unhappy that upgrading dmd broke their 
build scripts.  For large projects, such a change may not be 
trivial as in the above example.

T

Actually this feature is mutually exclusive with the "-c" case.  
It doesn't make sense to compile imported modules unless you are 
also linking an executable.  So your example would work as 
expected.

Do you have any other cases you thought of that would not work? 
Like I said I couldn't think of any.  I'm not saying that that's 
enough reason to make it an "opt-out" feature, it's just 
something to think about.  The feature could also be an "opt-in" 
feature at first and eventually made "opt-out" if it makes sense. 
 But I'd still like to know people's thoughts/concerns either way.

Re: Beta 2.076.0

2017-08-24 Thread user1234 via Digitalmars-d-announce


On Friday, 18 August 2017 at 12:58:18 UTC, Martin Nowak wrote:

First beta for the 2.076.0 release.

This release comes with various phobos additions and lots of 
improvements for -betterC (changelog entry upcoming).


http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.076.0.html


Please report any bugs at https://issues.dlang.org

- -Martin


I have a warning about the RPM package signature. It was already 
the case with 2.075.1

Choosing between enum arrays or AliasSeqs

2017-08-24 Thread Nordlöw via Digitalmars-d-learn


Given

   enum e = ['a', 'b', 'c'];

   import std.meta : AliasSeq;
   enum a = AliasSeq!['a', 'b', 'c'];

is it somehow possible to convert (at compile-time) `e` to `a`?

Is it cheaper CT-performance wise to use AliasSeq instead of enum 
static arrays?


My use case is expressed by the TODOs in the following code 
snippet



import std.algorithm : among;

/** English indefinite articles. */
enum englishIndefiniteArticles = [`a`, `an`];

/** English definite articles. */
enum englishDefiniteArticles = [`the`];

/** English definite articles. */
enum englishArticles = englishIndefiniteArticles ~ 
englishDefiniteArticles;


/** Check if $(D c) is a Vowel. */
bool isEnglishIndefiniteArticle(C)(C c)
if (isSomeChar!C)
{
return cast(bool)c.among!(`a`, `an`); // TODO reuse 
englishIndefiniteArticles

}

/** Check if $(D c) is a Vowel. */
bool isEnglishDefiniteArticle(C)(C c)
if (isSomeChar!C)
{
return cast(bool)c.among!(`the`); // TODO reuse 
englishDefiniteArticles

}

/** Check if $(D c) is a Vowel. */
bool isEnglishArticle(C)(C c)
if (isSomeChar!C)
{
return cast(bool)c.among!(`a`, `an`, `the`); // TODO reuse 
englishArticles

}

88 matches

Mail list logo