Status of std.async?

[Shammah Chancellor via Digitalmars-d]

So, I've used vibed a bit in the past and really like it, but am 
hesitant to base other network based clients on it.  I see now 
that there are several other Async libraries for D, including one 
native one.  It also looks like Sonke is working on another 
native async library.


My question is this, what's the status of getting one of these 
moved into the standard library?   I know there was a thread 
about asking for someone to own this awhile ago, but I cannot 
seem to find it now by searching for "std.async".  Is this 
something that still needs an owner, or is it actively being 
worked?


-S

Re: The D language online tour - tour.dlang.org

[Shammah Chancellor via Digitalmars-d-announce]

On Tuesday, 17 May 2016 at 09:02:04 UTC, André wrote:

On Monday, 16 May 2016 at 20:39:26 UTC, Jack Stouffer wrote:
On Monday, 16 May 2016 at 18:02:29 UTC, Andrei Alexandrescu 
wrote:
This is great work, thanks! Please announce in social media 
as well! -- Andrei


Reddit: 
https://www.reddit.com/r/programming/comments/4jn6ks/the_online_d_language_tour/


Thanks!


Hey, great site! Really glad this was done.  The interface is a 
tiny bit confusing.  At the end of the welcome it's not clear you 
need to goto the "Basics" tab to continue on.  All the strings 
should probably just be tied together.


-S.

Re: So what does (inout int = 0) do?

[Shammah Chancellor via Digitalmars-d]

On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu 
wrote:

Consider:

https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152

There is no explanation to it in the source code, and the line 
blames to 
https://github.com/D-Programming-Language/phobos/pull/2661 
(irrelevant).


Commenting it out yields a number of unittest compilation 
errors, neither informative about the root of the problem and 
indicative as to how the parameter solves it.


There are two issues here:

1. Once a problem/solution pair of this degree of subtlety 
crops up, we need to convince ourselves that that's sensible. 
If we deem it not so, we look into improving the language to 
make the problem disappear.


2. There needs to be documentation for people working on the 
standard library so they don't need to waste time on their own 
discovery process.


We want Phobos to be beautiful, a prime example of good D code. 
Admittedly, it also needs to be very general and efficient, 
which sometimes gets in the way. But we cannot afford an 
accumulation of mad tricks to obscure the large design.



Andrei


`(int inout = 0)` is not the only problem with that template -- 
and it's bothered me for years.


`is(typeof( () { ... } ) )` as a whole looks like a "trick" to 
me.  It's not going to be immediately obvious to someone who 
reads the D spec, and then that code, what that template does.


I think that behavioral type checks are common enough in D that 
it should have it's own first-class syntax.


-Shammah

Concatenative Programming Languages

[Shammah Chancellor via Digitalmars-d]

I just stumbled on this wikipedia article: 
https://en.wikipedia.org/wiki/Concatenative_programming_language


Seems like D falls under that category?

-S.

Re: Pitching D to a gang of Gophers

[Shammah Chancellor via Digitalmars-d]

On Wednesday, 9 March 2016 at 13:23:55 UTC, Andrei Alexandrescu 
wrote:

On 03/07/2016 02:17 PM, landaire wrote:
I'd like to add that one of the things that I love about Go is 
that it
is crazy easy to cross-compile. `GOOS=freebsd go build` and I 
have a
FreeBSD binary sitting in my working directory, ready to send 
off.


What would be some good cases for that? When I want to 
cross-compile, I ssh into the target machine and build there. 
-- Andrei


Well,  at least in a commercial environment, not having to have 
multiple pools of build machines is very helpful.  That is to 
say, I don't need 10 windows machines sitting around waiting to 
accept a job, since I can just cross compile with `GOOS=windows 
GOARCH=386 go build` on linux.


This is also why gofmt is so awesome -- if you're working with a 
team of 40 other engineers, you don't want to be messing with 
formatting holy-wars.


And another item for this thread that D really shines at:

const and immutable -- Golang lacks const and immutable.  When 
working with large-ish teams, it's pretty annoying not to be able 
to require a library take a const, or immutable parameter.


-S

Re: Pitching D to a gang of Gophers

[Shammah Chancellor via Digitalmars-d]

On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
I'm having an opportunity to do a small tech-talk on things D 
in a eCommerce shop that is currently sold on Go (migrating to 
SOA from PHP monolith). I do not intend that to become Go vs D 
battle but it gives the context.


What guys seem to like of Go from my observation:
- goroutines instead of direct asynchronous programming*
- fast runtime with state of the art GC
- host of ready-made libraries esp. http & networking**
- lightweight OOP that doesn't get in your way
- tooling, tooling, tooling (IDE plugins and build tools work 
great)


*Note: all of standard I/O is transparently handled with 
goroutines much like vibe.d but goroutines are migrating across 
thread pool
** That being said there are tons of 1-man projects of dubious 
quality,


So far I'd thought of a few big themes:
- little nice things (slices/maps, things like 1_000_000 and 
e.g. a < b && d < e is parse error, UFCS)
- code reuse (templates & ranges, with examples like generic 
min and some algo)

- compile-time works (CTFE, need simpler example then regex)

I'm still pondering whether I should dive into UDA, I'd try to 
stay simple as simplicity is one of things Go guys known to 
love.


What features you'd highlight to enterprise-ish user?


I work in a 99% Go shop (a splash of C, and some smattering of 
scripts for in-house tools.)  I've tried to use D for a few 
things, and tried to get other people interested in it.  So, 
here's my perception:


Everything you've said is true, and D should focus on making some 
of these things much better.  Additionally, the compiled (mostly 
single binary nature) of Go makes it very nice for deployments.   
Focusing on dfmt, and dfix would be a huge win.


Here's some stuff D shares with Go:

"Single" binary deployments.
Garbage Collector
In-language slices and maps
Foreach (Although D is much more powerful here)

Some things D is weak on:
* The name -- all I ever hear are penis jokes.
* Garbage Collector (!)
* dfix and dfmt aren't as good as gofmt and gofix. (And believe 
me I understand they will be much more difficult to get to parity 
due to the feature set of D)
* Docs  -- although these have gotten much much better recently 
-- the current implementation of concepts makes it hard for 
people to know where and when they can use a type.  E.g sort docs 
(http://dlang.org/phobos/std_algorithm_sorting.html#sort) How do 
I know what types of things I can sort as a newcomer? Even if I 
figure out that I need to look at isForwardRange, the docs there 
aren't terribly helpful either 
(https://dlang.org/phobos/std_range_primitives.html#isForwardRange)  I would put up a PR, but I don't know how to fix it without introducing a language structure for Concepts -- but this has been veto'd for a variety of reasons (primarily type explosion as I understand the arguments)

* Libraries

Some things D is much better on (and would cause me to choose it 
every time and just contribute fixes where I could to the 
external tools):


* Package management/build tools
* Integration with existing build systems/libraries
* Reusable algorithms that are FAST
* Empowering programmer expressiveness without enabling magic

-S.

Re: Pitching D to a gang of Gophers

[Shammah Chancellor via Digitalmars-d]

On Saturday, 5 March 2016 at 11:31:27 UTC, John Colvin wrote:
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky 
wrote:
I'm having an opportunity to do a small tech-talk on things D 
in a eCommerce shop that is currently sold on Go (migrating to 
SOA from PHP monolith). I do not intend that to become Go vs D 
battle but it gives the context.


[...]


Have you seen this? 
http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ I'm not sure if it's all correct and how to compare the situation to D, but it was interesting to read.


That article is correct -- I've used go extensively at this 
point.  This is also a good article: 
https://gist.github.com/kachayev/21e7fe149bc5ae0bd878

Re: D compiler daily downloads at an all-time high

[Shammah Chancellor via Digitalmars-d-announce]

On Monday, 16 November 2015 at 19:16:09 UTC, Saurabh Das wrote:
On Monday, 16 November 2015 at 15:20:51 UTC, Andrei 
Alexandrescu wrote:

http://erdani.com/d/downloads.daily.png

There have been 1677 dmd downloads per day (net after 
discounting Travis CI) on average over the past 28 days (i.e. 
four weeks ending Sunday, November 15).


That's a new all-times high ever since we started measuring on 
January 02, 2013. The previous record, 1630 average daily 
downloads, was established in the four weeks ending November 
17, 2014.


w00t!  Go us!

Re: DIP 57: static foreach

[Shammah Chancellor via Digitalmars-d]

On Monday, 10 March 2014 at 06:40:49 UTC, Kenji Hara wrote:

2014-03-10 6:31 GMT+09:00 Timon Gehr :


http://wiki.dlang.org/DIP57

Thoughts?




From the "Semantics" section:


For static foreach statements, break and continue are 
supported and

treated like for foreach statements over tuples.

This is questionable sentence. On the foreach with tuple 
iteration, break and continue have no effect for the unrolling.


void main()
{
import std.typetuple, std.stdio;

foreach (i; TypeTuple!(1, 2, 3))
{
static if (i == 2) continue;
else static if (i == 3) break;

pragma(msg, "CT: i = ", i); // prints 1, 2, and 3 in CT
writeln("RT: i = ", i); // prints only 1 in RT
}
}

So, I think that static foreach *cannot* support break and 
continue as same as foreach with tuples.


Kenji Hara


Ditto.  This needs `static continue` and `static break`.  Without 
this functionality, the control flow in `static foreach` becomes 
very unwieldy.


-Shammah

Re: DIP 57: static foreach

[Shammah Chancellor via Digitalmars-d]

On Wednesday, 4 November 2015 at 00:23:59 UTC, Andrei 
Alexandrescu wrote:

On 11/3/15 3:12 PM, Shammah Chancellor wrote:


So, I think that static foreach *cannot* support break and 
continue as

same as foreach with tuples.

Kenji Hara


Ditto.  This needs `static continue` and `static break`.  
Without this
functionality, the control flow in `static foreach` becomes 
very unwieldy.


There's no reason technical or otherwise to require "static" 
with continue/break in static foreach. -- Andrei


I'm not sure that I agree with you.  However, in the latest DMD 
it appears that named break/continues work with foreach over 
tuples now.   So, I'll rescind my statement regarding separating 
compile-time control flow vs runtime control flow.


-Shammah

Re: DIP 84: Static Inheritance

[Shammah Chancellor via Digitalmars-d]

On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
From the discussion here: 
http://forum.dlang.org/post/tgnxocozkurfvmxqo...@forum.dlang.org, I thought a library solution would do to fix the issue of getting decent error messages when a type fails to satisfy a template constraint that it was meant to, such as `isInputRange`. So I submitted a PR (https://github.com/D-Programming-Language/phobos/pull/3677), it's been there ever since and doesn't seem like it'll go anywhere from the discussion (http://forum.dlang.org/post/qvofihzmappftdiwd...@forum.dlang.org).


So the only other way is a DIP (http://wiki.dlang.org/DIP84) 
for language and compiler support for static inheritance. It's 
backwards-compatible and IMHO worth looking at.


Please let me know what you think.

Atila


Atila,  did you get a chance to look at the 
std.experimental.concepts work I was doing?


It's very similar to what you seem to want, but the diagnostic 
messages are really annoying to use as you have to make a default 
template that the user can fall through to:


https://github.com/schancel/phobos/blob/4ca5d075f31b8e09ba71ac2a53ff56ff0c4ac5b9/std/experimental/concepts.d

-Shammah

Re: DIP 84: Static Inheritance

[Shammah Chancellor via Digitalmars-d]

On Friday, 30 October 2015 at 16:44:15 UTC, Atila Neves wrote:
On Friday, 30 October 2015 at 15:45:00 UTC, Shammah Chancellor 
wrote:

On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:

From the discussion here: 


I took a look. I don't think we should or need to use classes 
and therefore dynamic polymorphism to solve the problem of 
checking for adherence to a static interface.


Mostly all I want is for the compiler to tell me why something 
doesn't compile - it already knows it but is hiding the 
information from me.


Atila


I'm not advocating for the implementation, but the dynamic 
polymorphism isn't required.  The class is just a skeleton for 
specifying the definition in a clear way.  See the unit test:


https://github.com/schancel/phobos/blob/4ca5d075f31b8e09ba71ac2a53ff56ff0c4ac5b9/std/experimental/concepts.d#L280-L303

Re: Compile time features

[Shammah Chancellor via Digitalmars-d]

On Thursday, 29 October 2015 at 06:02:05 UTC, qsdf wrote:
On Thursday, 29 October 2015 at 02:43:59 UTC, Shammah 
Chancellor wrote:




I agree with you on an aspect: writing code with __traits() 
often leads to a  cascade of "unfriendly", "cryptic", 
"undigest", static if and loops.


However your examples are discutables:

1/ The symbol is not always a type, so to test it there is 
`if(is()){}`:


---
import std.stdio;

enum hack(A...) = A;

int main() {
foreach(member; __traits(allMembers, std.stdio)) {
pragma(msg, member);
static if (is(member))
		alias sym = hack!(__traits(getMember, std.stdio, 
member))[0];

}
}
---


The point is that you cannot use is() without first using 
getMember, but using __traits(getMember) before 
__traits(compiles) generates an error.  In your example you're 
trying to use `is` on a string, which does not work.




2/ with only one way to define the alias it works, whatever is 
the function type (property or not)


---
import std.traits, std.stdio, std.typetuple;

private template MemberType(C, string memberName)
{
alias member = TypeTuple!(__traits (getMember, C, 
memberName))[0];

static if (isSomeFunction!(typeof()))
alias MemberType = typeof();
else static assert(0, "not handled here !");
}

struct Hop
{
void foo(uint a){}
@property uint bar(){return 0;}
uint baz(){return 0;}
@property void bla(uint h){}
}

void main()
{
MemberType!(Hop, "foo").stringof.writeln;
MemberType!(Hop, "bar").stringof.writeln;
MemberType!(Hop, "baz").stringof.writeln;
MemberType!(Hop, "bla").stringof.writeln;
}
---


And you snipped out important sections of code for dealing with 
fields.  The following code now will not compile:


getType.d(7): Error: need 'this' for address of bob
getType.d(27): Error: template instance getType.MemberType!(Hop, 
"bob") error instantiating



```
struct Hop
{
int bob;
}

void main()
{
MemberType!(Hop, "bob").stringof.writeln;
}
```





3/ Your example doesn't compile


Sorry, try this:

```
import std.stdio : writeln;
import std.typetuple;
// This won't work:
/+
private template stuff(Args...) {
/+ static +/ foreach(Arg; Args) {
...
}
}
+/
// Must do this instead:
private template expand(Args...)
{
static if (Args.length > 0)
{
static if (Args.length > 1)
{
			enum expand = AliasSeq!(repeat!(Args[0], Args.length), 
expand!(Args[1..$]));

}
else static if (Args.length == 1)
{
enum expand = AliasSeq!(repeat!(Args[0], Args.length));
}
}
}
private template repeat(alias T, int times) {
static if ( times > 1 ) {
enum repeat = AliasSeq!(T, repeat!(T, times-1));
} else static if (times == 1) {
enum repeat = AliasSeq!(T);
}
}
enum things = expand!("A","B","C");

void main() {
pragma(msg, things);
writeln("Hello World");
}
```

Re: Automatic method overriding in sub-classes

[Shammah Chancellor via Digitalmars-d]

On Monday, 26 October 2015 at 23:25:49 UTC, Tofu Ninja wrote:

So we have TemplateThisParameters methods which are cool but 
have some drawbacks.
They are templates so they are implicitly non-virtual and are 
called based on the type of the reference.
It would be very nice to be able to auto generate method 
overrides based on the this type with out having to drop a 
mixin in every sub class.

This would be very useful for CT-reflection.
I will call this new feature auto override methods for the rest 
of this post.


This kind of magic is detrimental to being able to reason about 
the code you are writing.  If libraries do this for example, 
there's too much spooky action-at-a-distance occurring.  Having 
explicit mixins is the appropriate way to handle this.

Compile time features

[Shammah Chancellor via Digitalmars-d]

Currently D has some very very powerful compile time features, 
but they can get unwieldily quickly when doing compile time 
reflection with mildly complicated logic.  It's pretty 
disappointing.  I'd like to start a discussion around some of the 
problems I've ran into using these features.  If there aren't 
bugzilla reports, I can open them but I'm not entirely sure how 
to file these appropriately.


1) There seems to be many cases where __traits(allMembers, ...) 
over a package produces symbol strings which cannot be converted 
to a symbol using __traits(getMember). Also __traits is not 
useable in reasonable contexts( alias foo = __traits(..)). E.g.


This will fail due to weird symbols being returned from 
allMembers.

```
import std.stdio;

enum hack(A...) = A;

int main() {
foreach(member; __traits(allMembers, std.stdio)) {
pragma(msg, member);
alias sym = hack!(__traits(getMember, std.stdio, member))[0];
}
return 0;
}
```

2) There are oddities around getting the types of functions which 
are properties:


e.g. (Note the __compiles, and addressing the member):

```
//Gets the member type, even for properties.
private template MemberType(C, string memberName)
{
alias member = TypeTuple!(__traits (getMember, C, 
memberName))[0];


static if (__traits (compiles, typeof()))
{
static if (isSomeFunction!(typeof()))
{
alias MemberType = typeof();
}
else
{
alias MemberType = typeof(member);
}
} else {
alias MemberType = typeof(member);
}
}
```

3) Additionally, any kind of iteration becomes very unwieldy.  
This kind of code becomes necessary in common cases.  (E.g. pass 
in a list of packages and reduce to a AliasSeq of type symbols)



```
import std.stdio : writeln;
import std.typetuple;

// This won't work:
/+
private template stuff(Args...) {
/+ static +/ foreach(Arg; Args) {
...
}
}
+/

// Must do this instead:
private template expand(Args...)
{
static if (Args.length > 0)
{
static if (Args.length > 1)
{
			enum stuff = AliasSeq!(repeat!(Args[0], Args.length), 
stuff!(Args[1..$]));

}
else static if (Args.length == 1)
{
enum stuff = AliasSeq!(repeat!(Args[0], Args.length));
}
}
}

private template repeat(alias T, int times) {
static if ( times > 1 ) {
enum repeat = AliasSeq!(T, repeat!(T, times-1));
} else static if (times == 1) {
enum repeat = AliasSeq!(T);
}
}

enum things = expand!("A","B","C");

void main() {
pragma(msg, things);
writeln("Hello World");
}
```

Re: Indicators and traction…

[Shammah Chancellor via Digitalmars-d]

On Wednesday, 23 September 2015 at 12:19:48 UTC, Russel Winder 
wrote:
Having just done a session at PyConUK 2015 aimed at weaning 
people of
pure Python and into polyglot – Python with (C++|D|Chapel) 
(there
should have been a Rust bit but…) – and as people probably 
heard the D
bit was a bit embarrassing for me, I got some interesting 
comments

during the rest of the conference.

The most important can be paraphrased as "I had heard of D but 
as it was getting no traction, I never looked at it again."


This would seem to indicate that D really does need to have a 
marketing campaign to show it does have traction and isn't just 
a little ghetto as so many languages end up in. D's forays into 
AAA games, finance, etc. all need to get permanent presence. In 
this respect, Reddit is (almost) an irrelevance: bulk 
perception is unaffected by Reddit, most programmers do not 
even look at it, let alone follow it. It would be nice if Tiobe 
and the like were an irrelevance, but that is less so.


Having active regional groups is a first important factor, and 
that is happening, though perhaps less than would be good. 
Having lots of projects on GitHub (and BitBucket) that get 
noticed. Clearly everyone is fighting JavaScript, but that is 
not an issue for D per se. Go, Rust, C++, C are the "enemy".


Maybe discuss this a bit at the coming London D Meeting – which 
sadly clashes with the London Go Meeting…



Honestly, the biggest thing that would get some D traction is 
people writing developer tools in it.  I've been working on some 
release tooling in D to snapshot sets of repositories for later 
checkout and to generate changelogs from commit messages somewhat 
like dpkg-dch.


-Shammah

Re: A collection of DIPs

[Shammah Chancellor via Digitalmars-d]

On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote:

https://github.com/NightmareX1337/DX

Don't kill me, I'm just trying to help...

You can report issues and create pull requests :)


Destroy!


Hi NX,

Thanks for the document.  A lot of what you say about UDA and 
compile time reflection is absolutely true.  We should fix it so 
it isn't so darn convoluted.


w/ regards to __traits() those are call outs to the compiler and 
generally should not be used directly.  Thus std.traits, and why 
they're prefixed with __.  Unfortunately, the current state of 
compile time reflection requires that you must use __traits 
directly (at least, I've had to)


However, I can't agree with you about alias this, UFCS, or global 
functions in phobos.  The "idiomatic" way to code in D is use 
local named imports.  e.g.:


void main() {
   import std.stdio : writeln;
   writeln("Hello world!");
}

-Shammah

Re: Moving forward with work on the D language and foundation

[Shammah Chancellor via Digitalmars-d-announce]

On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu 
wrote:

Hello everyone,


Following an increasing desire to focus on working on the D 
language and foundation, I have recently made the difficult 
decision to part ways with Facebook, my employer of five years 
and nine months.


[...]


Awesome.  I wish I could join you.  :)  Maybe in time.

How do we donate?  Is there a mechanism to maybe do reoccurring 
donations via PayPal?

Re: Proposal : mnemonic for start index for slices

[Shammah Chancellor via Digitalmars-d]

On Saturday, 8 August 2015 at 13:08:08 UTC, Temtaime wrote:

Hi !
I want to add some sugar to D : sometimes it's necessary to use 
complex start index.


For example:
auto sub = arr[idx + 123 * 10..idx + 123 * 10 + 1];

Proposal is to add a mnemonic for start index, for instance :

auto sub = arr[idx + 123 * 10..# + 1]; // # == start index

# is for example. Maybe it can be @ or some other symbol.

Any ideas ? Should i try to create a DIP ?


More sugar is more overhead for new people to learn just to 
understand code written in the language.  Why don't you do:


auto startIdx = idx + 123 * 10;
auto sub = arr[startIdx .. startIdx + 1];

-Shammah

Re: [RFC] std.experimental.concepts

[Shammah Chancellor via Digitalmars-d]

On Friday, 24 July 2015 at 23:13:25 UTC, deadalnix wrote:
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor 
wrote:
I put up a PR for phobos awhile ago for concepts as a library 
to kind of start the discussion around concepts.   There 
seemed to be some interest around the PR, so I have rebased it 
and fixed the formatting.


Please take a look: 
https://github.com/D-Programming-Language/phobos/pull/2627


-Shammah


Doing it as a library would miss a lot of the point of concepts 
:
 - Compiler can do a fair amount of semantic analysis on 
template before instantiating them. This work is done once 
rather than repeating it a every template instantiation.
 - It allow for much more clearer error messages. Anyone having 
to maintain some meta code will understand what I'm talking 
about here.
 - It make compile time and runtime polymorphism more alike. I 
do think we'd all agree that Andrei approach to mention 
template arguments as compile time arguments and go from there 
is a good move. Concept would be the same move, but for typing. 
By reusing common language constructs (C++ failed to use that 
opportunity) for instance.


Agreed, that's why I left the PR alone for so long before someone 
pinged me on it.  I sort of did it as a POC and didn't quite end 
up liking the results.  The library solution would be okay if it 
was easier to get diagnostics -- but currently that requires 
nasty hacks if you looked at the docs.

Named parameters

[Shammah Chancellor via Digitalmars-d]

Since D has optional arguments -- why don't we support named 
parameters?  There are extremely handy and work beautifully in 
languages like C#.

with(auto x = ...)

[Shammah Chancellor via Digitalmars-d]

This operation doesn't seem to work.   It would be a pretty handy 
thing to work since we don't support named parameters at this 
time.


Comments?

[RFC] std.experimental.concepts

[Shammah Chancellor via Digitalmars-d]

I put up a PR for phobos awhile ago for concepts as a library to 
kind of start the discussion around concepts.   There seemed to 
be some interest around the PR, so I have rebased it and fixed 
the formatting.


Please take a look: 
https://github.com/D-Programming-Language/phobos/pull/2627


-Shammah

Re: Named parameters

[Shammah Chancellor via Digitalmars-d]

On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor 
wrote:
Since D has optional arguments -- why don't we support named 
parameters?  There are extremely handy and work beautifully in 
languages like C#.


We've argued about this several times in the past. We're not 
adding them. They interact badly with overloading (especially 
if you try and add more overloads later), and they make it so 
that the parameter names are part of the API, which means even 
more bikeshedding and arguments about naming.


- Jonathan M Davis


Funny, they work beautifully in C#.

https://msdn.microsoft.com/en-us/library/dd264739.aspx

Creating a better user experience

[Shammah Chancellor via Digitalmars-d]

I have watched plethora of projects come and be discharged to the 
sea of abandonware over the last 15 years of watching D.  For new 
users getting started with D it can be hard to find some of the 
tools that are current.


It would be really nice if dub, dfmt, and dfix were co-opted into 
the standard distribution of D and officially sanctioned as part 
of the D-Programming-Language github organization.  These are 
great tools and I would hate to see them flounder if the authors 
got bored/busy.


-Shammah

Re: Scaling rdmd up: build package at a time

[Shammah Chancellor via Digitalmars-d]

On Friday, 5 June 2015 at 16:15:21 UTC, Andrei Alexandrescu wrote:

This is a self-contained and really fun project:

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

It requires an understanding of how rdmd currently works 
(1KLOC in a single module!) and is of huge impact.


Who'd want to get into it? I would if I didn't already have 
std.allocator to have fun with.


(Speaking of which: regions that grow upwards or downwards 
depending on stack growth direction for cache hotness, yum! 
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_region.html)



Andrei


How can any of this work without a special object format that is
template aware?

DLang Meetup Bay Area -- Reminder

[Shammah Chancellor via Digitalmars-d]

Reminder about tonight's meetup: 
http://www.meetup.com/D-Lang-Silicon-Valley/events/221371799/


Apcera
585 Howard Street (Third Floor), San Francisco, CA (edit map)

Food, beverages, and venue are provided by Apcera 
(http://www.apcera.com)


We are having a lightning talk meeting this month:
Ali Çehreli: Fibers (aka. coroutines and green threads)
Shammah Chancellor: Tooling around D; What is awesome, what we 
need, and more.

Amaury Sechet: Current state of SDC
Andrei Alexandrescu: Ask me anything about D

Also, if whoever owns the D_Programming twitter account could 
post, that would be great.

AA Performance in Benchmarks

[Shammah Chancellor via Digitalmars-d]

So, I was tooling around with one of the benchmarks I saw listed 
on twitter:


https://github.com/kostya/benchmarks/tree/master/brainfuck

This D benchmark spends most of it's time on AA lookups.   
Discussions about the implementation aside, I am curious as to 
why the D AA is so slow even after calling AA.rehash.


I took a look at the Nim tables implementation, and it looks that 
they use power-of-two vectors and use the property of primitive 
roots modulo n to get the next value in the case of a collision:


```
proc nextTry(h, maxHash: THash): THash {.inline.} =
  result = ((5 * h) + 1) and maxHash
```

So, my questions:

1) What are the general purpose performance implications of 
something like this?
2) I saw a thread awhile ago where someone had posted an updated 
implementation of the AA with benchmarks and showed that it was 
substantially faster in all cases.  I can't find the thread again 
-- what happened with this work?


-Shammah

Re: SDC needs you -- redux

[Shammah Chancellor via Digitalmars-d]

On 2015-04-22 11:28:21 +, jkpl said:


Hey. Is the win32 build fixed now (libd) ?
Since, i don't know, maybe 2 monthes, it looks like there is a mess 
with the 32/64 bit types.


I'm not sure.  I don't use Windows unfortunately.   It would be awesome 
if you could take a look and make it work if it doesn't!


-Shammah

Re: SDC needs you -- redux

[Shammah Chancellor via Digitalmars-d]

On 2015-04-20 22:40:10 +, Brian Schott said:


On Sunday, 19 April 2015 at 06:01:14 UTC, weaselcat wrote:
gofmt, much like python's standardized formatting, made contributing to 
go projects much easier IMO. While the same can't be done for D, 
hopefully dfmt becomes a standard tool and each dub project can just 
include a dfmt.conf or something to make contributing easier.


dfmt options go in .editorconfig with the rest of your project's style 
decisions like tabs/spaces and line length.


I agree with the OP on the tooling point, just look at C++. C++ had 
historically zero(okay, some - but it sucked! ctags were awful, etc.) 
tooling before clang hit the scene. IMO clang/LLVM was a complete game 
changer for C++ tooling, and I hope D can do the same.


For what it's worth, D-Scanner can output ctags information for D files.


Clang has a static analyzer, a formatter, a modernizer...
Hell, clang(and obv. libclang) can dump the AST right from its driver, 
and even has autocompletion built into it(-code-completion-at)


We now have a formatter. D-Scanner can perform some static analysis and 
dump an AST from its parser, DCD provides autocompletion. dfix can 
perform syntax upgrades.


Can D-Scanner really provide you with autocompletion for code that is 
from a mixin generated by CTFE?


-Shammah

Re: SDC needs you -- redux

[Shammah Chancellor via Digitalmars-d]

On 2015-04-18 20:39:55 +, weaselcat said:


On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor wrote:

...


Are there any plans for the LDC and SDC team to work together once SDC matures?


I have not had an opportunity to speak with them, but LDC is written in 
C++.   But, I'm sure they have the skills to help us if they want to :)


I was am interested to know if their custom runtime code would be 
something both projects could share.


-Shammah

Re: nginx module bindings

[Shammah Chancellor via Digitalmars-d]

On Saturday, 18 April 2015 at 08:17:15 UTC, Jacob Carlborg wrote:

On 2015-04-18 09:33, Shammah Chancellor wrote:

Yeah, I am at an impasse.  It either segfaults or spits out 
lots
of errors about not being able to find headers despite adding 
all

the -I paths.


Which headers are it complaining about?


Here is the command I was running.

dstep -I~/nginx-build/nginx-1.6.2/objs/ngx_auto_headers.h 
-I../../src/os/unix/ -I ../../src/core -I ../../src/event 
-I~/d/llvm/tools/clang/lib/Headers/ ngx_conf_file.h
File(10B2B20F0, )warning: ../../src/event: 'linker' input 
unused [-Wunused-command-line-argument]
File(10B2B20F0, )warning: ../../src/core: 'linker' input unused 
[-Wunused-command-line-argument]
File(10B2B20F0, )/usr/include/module.map:1:25: warning: unknown 
attribute 'extern_c' [-Wignored-attributes]
File(10B2B20F0, )/usr/include/module.map:36:14: error: header 
'float.h' not found
File(10B2B20F0, )/usr/include/module.map:81:14: error: header 
'stdarg.h' not found
File(10B2B20F0, )/usr/include/module.map:113:14: error: header 
'tgmath.h' not found
File(10B2B20F0, )/usr/include/module.map:1561:21: warning: 
unknown attribute 'extern_c' [-Wignored-attributes]
File(10B2B20F0, )/usr/include/module.map:1577:26: warning: 
unknown attribute 'extern_c' [-Wignored-attributes]
File(10B2B20F0, )/usr/include/module.map:1602:23: warning: 
unknown attribute 'extern_c' [-Wignored-attributes]
File(10B2B20F0, )/usr/include/module.map:1635:23: warning: 
unknown attribute 'extern_c' [-Wignored-attributes]
File(10B2B20F0, )/usr/include/module.map:1662:22: warning: 
unknown attribute 'extern_c' [-Wignored-attributes]
File(10B2B20F0, )./ngx_config.h:12:10: fatal error: 
'ngx_auto_headers.h' file not found

SDC needs you -- redux

[Shammah Chancellor via Digitalmars-d]

I'm going to re-iterate what deadalnix said.   I am doing this because 
the thread about SDC got co-opted in this forums usual fashion.


So, let me qualify:

I've been part of this community since late 2001.  We've come a long 
way.  However,  believe having another *good* frontend implementation 
is absolutely key for our success.


Let me qualify this need with some stats.  I don't mean for this list 
to in any way knock Walter or DMD, but rather to just stress the value 
of SDC to the community and also encourage people who do not want to 
spent the time getting over the learning curve for the DMD frontend to 
invest some time implementing simple things in SDC.


1) SDC, libd-llvm, and libd together are ~ 30KLOC of idiomatic and very 
intelligible D code.  Compare this with the 300KLOC for the DMD 
frontend.
	1.1) The 30KLOC is clean and easy to get into.  It took me less than 3 
days to get into it and start implementing language features.
	1.2) This is enabled by the use of a scheduler to easily handle 
complex Dlang features.
	1.3) This will enable advanced compiler normally be very difficult to 
implement
2) SDC supports a majority of the language at this point, the remaining 
work is mostly trivial. (When I say majority, I mean majority in terms 
of LOC needed to support, not in terms of implemented pieces of 
syntatic sugar)
	2.1) We won't need another 250KLOC to get to 100% feature parity.  
We're already at something like 80% feature parity by my estimation.
3) SDC is designed also to be a library that can used for tooling in an 
easy fashion!
	3.1) I work with Golang on a daily basis professionally.  The tooling 
for golang is a major reason for it's adoption.  This tooling looks 
like gofix, gofmt, govet, etc.  We need this tooling to be able to 
succeed.
4) SDC use of fibers and a scheduler allows us to have a very robust 
error handling mechanism that DMD will never be able to implement.   We 
emit beautiful clang-style errors telling you EXACTLY what is wrong 
with your code.
5) SDC is fast.  It is actually faster than DMD when you move into 
template and CTFE land.

6) SDC leverages all the work done by the HUGE llvm group.
7) SDC uses the LLVM JIT for CTFE, this means no double-implementation 
of language features for CTFE, and for normal compilation.
8) Because SDC is written in D, is clean, and uses a JIT this opens up 
the door for actually exposing compiler AST Nodes *directly* to the 
code being compiled. (!  No more __traits horror when doing 
metaprogramming)
9) Because SDC is clean, easy to understand, and easy to implement 
language feature on top of, we have been able to find quite a few bugs 
in DMD.  I have been submitting bug reports back to DMD and actually 
causing the mainline D compiler to do a *better* job!


I could go on and on about this.  But I would hope that maybe you just 
clone the git repo, and start fiddling around and submit some simple 
PRs.We recently reorganized our git repos to make it much easier 
for people to get started.


Again,  I don't mean for this to come off as a knock against DMD or the 
work that has been done there over the last 15 years.   I also don't 
mean to steal any engineering resources from the DMD frontend.   
Instead, I am hoping to appeal to those people, who like myself, do not 
have the time to understand the DMD frontend and work on it.   SDC is 
simple, and easy to get started on.


So again, here is our TODO list:  
https://github.com/deadalnix/SDC/wiki/TODO-list


I hope you will join Amaury and myself in working on this awesome 
project.   We have a #slack channel set up to help us work 
asynchronously, and I would love it if you send me am email so I can 
invite you to the teamchat.   Even just having people in the channel to 
have discourse with would be helpful!


Cheers,
-Shammah

Re: nginx module bindings

[Shammah Chancellor via Digitalmars-d]

On 2015-04-18 19:15:09 +, Jacob Carlborg said:


On 2015-04-18 17:25, Shammah Chancellor wrote:


File(10B2B20F0, )/usr/include/module.map:36:14: error: header
'float.h' not found
File(10B2B20F0, )/usr/include/module.map:81:14: error: header
'stdarg.h' not found
File(10B2B20F0, )/usr/include/module.map:113:14: error: header
'tgmath.h' not found


These three are Clang built-in headers. They're shipped with Clang and 
need to be place in the standard include paths or explicitly added 
using the -I flag. See the information about libclang [1].


This is fixed in master, the files are shipped with DStep now. 
Although, I may not have included all, I have mostly added them as I 
need.



File(10B2B20F0, )./ngx_config.h:12:10: fatal error:
'ngx_auto_headers.h' file not found


I'm not sure about this but it could be an related to how these headers 
are used. DStep is built to generate bindings from one file at a time. 
That might not always be compatible with the build system a library 
uses. For example, some headers could be generated in a build step. 
I've seen some headers using types without including a single header, 
that still works since another header will include this one plus the 
other headers that are needed.


Please read the limitations at the bottom of the documentation [2] to 
see if any of those apply in your case.


BTW, I updated the code so it can be built with DMD 2.067.0. I'm just 
waiting for the Travis build to pass before merging it to master.


[1] https://github.com/jacob-carlborg/dstep#libclang
[2] https://github.com/jacob-carlborg/dstep#limitationsknown-issues


I included the -I flag for the location of those included headers.  It 
seems as if maybe it is not including anything.   With that said, I am 
using clan release_34, because I cannot build 32 on MacOS X.


-Shammah

Re: nginx module bindings

[Shammah Chancellor via Digitalmars-d]

On Saturday, 18 April 2015 at 06:34:34 UTC, ketmar wrote:

On Fri, 17 Apr 2015 22:50:28 -0700, Shammah Chancellor wrote:


Have you tried dstep?

https://github.com/jacob-carlborg/dstep


I did try to compile it, but it started pulling in tango 1.0 
and whatnot

-- I figured it was not up to date.  Is this wrong?


it will not compile with 2.067, only with 2.066.

dunno if it really works though, as built dstep segfaults when 
i'm trying

to convert anything. the only thing i can see is CLI help.


Yeah, I am at an impasse.  It either segfaults or spits out lots
of errors about not being able to find headers despite adding all
the -I paths.

Re: nginx module bindings

[Shammah Chancellor via Digitalmars-d]

On 2015-04-18 02:24:52 +, Meta said:


On Saturday, 18 April 2015 at 02:03:40 UTC, Shammah Chancellor wrote:

Hello DForum!

I wanted to attempt to write an nginx module in Dlang.  However, the 
first step of generating some bindings is proving to be a pain on 
linux.   Htod is windows only, and the other projects either generate 
incomprehensible modules, or are way out of date (it seems).


Any pointers, or pre-existing bindings for nginx modules would be appreciated.

-Shammah


Have you tried dstep?

https://github.com/jacob-carlborg/dstep


I did try to compile it, but it started pulling in tango 1.0 and 
whatnot -- I figured it was not up to date.  Is this wrong?


-Shammah

nginx module bindings

[Shammah Chancellor via Digitalmars-d]

Hello DForum!

I wanted to attempt to write an nginx module in Dlang.  However, the 
first step of generating some bindings is proving to be a pain on 
linux.   Htod is windows only, and the other projects either generate 
incomprehensible modules, or are way out of date (it seems).


Any pointers, or pre-existing bindings for nginx modules would be appreciated.

-Shammah

Re: Named unittests

[Shammah Chancellor via Digitalmars-d]

On 2015-03-30 21:52:36 +, Andrei Alexandrescu said:

We're having a strong need for named unittests at Facebook for multiple 
reasons.


1. We have sophisticated tooling that verifies whether unittests are 
flaky. The automated monitor (for e.g. C++) figures whether a given 
unittest fails several times across several commits. Unittests are 
identified by name; relying on file/line is impossible because the line 
of a failure is not stable across changes.


2. Again for efficient automated testing and flakiness detection, one 
should be able to run only a subset of unittests by mentioning them by 
line in the command line. Note that this implies there's no 
interdependency between distinct unittests, which is fine because the 
new ability is opt-on; I'd say is pure style anyway.


3. Mentioning unittest names in failure messages helps human 
communication (e.g. AddPeer is failing after your change). This is 
impossible with file and line numbers.


I'd like to make a DIP for named unittests. Who can help me with that?


Andrei


This is a fantastic idea -- and something I was concerned about lately.  +1

I can possibly help with a DIP, but it seems like a very 
straightforward request?


-Shammah

Re: A reason to choose D over Go

[Shammah Chancellor via Digitalmars-d]

On 2015-03-27 19:27:37 +, Martin Nowak said:


On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote:

Also, and this counts for something I think, Go is a trendy
language right now, so when it comes to recruiting, I think
having Go as a critical part of Repustate’s tech stack will help.

Stop the world, I wanna get out!


I was recently told by a commercial D user, that using D helps them to 
more easily identify good programmers.


Every programmer I know who was worth their salt was at least interested in D.

-S.

Re: Mono-D on downloads page?

[Shammah Chancellor via Digitalmars-d]

On 2015-03-27 23:07:39 +, weaselcat said:


On Friday, 27 March 2015 at 22:57:16 UTC, bitwise wrote:

On Friday, 27 March 2015 at 20:56:41 UTC, bitwise wrote:
It's an easy way for people to get started with D, and IMO, Mono-D, 
along with Visual D should be listed right at the bottom of the Getting 
Started page.


http://dlang.org/getstarted.html


would it be accepted if I did a pull request for this?

$(UL
$(LI $(LINK2 http://dlang.org/download.html, $(B Download)) a
compiler.)
$(LI $(LINK2 http://wiki.dlang.org/IDEs, $(B Choose)) an IDE.)
...


+1


+2

Re: A reason to choose D over Go

[Shammah Chancellor via Digitalmars-d]

On 2015-03-25 10:17:00 +, Bienlein said:



I recently made a pull request for a go tool and spent about half an
hour trying to find some function to test whether an array contains a
particular element.


There are libraries for this like gen: 
http://clipperhouse.github.io/gen. But it also suffers from the absence 
of generics.



trust me, from an undecided but experienced developer's
perspective there are so many reasons to choose D over Go. on the
otherhand same person has a lot more reasons to choose Go over D.


I earn my pay with Java development. In my spare time I learn some 
Scala hoping there might be some work for me with Scala in the future. 
Then I need to become familiar with all kinds of new frameworks, tools, 
libraries and systems that continue to pop up every year in the JVM eco 
system.


In the end there is not much time left for playing with a systems 
language. As Go is very effortless it could be a good compromise here. 
I have thrown it away and refetched it due to lack of alternatives 
several times. I would like to play with D, but it has as step a 
learning curve as Scala. If you don't have a background in C or C++ the 
learning curve is even steeper. So it depends a lot from where you are 
coming.



i'm writing a very long blog post about this. if anyone's
interested, i can happily share the draft with them.


Please drop a comment in this thread or somewhere when it is published.

Cheers, Bienlein


D is a superset of go's functionality aside from the structural typing 
(which in my opinion is a huge fail for a variety of reasons you will 
see if you try to use it for anything extensive).  If you don't want to 
learn about templates and metaprogramming, then don't.  I fail to 
understand why having extra features is a deterrant?


-Shammah

Re: Can we deprecate D-style Variadic Functions

[Shammah Chancellor via Digitalmars-d]

On 2015-03-26 01:04:03 +, Freddy said:


On Thursday, 26 March 2015 at 00:11:05 UTC, Dicebot wrote:

On Wednesday, 25 March 2015 at 22:12:04 UTC, Freddy wrote:
D-style Variadic Functions found here:http://dlang.org/function.html 
seem entirely out classed by Variadic Function Templates. Can we 
deprecate them?


Those are two different concepts with different trade-offs. Using 
variadic templates adds template bloat. Using D-style variadics 
requires RTTI (and small overhead for it). It is up to 
library/application writer to decide what is best in his case.


My ploblem is that Variadic Function shouldn't be builtin the language. 
They are rarely need and can be abstracted into a library. Something 
like this:

```
import core.stdc.stdlib: alloca;
import std.stdio;
template VariadicFunction(alias Imp){
auto VariadicFunction(T...)(T args){
enum size=T.length * TypeInfo.sizeof;
auto rtti=cast(TypeInfo[])(alloca(size)[0..size]);
foreach(i,type;T){
rtti[i]=typeid(type);
}
//auto data=args; bug? doesn't work
void* data;
{
size_t datasize;//T.sizeof doesn't work
foreach(type;T){
datasize+=type.sizeof;
}
data=alloca(datasize);
size_t inc;
foreach(v;args){
*cast(typeof(v)*)(data+inc)=v;
inc+=v.sizeof;
}
}
Imp(data,rtti);
}
}

private void rtVariadicImp(void* vars,scope const TypeInfo[] rtinfo){
writeln(*cast(int*)vars);
writeln(rtinfo);
}

alias rtVariadic=VariadicFunction!(rtVariadicImp);

void main(){
rtVariadic(1,'a');
}
```


I disagree, and your example does not get rid of the template bloat.  
That does in fact instantiate a template for every set of argument 
types.


-Shammah

Re: pureity of closures

[Shammah Chancellor via Digitalmars-d]

On 2015-03-23 09:45:39 +, Dicebot said:

I think this was not intended and is simply a side effect of limited D 
call graph analysis. Relaxing that limitation makes sense to me because 
unused impure function can be used for compile-time reflection or 
returned from pure function as a result (you need to ensure it does not 
capture pure functions as closure context in that case)


Pure functions returning impure functions.  *BOOM* My brain just exploded.

-Shammah

Re: Why dont dlang check NullPointer?

[Shammah Chancellor via Digitalmars-d]

On 2015-03-27 05:34:59 +, zhmt said:


On Friday, 27 March 2015 at 04:13:01 UTC, deadalnix wrote:

On Friday, 27 March 2015 at 03:59:30 UTC, zhmt wrote:


The best way to do that is to separate the server modules into 
independent processes. Then if one crashes, the others keep running 
without fear of corruption.


So instead of server modules, try doing mini servers that communicate 
with the main server. This is how a lot of newer programs are written 
because of the reliability and security benefits it offers.


But this will make the developement more difficult for me, or not acceptable.

Is there any other ways?


http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/ 



There is a hook in the runtime to enable this if you want.

BUT, null pointer exception or not, Adam is right. Have your stuff run 
in multiple process that you can restart. This is more reliable, this 
is more secure, this is easier to update without downtime, and so on... 
This is far superior solution for server stuff.


multi-process means crashes are isolated by process, but isolated by 
thread may be more handy.


For example , this feature is suported by java c# lua, ie.

This can make dlang app developed by most developers more reliable.


All the languages you mention run in a VM.   In the case of a systems 
language like D, the operation system itself is intercepting the 
reference to invalid memory and sending a SIGSEG to the process.  The 
default handler causes the process to immediately terminate.   Having 
the D runtime do something different in the SIGSEG handler by default 
would be bad form.


-Shammah

Re: Human unreadable documentation - the ugly seam between simple D and complex D

[Shammah Chancellor via Digitalmars-d]

On 2015-03-26 19:32:51 +, Idan Arye said:

There is a discussion about D vs Go going on in several threads(yey for 
multithreading!), and one thread is about an article by Gary Willoughby 
that claims that Go is not suitable for sophisticated 
programmers(http://forum.dlang.org/thread/mev7ll$mqr$1...@digitalmars.com). 
What's interesting about this one is the reddit comments, which turned 
into an argument between simple languages that average programmers can 
use and complex languages that only the top 1% of intelligent 
programmers can use, but they can extract more out of them.


But the thing is - the world of the top programmers is not really 
separate from that of average programmers. Professional development 
teams can have a few top programmers and many average one, all be 
working on the same project. Open source projects can have top 
programmers working on the core while allowing average programmers to 
contribute some simple features. Top programmers can write libraries 
that can be used by average programmers.


To allow these things, top programmers and average programmers should 
be able to work on the same language. Of course, any language that 
average programmers can master should be easy for a top programmer to 
master - but the thing is, we also want the top programmer to be able 
to bring more out of the language, without limiting them by it's 
over-simplicity. This will also benefit the average programmers, since 
they also improve the quality of the libraries and modules they are 
using.


This idea is nothing new, and was mentioned in the main(=biggest) 
current D vs Go 
thread(http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com?page=3#post-jeuhtlocousxtezoaqqh:40forum.dlang.org). 
What I want to talk about here is the seams. The hurdles that in 
practice make this duality harder.


Let's compare it to another duality that D(and many other languages, 
mainly modern systems languages) promotes - the duality between 
high-level and low-level. Between write-code-fast and write-fast-code.


The transition between high-level and low-level code in D consists by a 
change of the things uses - which language constructs, which idioms, 
which functions. But there aren't any visible seams. You don't need to 
use FFI or to dynamically load a library file written in another 
language or anything like that - you simply write the high-level parts 
like you would write high-level code and the low-level parts like you 
would write low-level code, and they just work together.


The duality between high-level D and low-level D is seamless. The 
duality between simple D and complex D - not so much.


The seams here exist mainly in understanding how to use complex code 
from simple code. Let's take std.algorithm(.*) for example. The 
algorithms' implementations there are complex and use advanced D 
features, but using them is very simple. Provided, of course, that you 
know how to use them(and no - not everything that you know becomes 
simple. I know how to solve regular differential equations, but it's 
still very complex to do so).


The problem, as Andrei Alexandrescu pointed 
out(http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com?page=6#post-mduv1i:242169:241:40digitalmars.com), 
is learning how to use them. Ideally you'd want to be able to look at a 
function's signature and learn from that how to use it. It's name and 
return type should tell you what it does and it's argument names and 
types should tell you what to send to it. The documentation only there 
for a more through description and to warn you about pitfalls and edge 
cases.


But when it comes to heavily templated functions - understanding the 
signature is HARD. It's hard enough for the top programmers that can 
handle the complex D features - it's much harder for the average 
programmers that could have easily used these functions if they could 
just understand the documentation.


Compare it, for example, to Jave. Even if a library doesn't contain a 
single documentation comment, the auto-generated javadoc that contains 
just the class tree and method signatures is usually enough to get an 
idea of what's going where. In D, unless the author has provided some 
actual examples, you are going to have a hard time trying to sort out 
these complex templated signatures...


That's quite an hurdle to go though when wanting to use complex code 
from simple code(or even from other complex code). That's the ugly seam 
I'm talking about.


Now, if you are working on a big project(be it commercial or 
open-source), you can find lot's of examples how to use these complex 
functions, and that's probably how you'd tackle the problem. When you 
are using some library you usually don't have that luxury - but these 
libraries usually have the generated ddoc at their website. Of course - 
that generated ddoc is full with complex templated signatures, so 
that's not very helpful...


So, what can be done? Maybe the ddoc 

Re: dfmt options

[Shammah Chancellor via Digitalmars-d]

On 2015-03-14 23:15:34 +, Brian Schott said:


First, a disclaimer: I am an idiot for starting this thread.

Moving on...

I'm working on a list of configuration options for dfmt - a formatter 
for D source code.


So far I have the following:

* Insert spaces between if, while, for, foreach, etc loops and the (
* Allman vs One True Brace Style (Already supported by commant-line switch)
* Operators at the end of the old line vs beginning of the new line 
when wrapping long expressions.

* Insert space after the ) of a cast expression
* Make case and default match the indent level of the enclosing switch
* Labels for loops always on their own line vs the same line as the loop
* Labels outdented one level
* Label indentation matches the most recent switch
* Hard limit for line length
* Soft limit for line length

What am I missing?


A way to configure this and have it look for the most relevant 
`.dfmtcfg` file! :)


That is to say, make it look up from the current directory recursively 
until it finds a config file, and use that.This will greatly help 
people who are contributing to the same project keep a consistent 
format.  Also,  Hard and soft limit for line length causes an exception 
to be thrown when I tried it.


-Shammah

Re: D usage quotes/badges

[Shammah Chancellor via Digitalmars-d]

On 2015-02-20 21:51:25 +, Shammah Chancellor said:

One thing I've noticed about D vs other languages which are getting 
more interest is that we do not have a list of companies actually 
using D in production on our homepage.   While I know that there are 
quite a few development companies using go, we are not actively 
soliciting them for using their badges.


E.g. Why don't we have a link to Facebook on our homepage?

If you go someplace like http://msgpack.org/ you can clearly see a 
number of companies who effectively use msgpack in production and 
quotes from them.


We should setup something like that on our homepage.

So... Who all is using D in production?

-Shammah


It seems I've been misunderstood/typed the message poorly.   A lot of 
languages are being used because there are examples of other companies 
using the language in production.


D is being used in production, but we are not actively advertising who 
is using it and for what.


I think we should.

-Shammah

Re: DDMD just went green on all platforms for the first time

[Shammah Chancellor via Digitalmars-d]

On 2015-02-21 14:02:47 +, Daniel Murphy said:


https://auto-tester.puremagic.com/?projectid=10

This is a pretty big milestone for the project.  For the first time, an 
unpatched dmd can build ddmd, and that ddmd can build druntime and 
phobos and pass all the test suites.


Hopefully in the next couple of weeks the remaining minor issues will 
be fixed (eg makefile changes, ddmd runs out of memory compiling 
std.algorithm unittests on win64) and we can start adding ddmd to 
master alongside the C++ compiler.


A big thanks to Brad for upgrading the autotester, and to everyone who 
has helped fix bugs and get patches merged over the last couple of 
years.


Github shows 376 closed DDMD pull requests, which is about 8% of all 
dmd pull requests ever.


Awesome!  Now those of us who don't want to work in C++ can start 
helping?  Possibly?


-Shammah

D usage quotes/badges

[Shammah Chancellor via Digitalmars-d]

One thing I've noticed about D vs other languages which are 
getting more interest is that we do not have a list of companies 
actually using D in production on our homepage.   While I know 
that there are quite a few development companies using go, we are 
not actively soliciting them for using their badges.


E.g. Why don't we have a link to Facebook on our homepage?

If you go someplace like http://msgpack.org/ you can clearly see 
a number of companies who effectively use msgpack in production 
and quotes from them.


We should setup something like that on our homepage.

So... Who all is using D in production?

-Shammah

Re: Remove std. from library reference menu?

[Shammah Chancellor via Digitalmars-d]

On 2015-01-24 17:32:15 +, Andrei Alexandrescu said:


Thanks @JinShil! https://github.com/D-Programming-Language/dlang.org/pull/827

The con is that some people may find it confusing, thinking they should 
import algorithm instead of std.algorithm etc.


On the other hand the documentation of each module has std. in clear 
in the heading.



Thoughts?

Andrei


Can we add an io package to std while we're at it and have  std.stdio 
public import it? :)


--
-Shammah

Re: Is anyone working on a D source code formatting tool?

[Shammah Chancellor via Digitalmars-d]

On 2015-01-12 03:23:28 +, deadalnix said:


On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote:

Has someone made a dfmt, like http://gofmt.com/ ?


That is amongst the plans for libd. I'd be happy to support anyone that 
want to work on it :)


This is part of the reason I wanted to de-couple libd's parsing from 
with libd-llvm can currently handle and have separate tests for that 
libd.


Is this something we might be able to consider doing?  We can easily 
have some code and do Code-ast-fmt Code-ast as tests for libd.


-Shammah

Re: CTFE pow()

[Shammah Chancellor via Digitalmars-d]

On 2015-01-01 17:59:09 +, Andrei Alexandrescu said:


Manu via Digitalmars-d digitalmars-d@puremagic.com wrote:

Does anyone know how to fix this? Can we please do so? It's been a
problem for like 5 years it seems.
It's a bit insane that we can't resolve any non-linear functions at
compile time.


I've been hoping for that too for a long time. Application to memoization
tables is immediate and awesome. -- Andrei


I think that SDC can do this already. :D

Re: Is anyone working on a D source code formatting tool?

[Shammah Chancellor via Digitalmars-d]

On 2015-01-10 20:17:34 +, Walter Bright said:


Has someone made a dfmt, like http://gofmt.com/ ?


No, I was planning on working on one if we ever got libd parsing 100% 
of the code.Unfortunately I haven't had a lot of time to work on 
these sorts of things lately.


-Shammah

Re: For the lulz: ddmd vs libdparse lexer timings

[Shammah Chancellor via Digitalmars-d]

On 2015-01-05 00:50:55 +, Brian Schott said:


Looks like it's time to spend some more time with perf:

http://i.imgur.com/k50dFbU.png

X-axis: Meaningless (Phobos module file names)
Y-axis: Time in hnsecs (Lower is better)

I had to hack the ddmd code to get it compile (more 1337 h4x were 
required to compile with LDC than with DMD), so I haven't uploaded the 
code for the benchmark to Github yet.


Both tests were in the same binary and thus had the same compiler flags.


I'd be interested to know where libd sits on here.  It's lexer is very 
clever.  Props to Amaury or Bernhard (whoever wrote it)


-S.

Re: What's missing to make D2 feature complete?

[Shammah Chancellor via Digitalmars-d]

On 2014-12-20 23:27:18 +, aldanor said:


- static foreach (declaration foreach)
- fixing __traits templates (eg getProtection vein extremely flaky, 
allMembers not working etc) -- seeing as ctfe is one of flagship 
features of D, it would make sense to actually make it work flawlessly.


This +10.

I use this stuff in all my D projects since I learned how to do it, and 
it's extremely useful -- but very clunky.


-S.

Re: D and Nim

[Shammah Chancellor via Digitalmars-d]

On 2015-01-04 18:10:51 +, Jonathan said:


Hey folks,

I've been recently checking out Nim/rod and feel like it takes a lot of 
inspiration from D (I think the creator was in the D community too as 
some point). How do you think it compares? What areas does D, in 
principle, makes it a better choice? To give you my background, I like 
creating games (mostly using SDL bindings) using new languages, aiming 
for the most efficient yet concise way to write the engine and game 
logic.


FYI, this is NOT a language war thread. I'm just curious about what 
separates them from a principle level.


I just heard about this language the other hanging out with some other 
techies.   I like that it makes some common idioms in D first-class 
citizens.   For example, imperative type declarations are first-class 
citizens so all the boiler plate around if (isInputRange!(R)) type 
stuff goes away in Nim.  Unfortunately, they decided to use whitespace 
to define scope :/


-S.

Re: Why does std.container.BinaryHeap use RefCounted?

[Shammah Chancellor via Digitalmars-d]

On 2014-12-16 07:57:32 +, Tobias Pankrath said:


Original: http://forum.dlang.org/thread/uapqmdbtadpwnciwf...@forum.dlang.org
Reposting here, because I got no answer in D.learn:

std.container.BinrayHeap
(http://dlang.org/library/std/container/BinaryHeap.html)
implements a binary heap on top of a) a given random access range
or b) another container that supports random access.

Regardless of it's underlying data structure type, it wraps its
store in RefCounted, but I don't see why this is necessary.

In case b) the container itself uses reference counting, so
holding a simple reference to a container should be enough.

In case a) the given range might use ref counting under the hood,
see b). Or not, than it is probably relying on the GC, and no
reference count is needed.


I ran into the same issue with one of the other containers the other 
day.  It was causing me a substantial amount of confusion has it was 
automatically deallocating things I put into it for reasons I did not 
care to understand at the time.


-Shammah

Re: DIP69 - Implement scope for escape proof references

[Shammah Chancellor via Digitalmars-d]

On 2014-12-04 09:24:13 +, Walter Bright said:


http://wiki.dlang.org/DIP69

Despite its length, this is a fairly simple proposal. It adds the 
missing semantics for the 'scope' storage class in order to make it 
possible to pass a reference to a function without it being possible 
for it to escape.


This, among other things, makes a ref counting type practical. It also 
makes it more practical to use other storage allocation schemes than 
garbage collection.


It does not make scope into a type constructor, nor a general 
type-annotation system.


It does not provide an ownership system, though it would complement one.


I like the basics of the proposal and I think it's the right direction. 
HOWEVER, I strongly believe that function arguments should be scoped 
by default and `impure` when they take reference which they will keep.


-Shammah

Re: DIP69 - Implement scope for escape proof references

[Shammah Chancellor via Digitalmars-d]

On 2014-12-04 10:00:28 +, Walter Bright said:


On 12/4/2014 1:51 AM, eles wrote:

On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:

http://wiki.dlang.org/DIP69

Despite its length, this is a fairly simple proposal. It adds the missing
semantics for the 'scope' storage class in order to make it possible to pass a
reference to a function without it being possible for it to escape.


Making it implicit and requiring an explicit escape for un-scoped variables?



Was afraid that would break too much code.


No, this is super important.  Break it all!  This kind of change will 
significantly increase the performance of D code by almost eliminating 
GC thrashing.


Having to type scope EVERYWHERE will make it unused and therefore 
unusable in other people's libraries.


-Shammah.

Re: DIP69 - Implement scope for escape proof references

[Shammah Chancellor via Digitalmars-d]

On 2014-12-11 07:03:58 +, Shammah Chancellor said:


On 2014-12-04 09:24:13 +, Walter Bright said:


http://wiki.dlang.org/DIP69

Despite its length, this is a fairly simple proposal. It adds the 
missing semantics for the 'scope' storage class in order to make it 
possible to pass a reference to a function without it being possible 
for it to escape.


This, among other things, makes a ref counting type practical. It also 
makes it more practical to use other storage allocation schemes than 
garbage collection.


It does not make scope into a type constructor, nor a general 
type-annotation system.


It does not provide an ownership system, though it would complement one.


I like the basics of the proposal and I think it's the right direction. 
 HOWEVER, I strongly believe that function arguments should be scoped 
by default and `impure` when they take reference which they will keep.


-Shammah


Also, more feedback.   I would suggest that scope variable are the 
default inside of functions as well as parameters.   Using escape 
analysis, instead of them being errors, make them warnings and 
implicitly make them impure.


-Shammah

Re: DIP69 - Implement scope for escape proof references

[Shammah Chancellor via Digitalmars-d]

On 2014-12-05 15:27:41 +, Steven Schveighoffer said:


On 12/4/14 4:24 AM, Walter Bright wrote:

http://wiki.dlang.org/DIP69

Despite its length, this is a fairly simple proposal. It adds the
missing semantics for the 'scope' storage class in order to make it
possible to pass a reference to a function without it being possible for
it to escape.

This, among other things, makes a ref counting type practical. It also
makes it more practical to use other storage allocation schemes than
garbage collection.

It does not make scope into a type constructor, nor a general
type-annotation system.

It does not provide an ownership system, though it would complement one.


Can we take a step back here?

I read many people's comments and I understand only about half of them.

Can someone who knows what this new feature is supposed to do give some 
Ali Çehreli-like description on the feature? Basically, let's strip out 
the *proof* in the DIP (the how it works and why we have it), and focus 
on how it is to be used.


I still am having a hard time wrapping my head around the benefits and 
when to use scope, scope ref, why I would use it. I'm worried that we 
are adding all this complication and it will confuse the shit out of 
users, to the point where they won't use it.


-Steve


This is exactly why this feature should be default behavior with 
compiler warnings generated when things escape scope.


The basic idea is that most things should be on the stack and go away 
when the stack goes away.   The proposal codifies how the compiler 
should infer that references to variables which are to be placed on the 
stack are not escaping their scope.   The benefit is that the GC has to 
do *way* less work from what it has to do now for most of the use cases 
of D.


-Shammah

Re: D Meetup in SF?

[Shammah Chancellor via Digitalmars-d]

On 2014-12-08 16:06:45 +, Martin Nowak said:


On 12/05/2014 09:15 AM, Shammah Chancellor wrote:

I didn't notice a D meetup group in SF.  Is anyone else in here
interested in doing something like this once a month?


We could have a video cast over to the Berlin meetup :).


That would be really awesome.   We really need to get this stuff going. 
I think meetups are a great way to evangelize.


-S.

Re: D Meetup in SF?

[Shammah Chancellor via Digitalmars-d]

On 2014-12-05 20:08:28 +, Vic said:


http://www.meetup.com/D-Lang-Sillicon-Valley
in Sunnyvale.

First meeting in Jan., and then every 6 weeks

Room holds 2 - 500, sponsored by Apakau

Looking for co-organizers to meet w/ ahead of first meeting.

I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist 
meeting and take it from there.


I was thinking of something in SF proper, but Sunnyvale may be possible for me.

-S

D Meetup in SF?

[Shammah Chancellor via Digitalmars-d]

I didn't notice a D meetup group in SF.  Is anyone else in here 
interested in doing something like this once a month?


-S.

Re: Do everything in Java?

[Shammah Chancellor via Digitalmars-d]

On 2014-12-04 14:12:32 +, Ola Fosheim Grøstad said:

I did not find that odd, they are not perceived as stable and proven. 
Go is still working on finding the right GC solution.


There are quite a few companies using Go in production.

-S.

Splitting stdio, etc.

[Shammah Chancellor via Digitalmars-d]

Will a PR for splitting stdio up into a package require a DIP?  It 
should not be a breaking change -- correct?  Some of the standard 
module files are very substantial at this point and require quite a bit 
of work to compile a simple Hello World application.

alias foo = __traits(...)

[Shammah Chancellor via Digitalmars-d]

Is this fixed now?  I don't want to denigrate the work to get C++ 
compatibility and the GC improvements.  But, this is the biggest hurdle 
I have when introducing new people into D.   I'm a huge compile time 
reflection proponent, and having alias hack(T...) = T makes the code 
look very buggy to newcomers.


Please don't say where is the PR?  When I have time,  I will fix it.  
The learning curve on the frontend is non-trivial and I'm not a 
talented C++ dev.   I will definitely dig in and get at that bug, as 
it's my biggest nit at the moment.


-S.

Code Coverage and SDC

[Shammah Chancellor via Digitalmars-d]

So,  I'm trying to setup code coverage to ensure that we are testing 
100% of the SDC LOC when we run our tests.


Issues I'm having:

1) Combined lst files from multiple results.

2) Seems to be some conditions on when lst files are generated.  If the 
binary is invoked from somewhere other than where it was compiled, or 
the source and obj files are not around it doesn't generate anything.


3) Given 2 above,  how do you get cov on libraries included in another binary?

I'm sure there are other issues, but those are the ones I've run into so far.

Any ideas?

As an aside, has anyone tried to do this with ddmd?

-S.

Re: Generating code based on UDA

[Shammah Chancellor via Digitalmars-d-learn]

On 2014-10-25 13:37:54 +, Rares Pop said:


Hello everyone,

I am trying to understand UDA traits scoping while mixing in code.
Aiming to generate code based on UDA I wonder if the following is possible:

class A
{
@Inject
Logger logger;

@Inject
SomeOtherClass dependency;

mixin injections!(A)

...
}

In injections function I want to iterate through members annotated 
with the @Inject attribute and generate some specific code.

So far in my attempts the compiler complains about unknown identifier A.
Should the A class be available to the compiler at the time of the 
mixin invocation?


Thanks for your help,
Rares


Very much possible.  Since I don't see what your template is doing, I'm 
going to give it a guess:


class A{
mixin injections;
}

template injections
{

 typeof(this);  // e.g. foreach( tra; 
__traits(getAttributes, typeof(this)))



}


typeof(this) will be A.

Re: Value Range Propigation Spec

[Shammah Chancellor via Digitalmars-d]

On 2014-10-22 20:32:35 +, Walter Bright said:


On 10/22/2014 2:31 AM, Shammah Chancellor wrote:

A couple of us working on SDC are trying to get ValueRange propigation
implemented.   I was wonder if someone could offer some insight as to how VRP
works in DMD.   If for example, trying to get the value range of a global, what
is the expected behavior?

It seems as though VRP is a language feature, and not a compiler feature --
since this allows some code to compile and not others.   Is there a
specification for how it should work somewhere?  If not, it's hard to implement
other compilers that will not generate errors in the same circumstances as DMD.



VRP is definitely a language feature, not a compiler feature. The 
specification is straightforward - a narrowing conversion can be 
implicitly performed if it can be proved that it would not lose 
information.


How it works, though, is kinda tricky, and the only guide to it is the 
compiler source code.



Walter,

Several of us working on it were a little surprised that DMD does not 
compile this:


void main() {
long l = 42;
int i = l;
}

Is this expected to compile?  Planned? My post was based on my 
thought that this *did* compile and we were wondering rules for when 
the range would be reset.   If `l` were __gshared for example, the 
range wouldn't be deterministic.


Surely there should be some rules document?  What we've implemented, is 
that the value range is calculated at float80 precision, and it's min 
and max can fit in the ultimate type for a cast, then it's good to go.  
We only look at the actual expression being implicitly cast.



Thanks,
-Shammah

Value Range Propigation Spec

[Shammah Chancellor via Digitalmars-d]

A couple of us working on SDC are trying to get ValueRange propigation 
implemented.   I was wonder if someone could offer some insight as to 
how VRP works in DMD.   If for example, trying to get the value range 
of a global, what is the expected behavior?


It seems as though VRP is a language feature, and not a compiler 
feature -- since this allows some code to compile and not others.   Is 
there a specification for how it should work somewhere?  If not, it's 
hard to implement other compilers that will not generate errors in the 
same circumstances as DMD.

RFC: std.concepts

[Shammah Chancellor via Digitalmars-d]

It was request that I create a NG thread about a module I was hoping to 
merge with phobos. (std.concepts)  Please take a look.


Thanks in advance.

-S

Link to PR:

https://github.com/D-Programming-Language/phobos/pull/2627

Docs:


bool isConcept(T, C, bool diagnostics = false, string errorPrefix = )();
Returns true if T supports the concept C. Note, templated member 
functions are not supported currently.


Concepts should be defined as in the following example:

class CInputRange(E) : Concept
{
abstract void popFront();
@property abstract E front();
bool empty;

	//Optional axioms function.  This will be checked if it compiles, and 
that it returns true if it does.

static bool axioms(T)()
{
return true;
}
}

class CInfinite() : Concept
{
static bool axioms(T)() {
enum empty = T.empty;
return !empty;
}
}

class CInfiniteInputRange(E) : CInputRange!E
{
mixin CInfinite;
}
---

template conceptDiagnostic(R, string F, int L, C...)
Prints error messages for why template instantiation failed.

Examples:
---
bool DoStuff(R)(R infRange) if ( isConcept!(R, CInfiniteInputRange!string))
{
return true;
}

bool DoStuff(R)(R infRange) if ( isConcept!(R, COutputRange!string))
{
return true;
}

//Example of using conceptDiagnostic
bool DoStuff(R, string F = __FILE__, size_t L = __LINE__ )(R infRange)
{
	mixin conceptDiagnostic!(R, F, L, COutputRange!string, 
CInfiniteInputRange!string);

return false;
}
---

class Concept;
Base class for Concepts. All Concepts should derive from this, or 
another concept.

Re: RFC: std.concepts

[Shammah Chancellor via Digitalmars-d]

On 2014-10-19 22:14:29 +, Hpkl said:


On Sunday, 19 October 2014 at 21:10:12 UTC, Shammah Chancellor wrote:
It was request that I create a NG thread about a module I was hoping to 
merge with phobos. (std.concepts)  Please take a look.


Thanks in advance.



So basically it allows, at compile time, to check that an agregate 
contains all the primitive methods defined in a concept, and 
eventually it diagnoses accurately which axiom is missing ? right ?


e.g the the assertion in http://dpaste.dzfl.pl/08f740ac5e48
would be correct ?


It can't give messages about the particular axioms that fail without 
spliting them up into individual axioms -- and that's definitely 
something to consider.


However, axioms are usually fairly rare in concepts AFAIK.  You can 
instead write the following, and it will tell you what's missing.


class CLutFunc1: Concept
{
void prepare(in uint sampling);
float get(in float x);
}

-S.

Re: template constraint diagnostics

[Shammah Chancellor via Digitalmars-d]

On 2014-10-15 17:29:33 +, Trass3r said:


http://youtu.be/qwXq5MqY2ZA?t=33m57s

I wish we had diagnostics like that in D.


I have answered your call:

https://github.com/D-Programming-Language/phobos/pull/2627

Please comment.

-S.

Re: template constraint diagnostics

[Shammah Chancellor via Digitalmars-d]

On 2014-10-18 21:52:30 +, Shammah Chancellor said:


On 2014-10-15 17:29:33 +, Trass3r said:


http://youtu.be/qwXq5MqY2ZA?t=33m57s

I wish we had diagnostics like that in D.


I have answered your call:

https://github.com/D-Programming-Language/phobos/pull/2627

Please comment.

-S.


I don't know if anyone looked at this yet, but I've updated it quite a 
bit since the original post.   Please take a look again and comment.   
It also generates some useful DDoc now.


Docs:


bool isConcept(T, C, bool diagnostics = false, string errorPrefix = )();
Returns true if T supports the concept C. Note, templated member 
functions are not supported currently.


Concepts should be defined as in the following example:

class CInputRange(E) : Concept
{
abstract void popFront();
@property abstract E front();
bool empty;

	//Optional Axioms function.  This will be checked if it compiles, and 
that it returns true if it does.

static bool Axioms(T)()
{
return true;
}
}

class CInfinite() : Concept
{
static bool Axioms(T)() {
enum empty = T.empty;
return !empty;
}
}

class CInfiniteInputRange(E) : CInputRange!E
{
mixin CInfinite;
}
---

template conceptDiagnostic(R, string F, int L, C...)
Prints error messages for why template instantiation failed.

Examples:
---
bool DoStuff(R)(R infRange) if ( isConcept!(R, CInfiniteInputRange!string))
{
return true;
}

bool DoStuff(R)(R infRange) if ( isConcept!(R, COutputRange!string))
{
return true;
}

//Example of using conceptDiagnostic
bool DoStuff(R, string F = __FILE__, size_t L = __LINE__ )(R infRange)
{
	mixin conceptDiagnostic!(R, F, L, COutputRange!string, 
CInfiniteInputRange!string);

return false;
}
---

class Concept;
Base class for Concepts. All Concepts should derive from this, or 
another concept.

dub configuration for external dependencies

[Shammah Chancellor via Digitalmars-d]

I'm not sure where the appropriate place to ask about dub is.  There 
doesn't seem to be a newsgroup for it?


Anyways,  I am wondering what the proper way to deal with external 
non-D dependencies is.   For example, libd-llvm uses a lot of libraries 
from LLVM whose library path changes from machine to machine, and some 
of the list of 30 libraries changes as well.   They have a nice 
configuration tool llvm-config which emits ldflags which are very nice 
to use from makefiles but I don't see any way to obtain this 
information from within the dub.json.


Do I essentially need to make an autotools-esque script to generate the 
dub.json?  That seems to be at odds with the ability to register 
packages.


-S

Re: Will D ever get optional named parameters?

[Shammah Chancellor via Digitalmars-d]

On 2014-10-13 19:18:38 +, Walter Bright said:


On 10/13/2014 7:23 AM, Ary Borenszweig wrote:

On 10/13/14, 5:47 AM, Walter Bright wrote:

On 10/13/2014 1:29 AM, 岩倉 澪 wrote:

Are there good reasons not to add something like this to the language,
or is it
simply a matter of doing the work? Has it been discussed much?


Named parameters interact badly with overloading.


Could you give an example?


Nothing requires function overloads to use the same names in the same 
order for parameters. color can be the name for parameter 1 in one 
overload and for parameter 3 in another and not be there at all for a 
third.


Parameters need not be named in D:

int foo(long);
int foo(ulong x);

Named parameters are often desired so that default arguments need not 
be in order at the end:


int foo(int x = 5, int y);
int foo(int y, int z);

To deal with all this, a number of arbitrary rules will have to be 
created. Overloading is already fairly complex, with the implemented 
notions of partial ordering. Even if this could all be settled, is it 
worth it? Can anyone write a document explaining this to people? Do 
people really want pages and pages of specification for this?


Not to mention, that despite C# supporting this, MSFT's code analysis 
generates a warning and instead recommends providing more overloads.


-S.

Re: Why this doesn't compile?

[Shammah Chancellor via Digitalmars-d]

On 2014-10-11 18:10:52 +, ketmar via Digitalmars-d said:


On Sat, 11 Oct 2014 18:01:39 +
Uranuz via Digitalmars-d digitalmars-d@puremagic.com wrote:


Is it a bug?

yes. this is a bug in your code. and it's not alone.


image


I've withheld from responding to you for a good long while.  But, what 
is your deal Ketmar?  You're constantly trolling on this newsgroup.   
It's not appreciated.

Re: Why this doesn't compile?

[Shammah Chancellor via Digitalmars-d]

On 2014-10-11 18:10:22 +, Adam D. Ruppe said:


On Saturday, 11 October 2014 at 18:01:41 UTC, Uranuz wrote:

When I want to pass generic String by const reference I get an error.


Strings are passed by reference automatically, so you wouldn't want to 
double reference them anyway.


That's not entirely true.  They're passed by value unless something 
changed.   By value in that the struct representation is passed.  That 
is to say, the length and a pointer.




As far as I understand const should accept both mutable and immutable 
data. And there I want to pass it by reference.


Yes, but since foo isn't an lvalue (variable), you can't pass it by 
ref in D, even if it is const. This differs from C++, but I don't 
recall the reason, I think there's just too many weird edge cases that 
D wanted to avoid.


But in the case of strings, arrays, classes, pointers, and user defined 
structs that wrap these, you don't need to pass it as ref at all, just 
use plain const.


That's because string literals are stored in the data segment and are 
immutable rvalues.  You can't have a ref to an rvalue.

Re: Who pays for all this?

[Shammah Chancellor via Digitalmars-d]

On 2014-10-06 04:09:26 +, Andrei Alexandrescu said:


On 10/5/14, 7:28 PM, Shammah Chancellor wrote:

There are many languages which have grown more quickly than D (despite
being less interesting) because they have a foundation where people can
donate, or some company, which provides for the core developers.   I'm
not saying that having a non-profit will magically generate money, but
there are a few companies who use D out there who just might be willing
to donate non-trivial sums of money to further development if there was
a non-profit to see that the money was put to good use.

Just to name a few:

Python: https://www.python.org/psf-landing/
Node.JS:  http://www.joyent.com/
Perl: http://www.perlfoundation.org
Linux Core Developers: http://en.wikipedia.org/wiki/Linux_Foundation
Ruby Core Developers: https://www.heroku.com (A subsidiary of Salesforce)


C++ also has a foundation since 2012: 
http://pocoproject.org/blog/?p=671. It paid for CppCon 2014, which was 
very successful.


I believe a foundation would help D. Unfortunately, setting one up is 
very laborious, and neither Walter nor I know anything about that - 
from what I understand it takes a _lot_ of work. If anyone is able and 
willing to embark on creating a foundation for D, that would be a great 
help to the language and its community.


Andrei


I'm willing to put in the work if Walter is on board also.  I don't 
want to do all that work to end up being a DPL Foundation in name only.


-Shammah

Re: Who pays for all this?

[Shammah Chancellor via Digitalmars-d]

On 2014-10-06 22:28:52 +, Andrei Alexandrescu said:


On 10/6/14, 12:59 PM, Shammah Chancellor wrote:

I'm willing to put in the work if Walter is on board also.  I don't want
to do all that work to end up being a DPL Foundation in name only.


That's very generous of you, thanks! We'll discuss this. From what I 
read at http://lwn.net/Articles/561336/, my understanding is that we'll 
need significant ongoing expenses in additional to the initial setup 
expenditure of time and money. Anyone who knows more about this please 
chime in. -- Andrei


I'll start doing some research.   To be forward,  I am 100% ignorant of 
the process at the moment as well.


-S.

Re: What are the worst parts of D?

[Shammah Chancellor via Digitalmars-d]

On 2014-09-25 01:54:26 +, H. S. Teoh via Digitalmars-d said:

On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via 
Digitalmars-d wrote:

On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:

You're misrepresenting my position.*In spite of their current flaws*,
modern build systems like SCons and Tup already far exceed make in
their basic capabilities and reliability.


Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: Be
the change you want to see in dlang's build system :o). -- Andrei


Well, Cliff  I (and whoever's interested) will see what we can do about
that. Perhaps in the not-so-distant future we may have a D build tool
that can serve as the go-to build tool for D projects.

T



Please submit PRs for dub, instead of creating a new project.   Dub is 
a nice way of managing library packages already.   I'd rather not use 
two different tools.

Re: Who pays for all this?

[Shammah Chancellor via Digitalmars-d]

On 2014-10-05 03:33:36 +, Walter Bright said:

We're not really limited by lack of funds, but more by lack of focussed 
effort. If anyone wants to contribute funds, probably the best use 
would be to add bug bounties for bugzilla issues that they find to be 
neglected. The bounties don't really compensate at professional rates, 
but they do work as a nice thanks to those who donate their valuable 
time.


I've placed a couple of anonymous bounties, but I personally think it's 
a bad way to get directed focused effort.  A democracy of people trying 
to get what they individually want done through small donations?


There are many languages which have grown more quickly than D (despite 
being less interesting) because they have a foundation where people can 
donate, or some company, which provides for the core developers.   I'm 
not saying that having a non-profit will magically generate money, but 
there are a few companies who use D out there who just might be willing 
to donate non-trivial sums of money to further development if there was 
a non-profit to see that the money was put to good use.


Just to name a few:

Python: https://www.python.org/psf-landing/
Node.JS:  http://www.joyent.com/
Perl: http://www.perlfoundation.org
Linux Core Developers: http://en.wikipedia.org/wiki/Linux_Foundation
Ruby Core Developers: https://www.heroku.com (A subsidiary of Salesforce)

-S

Re: scope() statements and return

[Shammah Chancellor via Digitalmars-d]

On 2014-10-05 11:28:59 +, monarch_dodra said:


On Saturday, 4 October 2014 at 18:42:05 UTC, Shammah Chancellor wrote:
Didn't miss anything.  I was responding to Andrei such that he might 
think it's not so straightforward to evaluate that code.
I am with you on this.  It was my original complaint months ago that 
resulted in this being disallowed behavior.  Specifically because you 
could stop error propigation by accident even though you did not intend 
to prevent their propigation.  e.g:


int main()
{
scope(exit) return 0;
assert(false, whoops!);
}

-S


Isn't this the should scope(exit/failure) catch Error issue though?

In theory, you should seldom ever catch Errors. I don't understand why 
scope(exit) are catching them.


It doesn't catch the error. Propigation should continue as normal.  
However, in the case I gave a return statement is executed in a cleanup 
block before propigation can continue.   As has been pointed out, this 
is just like a finally{} block and it behaves the same way.   Throws, 
and returns should be prohibited from those as well.

Re: scope() statements and return

[Shammah Chancellor via Digitalmars-d]

On 2014-10-04 06:09:39 +, H. S. Teoh via Digitalmars-d said:

On Sat, Oct 04, 2014 at 01:08:38AM -0400, Shammah Chancellor via 
Digitalmars-d wrote:

On 2014-10-03 19:35:31 +, Andrei Alexandrescu said:

[...]

Worse yet:

// What does this function do? What *should* it do??
int func() {
scope(success)
throw new Exception();
scope(failure)
return 1;
return 0;
}


1


This throws an exception, as it's already outside of the
scope(failure) block and into the finally for success;

[...]

And if you switched the two scope statements?

I think you guys are missing the point... The point is that it's
ridiculous for the function to return one thing, only for the scope
statement to modify that return value after the fact in a way that
totally obfuscates the code.

int func() {
lots();
of();
scope(exit) return 1;
code();
inBetween();

// What does this function return? Yes, obviously it
// returns 1. Right.
return 0;
}

Similarly, allowing scope to do arbitrary things will easily turn your
loops into spaghetti code:

foreach (i; 0 .. 10)
{
scope(exit) break;
scope(success) continue;
if (i==5)
break;
// Yeah right, this doesn't actually break
// (even though it's totally broken :-P)

scope(failure) return;
if (i==8)
throw new Exception();
// Yeah right, this is just a dainbramaged way
// of breaking the loop
}
writeln(You know I actually get run?);

The only use of allowing these disruptive flow control constructs in
scope statements, that I can see, is to facilitate in writing entries
for the International Obfuscated D Code Contest.


T


Didn't miss anything.  I was responding to Andrei such that he might 
think it's not so straightforward to evaluate that code.   I am with 
you on this.  It was my original complaint months ago that resulted in 
this being disallowed behavior.  Specifically because you could stop 
error propigation by accident even though you did not intend to prevent 
their propigation.  e.g:


int main()
{
scope(exit) return 0;
assert(false, whoops!);
}

-S

Re: scope() statements and return

[Shammah Chancellor via Digitalmars-d]

On 2014-10-04 21:44:43 +, Andrei Alexandrescu said:


On 10/3/14, 8:01 PM, deadalnix wrote:

On Friday, 3 October 2014 at 19:35:21 UTC, Andrei Alexandrescu wrote:

I guess I'm convinced it adds more complication than expressiveness!



True for return, but throw is a stupid limitation( as it do not prevent
the scope to throw at all, simply forc to hide it, which is only worse).


Yah, nonlocal returns are odd but throw should be perfectly fine (and 
good to have). -- Andrei


They were removed because they stop the propigation of Errors when and 
if they were to throw.  This was already discussed quite a bit months 
ago.  My original message was not intended to respawn the debate.


Here's the dbug: https://issues.dlang.org/show_bug.cgi?id=11574

I'm not sure why it's still open actually.

-Shammah

issues.dlang.org utilization?

[Shammah Chancellor via Digitalmars-d]

There are currently 3588 issues in some open state, and zero 
closed/resolved issues.   This seems dubious to me.  Shouldn't issues 
be closed when the PR is merged?  Have I made some mistake with my 
bugzilla query?


-S.

Who pays for all this?

[Shammah Chancellor via Digitalmars-d]

I've been a member of the D community for about 13 years now, and I'm 
impressed with how much has happened over that period of time with the 
language and community.   However, I wonder who pays for all of this?   
I feel like a lot of the infrastructure is taken for granted, and 
provided ad-hoc by members of the community and/or Walter Bright from 
his non-D ventures.


Might it be time for a formation of a D Programming Language Foundation 
to which people can donate and funds some of the hosting, and possibly 
pay for some time of the various heavy contributors?


-Shammah

Re: What are the worst parts of D?

[Shammah Chancellor via Digitalmars-d]

On 2014-09-25 23:23:06 +, H. S. Teoh via Digitalmars-d said:

On Thu, Sep 25, 2014 at 03:48:11PM -0700, Andrei Alexandrescu via 
Digitalmars-d wrote:

On 9/25/14, 2:03 PM, eles wrote:

On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:


lack of attention paid to tightening up what we've already got and
deprecating old stuff that no one wants any more.  And inconsistency
in how things work in the language.


The feeling that I have is that if D2 does not get a serious cleanup
at this stage, then D3 must follow quickly (and such move will be
unstoppable), otherwise people will fall back to D1 or C++next.


I'm not sharing that feeling at all. From that perspective all
languages are in need of a serious cleanup. -- Andrei


I mean, enterprises use deprecation cycles with their products all the
time, and we don't hear of customers quitting just because of that. Some
of the more vocal customers will voice their unhappiness, but as long as
you're willing to work with them and allow them sufficient time to
migrate over nicely and phase out the old stuff, they're generally
accepting of the process.


Unless you're Oracle -- in which case you end up with a horrible 
amalgamation of poorly thought out features.  Features which work in 
such narrow cases that they're mostly useless.


-S

Re: scope() statements and return

[Shammah Chancellor via Digitalmars-d]

On 2014-10-03 19:35:31 +, Andrei Alexandrescu said:


Better yet:

int func() {
scope(exit)
return 1;
scope(exit)
return 2;
return 0;
}


2


That should return 1 as the return 1 is the last thing to execute.   
SDC currently doesn't disallow this and correctly produces 1.


It'll be lowered as such:

int foo2()
{
try {
try {
return 0;
} finally {
return 2;
}
} finally {
return 1;
}
}





Worse yet:

// What does this function do? What *should* it do??
int func() {
scope(success)
throw new Exception();
scope(failure)
return 1;
return 0;
}


1


This throws an exception, as it's already outside of the scope(failure) 
block and into the finally for success;


-S

Re: scope() statements and return

[Shammah Chancellor via Digitalmars-d]

On 2014-10-03 20:18:44 +, David Nadlinger said:


On Friday, 3 October 2014 at 17:50:29 UTC, Andrei Alexandrescu wrote:

On 10/2/14, 8:23 PM, Ali Çehreli wrote:

A scope(exit) or scope(success) statement may not exit with a throw,
goto, break, continue, or return; nor may it be entered with a goto.


Seems to me all these restrictions should be lifted. -- Andrei


Unless we have very good reason, the same restrictions as for finally 
blocks (i.e. the actual lowering) should apply.


David


They do.

scope() statements and return

[Shammah Chancellor via Digitalmars-d]

Per the documentation (http://dlang.org/statement.html) scope 
statements are not precluded from returning, but DMD does not allow for 
it.   Should the documentation be updated?


-S

Re: scope() statements and return

[Shammah Chancellor via Digitalmars-d]

On 2014-10-03 03:23:24 +, Ali Çehreli said:

A scope(exit) or scope(success) statement may not exit with a throw, 
goto, break, continue, or return; nor may it be entered with a goto


Derp.  I did not see that.  I was looking at the grammar on the top.

Re: RFC: moving forward with @nogc Phobos

[Shammah Chancellor via Digitalmars-d]

On 2014-09-29 10:49:52 +, Andrei Alexandrescu said:

Back when I've first introduced RCString I hinted that we have a larger 
strategy in mind. Here it is.


The basic tenet of the approach is to reckon and act on the fact that 
memory allocation (the subject of allocators) is an entirely distinct 
topic from memory management, and more generally resource management. 
This clarifies that it would be wrong to approach alternatives to GC in 
Phobos by means of allocators. GC is not only an approach to memory 
allocation, but also an approach to memory management. Reducing it to 
either one is a mistake. In hindsight this looks rather obvious but it 
has caused me and many people better than myself a lot of headache.


That said allocators are nice to have and use, and I will definitely 
follow up with std.allocator. However, std.allocator is not the key to 
a @nogc Phobos.


Nor are ranges. There is an attitude that either output ranges, or 
input ranges in conjunction with lazy computation, would solve the 
issue of creating garbage. 
https://github.com/D-Programming-Language/phobos/pull/2423 is a good 
illustration of the latter approach: a range would be lazily created by 
chaining stuff together. A range-based approach would take us further 
than the allocators, but I see the following issues with it:


(a) the whole approach doesn't stand scrutiny for non-linear outputs, 
e.g. outputting some sort of associative array or really any composite 
type quickly becomes tenuous either with an output range (eager) or 
with exposing an input range (lazy);


(b) makes the style of programming without GC radically different, and 
much more cumbersome, than programming with GC; as a consequence, 
programmers who consider changing one approach to another, or 
implementing an algorithm neutral to it, are looking at a major rewrite;


(c) would make D/@nogc a poor cousin of C++. This is quite out of 
character; technically, I have long gotten used to seeing most 
elaborate C++ code like poor emulation of simple D idioms. But C++ has 
spent years and decades taking to perfection an approach without a 
tracing garbage collector. A departure from that would need to be 
superior, and that doesn't seem to be the case with range-based 
approaches.


===

Now that we clarified that these existing attempts are not going to 
work well, the question remains what does. For Phobos I'm thinking of 
defining and using three policies:


enum MemoryManagementPolicy { gc, rc, mrc }
immutable
 gc = ResourceManagementPolicy.gc,
 rc = ResourceManagementPolicy.rc,
 mrc = ResourceManagementPolicy.mrc;

The three policies are:

(a) gc is the classic garbage-collected style of management;

(b) rc is a reference-counted style still backed by the GC, i.e. the GC 
will still be able to pick up cycles and other kinds of leaks.


(c) mrc is a reference-counted style backed by malloc.

(It should be possible to collapse rc and mrc together and make the 
distinction dynamically, at runtime. I'm distinguishing them statically 
here for expository purposes.)


The policy is a template parameter to functions in Phobos (and 
elsewhere), and informs the functions e.g. what types to return. 
Consider:


auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1 path, R2 ext)
if (...)
{
 static if (mmp == gc) alias S = string;
 else alias S = RCString;
 S result;
 ...
 return result;
}

On the caller side:

auto p1 = setExtension(hello, .txt); // fine, use gc
auto p2 = setExtension!gc(hello, .txt); // same
auto p3 = setExtension!rc(hello, .txt); // fine, use rc

So by default it's going to continue being business as usual, but 
certain functions will allow passing in a (defaulted) policy for memory 
management.


Destroy!


Andrei


I don't like the idea of having to pass in template parameters 
everywhere -- even for allocators.  Is there some way we could have 
allocator contexts?


E.G.

with( auto allocator = ReferencedCounted() )
{
auto foo = setExtension(hello, txt);
}

ReferenceCounted() could replace a thread-local new delegate with 
something it has, and when it goes out of scope, it would reset it to 
whatever it was before.   This would create some runtime overhead -- 
but I'm not sure how much more than already exists.


-Shammah

Re: RFC: moving forward with @nogc Phobos

[Shammah Chancellor via Digitalmars-d]

On 2014-09-29 22:15:33 +, Andrei Alexandrescu said:


On 9/29/14, 11:44 AM, Shammah Chancellor wrote:

I don't like the idea of having to pass in template parameters
everywhere -- even for allocators.


I agree.


Is there some way we could have
allocator contexts?

E.G.

with( auto allocator = ReferencedCounted() )


Don't confuse memory allocation with memory management. There's no such 
a thing as a reference counted allocator.


Andrei


Sure, but combining the two could be very useful -- as we have noticed 
with a allocators that work off of a garbage collector.  With regards 
to reference counting, you could implement one that automatically wraps 
the type in an RC struct and proxies them.   Being able to redefined 
aliases during different sections of compilation would be required 
though.

Re: Crazy code by Adam on SO

[Shammah Chancellor via Digitalmars-d]

On 2014-08-29 16:48:51 +, Andrei Alexandrescu said:


Worth a look:

http://stackoverflow.com/questions/2329/d-finding-all-functions-with-certain-attribute 



Andrei


That's some pretty neat code, I did something similar awhile ago for 
deserializing classes.  Here's a reduced case of it:


http://dpaste.dzfl.pl/4fffa339368f

The facility to be able to create such a factory through compile time 
reflection is absolutely awesome.  However, it feels as though the 
ability to do this is making use of undefined behavior rather than 
actual language features.


First:

I consider it sort of a language wart that alias hack(alias T) = T; is 
necessary for aliasing to the particular symbol, and that the 
__traits(getMember) expression can't be substituted in to the same 
places as the alias to it without compiler errors.   It's very 
non-intuitive.  I would have never figured that out on my own with out 
some other D wizards helping me about a year ago.  I still don't 
understand why I can't simply do :

alias member = __traits(getMember, ...);

Also:

The way that the foreach works in the pasted example is very 
surprising.   I would be nice if this was a static foreach instead of 
just a foreach which happens to run at compile time over a TypeTuple.   
Normally doing a switch inside a foreach like that would not work at 
all, but near as I can tell the compiler unrolls the whole thing since 
it's inputs are known at compile time.


Finally:

If you actually want to have something that returns a TypeTuple!() of 
only subclasses which you can foreach over in other places -- you have 
to make a *very* ugly recursive template:


	(Line 208 thru Line 235 returns a TypeTuple of all subclasses of the 
Message class)



https://github.com/schancel/gameserver/blob/master/source/messages/core.d#L208

Making these awesome feature more intuitive and easy to use would go a 
long way.  I feel like this should be on your short list along with the 
GC and C++ compatibility.


-S.

Re: Library Typedefs are fundamentally broken

[Shammah Chancellor via Digitalmars-d]

What exactly was wrong with the original typedef statement that was deprecated?

Re: Crazy code by Adam on SO

[Shammah Chancellor via Digitalmars-d]

On 2014-09-03 01:41:57 +, Rikki Cattermole said:


On Tuesday, 2 September 2014 at 22:30:59 UTC, Shammah Chancellor wrote:

On 2014-08-29 16:48:51 +, Andrei Alexandrescu said:


Worth a look:

http://stackoverflow.com/questions/2329/d-finding-all-functions-with-certain-attribute 




Andrei


Is this bug fixed then?

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


I have a PR open for this bug [0].
But I have had no feedback regarding it nor confirmation that it fixes 
the bug for others.

No idea if anybody else has done something for it as well.

[0] https://github.com/D-Programming-Language/dmd/pull/3921



Looks like you made this pretty recently.  Thanks!   That bug was quite 
a thorn in my side for awhile.


-Shammah

Re: Crazy code by Adam on SO

[Shammah Chancellor via Digitalmars-d]

On 2014-08-29 16:48:51 +, Andrei Alexandrescu said:


Worth a look:

http://stackoverflow.com/questions/2329/d-finding-all-functions-with-certain-attribute 



Andrei


Is this bug fixed then?

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

Re: SDC-32bit

[Shammah Chancellor via Digitalmars-d-announce]

On 2014-08-04 04:19:01 +, deadalnix said:


On Saturday, 2 August 2014 at 22:48:35 UTC, Shammah Chancellor wrote:
Also, it looks by using your fiber based scheduler that you can 
naturally parallize compiling.  Have you investigated that at all?


Obviously, yes. But that is quite tricky to get a deterministic result 
due to compile time features.


I'm not sure what you mean.   Are you referring to things like pragma msg?