Re: Error compiling with DUB (dmd) since yesterday dub update

[Mario via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 07:11:09 UTC, rikki cattermole wrote:

On 11/03/2018 8:02 PM, Mario wrote:
On Sunday, 11 March 2018 at 06:59:32 UTC, rikki cattermole 
wrote:

On 11/03/2018 7:55 PM, Mario wrote:

[...]


Are you aware that it is compiling with ldc?


Actually, I didn't even realize XD. I'm a newbie in VibeD and 
DLang, should I change it? Why did compiling work yesterday?


Thanks in advance


Workaround switch to dmd.
Real solution please file a bug for Botan and attach your log 
in.


Thank you, I followed your advice and I created an issue on the 
GitHub project: https://github.com/etcimon/botan/issues/42

Re: Error compiling with DUB (dmd) since yesterday dub update

[rikki cattermole via Digitalmars-d-learn]

On 11/03/2018 8:02 PM, Mario wrote:

On Sunday, 11 March 2018 at 06:59:32 UTC, rikki cattermole wrote:

On 11/03/2018 7:55 PM, Mario wrote:
I upgraded yesterday to "DUB version 1.8.0, built on Mar  3 2018" 
using "4.15.6-1-ARCH".


I got an error while compiling a project which uses the following 
dependencies:



dependency "vibe-d" version="~>0.8.3-beta.1"
dependency "vibe-d:tls" version="~>0.8.3-beta.1"
versions "VibeDefaultMain"
subConfiguration "vibe-d:tls" "botan"
The log I got is the following one: 
https://hastebin.com/wubujowezi.coffeescript


Do someone know what is happening and why suddenly it stopped 
working? Regrets.


Are you aware that it is compiling with ldc?


Actually, I didn't even realize XD. I'm a newbie in VibeD and DLang, 
should I change it? Why did compiling work yesterday?


Thanks in advance


Workaround switch to dmd.
Real solution please file a bug for Botan and attach your log in.

[Issue 17892] Scope analysis with -dip1000 fails for templated structs

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17892] Scope analysis with -dip1000 fails for templated structs

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

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

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

https://github.com/dlang/dmd/commit/1ec125e6bc5f7aec460d5d7deb2699d92f473c5c
fix Issue 17892 - Scope analysis with -dip1000 fails for templated structs

https://github.com/dlang/dmd/commit/37688254c7663c017b5f2b9be2bfcbca3070fbfa
Merge pull request #7993 from WalterBright/fix17892

fix Issue 17892 - Scope analysis with -dip1000 fails for templated st…
merged-on-behalf-of: Walter Bright 

--

Re: Error compiling with DUB (dmd) since yesterday dub update

[Mario via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 06:59:32 UTC, rikki cattermole wrote:

On 11/03/2018 7:55 PM, Mario wrote:
I upgraded yesterday to "DUB version 1.8.0, built on Mar  3 
2018" using "4.15.6-1-ARCH".


I got an error while compiling a project which uses the 
following dependencies:



dependency "vibe-d" version="~>0.8.3-beta.1"
dependency "vibe-d:tls" version="~>0.8.3-beta.1"
versions "VibeDefaultMain"
subConfiguration "vibe-d:tls" "botan"
The log I got is the following one: 
https://hastebin.com/wubujowezi.coffeescript


Do someone know what is happening and why suddenly it stopped 
working? Regrets.


Are you aware that it is compiling with ldc?


Actually, I didn't even realize XD. I'm a newbie in VibeD and 
DLang, should I change it? Why did compiling work yesterday?


Thanks in advance

Re: Tools to help me find memory leaks?

[Denis Feklushkin via Digitalmars-d-learn]

On Wednesday, 23 August 2017 at 20:52:17 UTC, Stefan Koch wrote:

On Wednesday, 23 August 2017 at 17:30:40 UTC, Drake44 wrote:
I'm on a Windows 7 machine and I'm using VisualD as my IDE. 
I'm trying to work out what's chewing up all the RAM in a 
program I'm writing... is there a tool that I can use that'll 
show me what in my program keeps allocating memory?


Thanks


If you are using the gc then compile with -profile=gc.
Which will generate a file that logs all gc allocations.


This will not displays number of deallocations. And problem is 
usually with the fact that something is allocated but not 
deallocated by GC for some reason.



On exiting the program normally.
So make sure you can exit via a keypress or after a timelimit 
has passed.


If you are using malloc / calloc / free
you'll have to use a tool like valgrind.

Error compiling with DUB (dmd) since yesterday dub update

[Mario via Digitalmars-d-learn]

I upgraded yesterday to "DUB version 1.8.0, built on Mar  3 2018" 
using "4.15.6-1-ARCH".


I got an error while compiling a project which uses the following 
dependencies:



dependency "vibe-d" version="~>0.8.3-beta.1"
dependency "vibe-d:tls" version="~>0.8.3-beta.1"
versions "VibeDefaultMain"
subConfiguration "vibe-d:tls" "botan"
The log I got is the following one: 
https://hastebin.com/wubujowezi.coffeescript


Do someone know what is happening and why suddenly it stopped 
working? Regrets.

Re: Error compiling with DUB (dmd) since yesterday dub update

[rikki cattermole via Digitalmars-d-learn]

On 11/03/2018 7:55 PM, Mario wrote:
I upgraded yesterday to "DUB version 1.8.0, built on Mar  3 2018" using 
"4.15.6-1-ARCH".


I got an error while compiling a project which uses the following 
dependencies:



dependency "vibe-d" version="~>0.8.3-beta.1"
dependency "vibe-d:tls" version="~>0.8.3-beta.1"
versions "VibeDefaultMain"
subConfiguration "vibe-d:tls" "botan"
The log I got is the following one: 
https://hastebin.com/wubujowezi.coffeescript


Do someone know what is happening and why suddenly it stopped working? 
Regrets.


Are you aware that it is compiling with ldc?

Re: Do forum posts use any markup language?

[Tony via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 18:02:48 UTC, Bogdan wrote:
I'd like to distinguish between regular text and code, maybe 
have quotes, etc.


A poster has come up with a standard way to delineate code and 
also show if multiple files are involved (along with an 
"extraction to files" program):


https://forum.dlang.org/thread/ndgdqraxjkuvfsjhe...@forum.dlang.org

This method now works at https://run.dlang.io

Re: Granular GC

[Dmitry Olshansky via Digitalmars-d]

On Saturday, 10 March 2018 at 19:53:22 UTC, Amorphorious wrote:
The GC sucks because it requires one to use it or jump through 
many hoops and unsafe techniques to get away from it.


I don’t see where it requires that.



It would be better if we simply had more control over the GC.

1. Allow for granular GC - Multiple independent GC's that 
handle independent parts of the D ecosystem each of which can 
be overridden in code if desired.


One GC for the main user program(allocations, etc), One for D 
internals such as slices, One for exception handling, One for 
lambda's/delegates, etc.


They all will have to know about each other.
This is a false separation, much like separating all odd and even 
integers to let CPU run faster.


Much more interesting one is thread-local GC, which theoretically 
would be attainable if cast to-from shared was a runtime hook.




The idea is that by having better resolution each GC can be 
tailored for it's specific purpose. For example, having a GC 
that handles the exception handling can be tailored so that it 
uses smaller memory and does not need to escape the memory 
reason to scan for false pointers, etc.


Having special _allocator_ for exceptions might help, on the 
other hand recent DIP makes it refcpunted unless escaped.


Scaning still required though, exception usually contains 
message, a pointer.


It can also does not need to be run very often and should be 
relatively fast... in fact, if no exceptions are on the stack 
then it should exist immediately.



No comment.



Similarly, lambda and delegates would have a relatively simple 
and fast GC since no false pointers need to be scanned, etc. In 
fact, some simple escape analysis should allow local 
allocations to bypass the GC.


???
Delegates by definition need to be scanned, same with lambdas. 
Also to know if something is lambda on a stack takes about the 
same time as scaning the whole stack.

Aaand once that lambda is in heap, it’s just the same old GC.


The goal here is to still allow most of the D dependent GC 
functionality to persist but not have to throw the baby out 
with the bath water. E.g., keep the GC for exceptions(if it 
still uses it), lambda's/delegates, but allow one to use manual 
memory management for slices, or any combination one ones.  The 
main problem with the GC is stop the world and it's scanning 
for false pointers.


Reuniting a bunch of different GCs working as one is a nightmare, 
also the moment something is manual the rest still needs to know 
about that memory.


Stop the world usually solved by having mostly concurrent 
collector.


But we really don't have to have an all or nothing attitude 
which is what is forced on us by a poor design.


We don’t have that really except for exceptions and delegates.

GC can be better designed even in current constraints.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 05:41:02 UTC, Dylan Graham wrote:


I regret some of things I said. I'm sorry for any offence 
caused, specifically towards members of the DLF.




I don't think you need to regret saying anything. You've 
demonstrated a willingness to engage in a conversation that we 
can *all* learn from.


I also doubt anyone actually got offended ;-)

.. we're all pretty strong minded here.

But I get back to my point about "programmer" portability.

Other developers of newer languages just don't seem to get that.

And it's hardly surprising that D would be focused in some way, 
on languages used by the vast majority of programmers 
(C/C++/Java/C#... and dare I say it..python)


That is D's great strength. (and betterc is just a part of it - 
and not one that particulary interests me).


Because D resources are rather contstrained, betterc gets more 
push back than it really should. But the main take away point I 
get from that vision statement, is a greater focus on increasing 
contributions - which is really what D needs more than anything 
(apart from a correct and complete language specification).

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/10/2018 05:47 AM, Dylan Graham wrote:

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


First of all, betterC is about far more than interfacing with 
C. In fact, interop with C isn't really what betterC is about 
at all - that's a separate aspect of the language. (And those 
C/C++ users who still haven't come to D - for many of them the 
holdout is *because* of the issues betterC aims to address. 
Make no mistake, for all the stockholm syndrome in the C and 
C++ worlds, there *are* a lot people openly wanting to jump 
ship but don't have a sufficient option yet. Heck, *I'm* a 
C/C++ -> D convert.)


But more importantly:

The D language itself is specifically designed and intended to 
be multi-purpose. Because of that, D users (and potential D 
users) are *highly* diverse. Everybody here has their own 
use-cases, their own needs and priorities, and their own list 
of things they want fixed yesterday.


In a group this diverse, there just simply *isn't* much on the 
D wishlist that's crucially important to a *majority*, because 
we all need completely different things.


Personally, better DLL support have little to no impact on me. 
Obviously it does for you, and I sympathise. Some of the things 
most important to me for D to improve you probably wouldn't 
care one bit about - and that's ok. We work on different sorts 
of things.


Improved betterC is something I would find very nice if I ever 
have time or opportunity to get back into embedded software. 
But outside of that, yea, it doesn't impact me much more than 
it does for you.


But here's the rub: In this crowd here, probably far more than 
most languages, we all have such wildly varying needs that 29% 
*is* what qualifies as significant around here. Most wishlist 
items are going to have similarly non-majority numbers. And 
they have to pick *something* to focus on. Luckily, as the 
vision document clearly states, there are *several* such 
"somethings" the dlang foundation is committing to working on.


You do have a good point. One of my likes for D was its 
flexibility, so it was very hypocritical of me to argue for what 
I did.


I regret some of things I said. I'm sorry for any offence caused, 
specifically towards members of the DLF.


I wish that DLL support was referenced in the vision document. I 
actually like most of what's been said in it, especially the 
@safe, @nogc and editor support. I also see Benjamin Thaut (if 
you're reading this - awesome work!) making progress on DLL 
support, I just wish the foundation could help him out a bit.

[Issue 18576] Compiler not doing RVO with auto returns

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

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

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

https://github.com/dlang/dmd/commit/94f0bd6af7120ff27968052ad5645a554db12bed
fix Issue 18576 - Compiler not doing RVO with auto returns

https://github.com/dlang/dmd/commit/8b51a1d3d6f2c96214da0b3e49a62c1b021a70b0
Merge pull request #7990 from WalterBright/fix18576

fix Issue 18576 - Compiler not doing RVO with auto returns
merged-on-behalf-of: Walter Bright 

--

[Issue 18576] Compiler not doing RVO with auto returns

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17363] @safety hole due to $ caching in slice expressions

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Walter Bright  ---
I don't think there is a solution to this problem. Consider:

a()[b($)..c($)]

where a, b, c are functions with side effects that change the length of the
array, and the calls to b and c depend on the $, the length of the array. Each
function can only be called once, because they have side effects.

In order to get $, a() has to be called. But b($) and c($) both change the
value of $, so no ordering is correct.

However, it is not memory unsafe, because reallocating the array is memory safe
even if other references to that array remain.

I'm marking this as INVALID because 1) there is no solution, cache or no cache,
and 2) it is not memory unsafe. It's just buggy code.

--

Re: Vision document for H1 2018

[Timothee Cour via Digitalmars-d-announce]

IMO this should be the priority:

1. blockers (things that can't be worked around at all or not without
jumping through a lot of hoops)
2. everything else

dmd still doesn't support shared libraries on OSX (cf
https://issues.dlang.org/show_bug.cgi?id=12190)

That prevents a whole category of use cases (eg D plugins called from
C++ or from D)





On Sat, Mar 10, 2018 at 8:06 PM, Nick Sabalausky (Abscissa) via
Digitalmars-d-announce  wrote:
> On 03/10/2018 05:47 AM, Dylan Graham wrote:
>>
>> On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:
>>>
>>>
>>> According to the State of D Survey, 71% of the respondents don't care
>>> about betterC. Why is betterC on the priority list?
>>
>>
>> Yeah. Why should D worry about tying itself into C when it can't even
>> interface with itself through DLLs?
>
>
> First of all, betterC is about far more than interfacing with C. In fact,
> interop with C isn't really what betterC is about at all - that's a separate
> aspect of the language. (And those C/C++ users who still haven't come to D -
> for many of them the holdout is *because* of the issues betterC aims to
> address. Make no mistake, for all the stockholm syndrome in the C and C++
> worlds, there *are* a lot people openly wanting to jump ship but don't have
> a sufficient option yet. Heck, *I'm* a C/C++ -> D convert.)
>
> But more importantly:
>
> The D language itself is specifically designed and intended to be
> multi-purpose. Because of that, D users (and potential D users) are *highly*
> diverse. Everybody here has their own use-cases, their own needs and
> priorities, and their own list of things they want fixed yesterday.
>
> In a group this diverse, there just simply *isn't* much on the D wishlist
> that's crucially important to a *majority*, because we all need completely
> different things.
>
> Personally, better DLL support have little to no impact on me. Obviously it
> does for you, and I sympathise. Some of the things most important to me for
> D to improve you probably wouldn't care one bit about - and that's ok. We
> work on different sorts of things.
>
> Improved betterC is something I would find very nice if I ever have time or
> opportunity to get back into embedded software. But outside of that, yea, it
> doesn't impact me much more than it does for you.
>
> But here's the rub: In this crowd here, probably far more than most
> languages, we all have such wildly varying needs that 29% *is* what
> qualifies as significant around here. Most wishlist items are going to have
> similarly non-majority numbers. And they have to pick *something* to focus
> on. Luckily, as the vision document clearly states, there are *several* such
> "somethings" the dlang foundation is committing to working on.

Re: Vision document for H1 2018

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 03/10/2018 05:47 AM, Dylan Graham wrote:

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents don't care 
about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it can't even 
interface with itself through DLLs?


First of all, betterC is about far more than interfacing with C. In 
fact, interop with C isn't really what betterC is about at all - that's 
a separate aspect of the language. (And those C/C++ users who still 
haven't come to D - for many of them the holdout is *because* of the 
issues betterC aims to address. Make no mistake, for all the stockholm 
syndrome in the C and C++ worlds, there *are* a lot people openly 
wanting to jump ship but don't have a sufficient option yet. Heck, *I'm* 
a C/C++ -> D convert.)


But more importantly:

The D language itself is specifically designed and intended to be 
multi-purpose. Because of that, D users (and potential D users) are 
*highly* diverse. Everybody here has their own use-cases, their own 
needs and priorities, and their own list of things they want fixed 
yesterday.


In a group this diverse, there just simply *isn't* much on the D 
wishlist that's crucially important to a *majority*, because we all need 
completely different things.


Personally, better DLL support have little to no impact on me. Obviously 
it does for you, and I sympathise. Some of the things most important to 
me for D to improve you probably wouldn't care one bit about - and 
that's ok. We work on different sorts of things.


Improved betterC is something I would find very nice if I ever have time 
or opportunity to get back into embedded software. But outside of that, 
yea, it doesn't impact me much more than it does for you.


But here's the rub: In this crowd here, probably far more than most 
languages, we all have such wildly varying needs that 29% *is* what 
qualifies as significant around here. Most wishlist items are going to 
have similarly non-majority numbers. And they have to pick *something* 
to focus on. Luckily, as the vision document clearly states, there are 
*several* such "somethings" the dlang foundation is committing to 
working on.

Re: List installed modules

[psychoticRabbit via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 03:52:19 UTC, psychoticRabbit wrote:


Whether dub does that currently I do not know, as i don't use 
dub, or any additional packages outside of phobos.


oh > dub list   ;-)

Re: List installed modules

[psychoticRabbit via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 01:04:27 UTC, Roberto wrote:

How do I list installed modules?



or..

https://dlang.org/phobos/index.html

Re: List installed modules

[psychoticRabbit via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 01:04:27 UTC, Roberto wrote:

How do I list installed modules?

dmd --list-modules
datefmt
dateparser
std.algorithm
std.array
std.conv
std.datetime
std.digest
std.exception
std.file
std.format
std.getopt
std.json
std.math
...


Presumably, you mean packages installed by dub, as opposed to 
what comes with phobos as part of the installation.


If that's what you mean, then that could be an enhancment request 
- i.e. to have dub maintain a list of what's installed, like any 
good package manager should.


Whether dub does that currently I do not know, as i don't use 
dub, or any additional packages outside of phobos.

Re: C++ launched its community survey, too

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:
It would be nice if you could actually just copy-n-paste a C 
header into an extern(C) block in D and have it Just Work(tm), 
but practically all C headers are dependent on macros one way 
or another that it would require including an entire C 
processor inside the D compiler, which is not exactly an 
inviting proposition.


Watch this space...

Re: List installed modules

[Roberto via Digitalmars-d-learn]

On Sunday, 11 March 2018 at 01:55:07 UTC, Jonathan M Davis wrote:
On Sunday, March 11, 2018 01:04:27 Roberto via 
Digitalmars-d-learn wrote:

[...]


The compiler has no concept of installed modules any more than 
C/C++ has a concept of installed header files. It has paths 
that it looks in for modules when it's told to import them, but 
it doesn't know or care about any modules until they're 
explicitly imported. If you want to see the default import 
path, then look at dmd.conf and what it passes to the -I flag. 
Otherwise, it's a question of where dmd is run from and what 
additional -I flags the build process passes to dmd.


- Jonathan M Davis


Thanks. I'll write an script.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 02:02:15 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote:


i.e. How can the D Foundation encourage new additional 
resoures to focus on things that also matter to the community.





and btw. the mention about strengthing the use of DIPS, does 
just that.


there are many improvement to 'process' that can be done to 
encourage more people to contribute to D.


This is not about betterc at all, really.


Then it does seem like things will improve. I hope there will be 
more surveys in the future and I'm very happy with the new DIP 
process.


My original argument was that BetterC is a mismanagement of 
resources, and I still stand by that.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote:


i.e. How can the D Foundation encourage new additional resoures 
to focus on things that also matter to the community.





and btw. the mention about strengthing the use of DIPS, does just 
that.


there are many improvement to 'process' that can be done to 
encourage more people to contribute to D.


This is not about betterc at all, really.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:53:30 UTC, Dylan Graham wrote:


That sentence was to counter psychoticRabbit. I didn't mean it 
literally. If you've read my earlier posts, it's not BetterC I 
have an issue with, it's the allocation of time.




Well that should have been the basis of your original argument.

i.e. How can the D Foundation encourage new additional resoures 
to focus on things that also matter to the community.


Instead, you started by attacking the D Foundation for allocating 
resources to betterc.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:50:22 UTC, Mike Parker wrote:

On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:



The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.


Please read my post from earlier:

https://forum.dlang.org/post/chsqspkoxbcdqjcqb...@forum.dlang.org

The survey *will* have an influence on what gets priority in 
the future, but it certainly can't be seen as representing the 
majority of D programming interests.




Good. That's definitely for the better.



It is not a dictatorship (read this sentence over and over 
till you get it).


No one is forcing you to use BetterC and its existence doesn't 
change anything about how you can use the language. Obviously, 
there are a number of areas that need work. The survey can help 
decide which of those to put resources into first, but it 
doesn't mean that other things deemed important have to be 
dropped.


That sentence was to counter psychoticRabbit. I didn't mean it 
literally. If you've read my earlier posts, it's not BetterC I 
have an issue with, it's the allocation of time.


As you said, hopefully the survey will help clear up these issues 
with D.

Re: Vision document for H1 2018

[Mike Parker via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:



The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.


Please read my post from earlier:

https://forum.dlang.org/post/chsqspkoxbcdqjcqb...@forum.dlang.org

The survey *will* have an influence on what gets priority in the 
future, but it certainly can't be seen as representing the 
majority of D programming interests.





It is not a dictatorship (read this sentence over and over till 
you get it).


No one is forcing you to use BetterC and its existence doesn't 
change anything about how you can use the language. Obviously, 
there are a number of areas that need work. The survey can help 
decide which of those to put resources into first, but it doesn't 
mean that other things deemed important have to be dropped.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:46:09 UTC, Dylan Graham wrote:


Rust was more popular and who could use that?
Rust is popular because of its ideas, not because it pandered.



I don't see "programmer" portability as being pandering.

It common sense.

Rust is good, in that it seeks to do something different. I like 
that.


But I live in the real world, and need to switch between 
languages often.


Language theory is nice and all that, but "programmer" 
portability is paramount for me.. not popular ideas.


And Rust is popular... with Rust programmers.

Re: List installed modules

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, March 11, 2018 01:04:27 Roberto via Digitalmars-d-learn wrote:
> How do I list installed modules?
>
> dmd --list-modules
> datefmt
> dateparser
> std.algorithm
> std.array
> std.conv
> std.datetime
> std.digest
> std.exception
> std.file
> std.format
> std.getopt
> std.json
> std.math
> ...

The compiler has no concept of installed modules any more than C/C++ has a
concept of installed header files. It has paths that it looks in for modules
when it's told to import them, but it doesn't know or care about any modules
until they're explicitly imported. If you want to see the default import
path, then look at dmd.conf and what it passes to the -I flag. Otherwise,
it's a question of where dmd is run from and what additional -I flags the
build process passes to dmd.

- Jonathan M Davis

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:41:33 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote:


I'm not sure what you mean at that last sentence.


I mean, cause D is so compatible with C/C++/Java/C# - that you 
can easily switch between them.


Whereas as Go and Rust have their own thing going, making those 
languages really difficult in terms of "programmer" portability.


C++ became popular cause C programmers could easily use it.
Java became popular cause C/C++ programmers could easily use it.
C# became popular cause C/C++/Java programmers could easily use 
it.


D is gradually becoming popular cause C/C++/Java/C# programmers 
can easily use it.


Rust was more popular and who could use that?
Rust is popular because of its ideas, not because it pandered.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:


The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.



And also the minority. A lesson that humanity has to learn over 
and over again.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:45:01 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:


The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.



And also the minority. A lesson that humanity has to learn over 
and over again.


Despite the fact that D struggles to interface with itself yet 
the priorities of the foundation are to make D easily interface 
with C? I don't care if they listen to the minority, but make 
sure your priorities are in line before doing so. I think BetterC 
will be something useful in the future, not now.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote:


I'm not sure what you mean at that last sentence.


I mean, cause D is so compatible with C/C++/Java/C# - that you 
can easily switch between them.


Whereas as Go and Rust have their own thing going, making those 
languages really difficult in terms of "programmer" portability.


C++ became popular cause C programmers could easily use it.
Java became popular cause C/C++ programmers could easily use it.
C# became popular cause C/C++/Java programmers could easily use 
it.


D is gradually becoming popular cause C/C++/Java/C# programmers 
can easily use it.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:21:27 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:


Point to the wall on the left side. That is what your talking 
to. D its focus on C++ as a bad plan has been made pushed by 
many people ( lots who left ). Its like asking Go for Generics.


And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again 
by asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And 
yet, its a priority when 71% say its not!


D simply is not equipped for dealing with people who come from 
languages like C#, Ruby, PHP, Python, ... because too many 
people here are C++ old timers ( yes, there are exceptions ) 
and they only think in that direction.

There is a lesson the be learned in this somewhere...



Again, D is not run by some corporation.

Nor is it a democracy - where majority rule. (read this 
sentence over and over till you get it)


The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.


It is not a dictatorship (read this sentence over and over till 
you get it).

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:
 And "scripting" language like PHP, that everybody 
criticizes just keeps growing and gained 11% market share in 
the last 7 years ( at now 83% ). Where as D its gain has been 
minimalist thanks to people leaving almost as fast as it gain.




Well, according to the TIOBE Index, C was the language of 2017.

Java is almost always on top, followed by C, followed closely by 
C++.


And it's not just 'old timers' using those languages... surely.

And scripting language can pretty much replace any other 
scripting language.


It's the 'real' programming languages that matter ;-)

And D's not doing to badly at all...despite betterc

https://www.tiobe.com/tiobe-index/d/

(although I wonder what happended back in 2009 ??)

[Issue 18559] std.math.* should stop using `real` overloads by default

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

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

Nicholas Wilson  changed:

   What|Removed |Added

 CC||iamthewilsona...@hotmail.co
   ||m

--- Comment #2 from Nicholas Wilson  ---
Please review:

https://github.com/dlang/phobos/pull/6257
https://github.com/dlang/dmd/pull/7995
https://github.com/dlang/druntime/pull/2135

--

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote:

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:


Every day D becomes more like C++ 2.0, why can't it just be D?


Oddly enough, I think this is D's strength.


I really don't.

Golang tried to draw the line, and look where that got it. Now 
it's a limited language for a specific domain  (at least until 
Go 3.0).


Rust decided (and Go to some extent), to introduce foreign 
syntax that was vastly different to what the majority of 
programmers are familiar with, and, it makes it difficult to 
transistion to because its syntax is so unlike the syntax most 
people will continue to have to work with.


D's strength, is that most C/C++/Java/C# programmers can just 
jump right in and use it. And, they can continue to go back and 
forth without syntax related psychosis developing.


betterc is just another way of supporting that crowd..and it's 
a very big crowd.


Yeah, 29% of the crowd.

Your problem is not betterc, but something else. So focus on 
that instead.


You're right, my problem isn't BetterC, it's the fact that 
Foundation can't get its priorities right. BetterC is a symptom.


And personally, depending on the problem, C# is better to 
program in than D. I still don't know why C# programmers are 
willing to give up C# and prefer to use D.

C# is vastly surperior for what it does.


I'm my current use-case, D is 'vastly superior'. I wouldn't have 
switched to D if there was no reason to.



D is also particulary useful for some problems.

Better to use both, not one or the other.

Thanks to not being Go or Rust, you can do that - cause 
concepts, syntax  etc, are really compatible with both.


I'm not sure what you mean at that last sentence.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:


Point to the wall on the left side. That is what your talking 
to. D its focus on C++ as a bad plan has been made pushed by 
many people ( lots who left ). Its like asking Go for Generics.


And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again 
by asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And 
yet, its a priority when 71% say its not!


D simply is not equipped for dealing with people who come from 
languages like C#, Ruby, PHP, Python, ... because too many 
people here are C++ old timers ( yes, there are exceptions ) 
and they only think in that direction.

There is a lesson the be learned in this somewhere...



Again, D is not run by some corporation.

Nor is it a democracy - where majority rule. (read this sentence 
over and over till you get it)


It's a language that develops because people are sufficiently 
motivated to put in the time to develop what interests them.


Have your say and leave it at that. Stop attacking the work 
others are doing.


And stop your discriminatory use of the phrase 'old timers'.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:
Well, no. I'm more concerned with the fact that the D Language 
Foundation is focused on BetterC, yet does not mention DLLs at 
all.


For God's sake, if D is the future, why does it continue to 
leech off C/C++? Other languages like Rust and C# only have 
basic function calling C (FFI/PInvoke) yet are way more 
popular. I get the feeling that most of the C++ programmers 
who would come to D have already done so.


The most I'll ever need of interfacing with C and C++ is to be 
able to call their functions from D. I've no reason for 
BetterC.


And what's with the language design, anyway? D has been 
designed with features that C++ programmers don't want, then 
now the D Language Foundation is wasting effort to change the 
language to rope those programmers in? If D was meant to be 
C++ 2.0, shouldn't it have been designed that way from the 
start?


I came to D from a C# background. I was looking a language 
that had a GC, was awesome to program in and was very fast. 
Why can't D own up to these facts, rather than becoming a 
leech of C++?


Every day D becomes more like C++ 2.0, why can't it just be D?


Point to the wall on the left side. That is what your talking 
to. D its focus on C++ as a bad plan has been made pushed by 
many people ( lots who left ). Its like asking Go for Generics.


Yeah. It quite seems like that. Maybe after BetterC will the 
foundation get its priorities right.


And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again 
by asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And 
yet, its a priority when 71% say its not!


Didn't BetterC start before the poll was issued? I hope that more 
polls like this are created in the future so that the leadership 
knows where it's priorities are based upon community demands.


D simply is not equipped for dealing with people who come from 
languages like C#, Ruby, PHP, Python, ... because too many 
people here are C++ old timers ( yes, there are exceptions ) 
and they only think in that direction.


Kind of ironic when D keeps pushing for more features hoping 
that it will attract C++ developers and the young kid on the 
block Rust is already eating up that market. And "scripting" 
language like PHP, that everybody criticizes just keeps growing 
and gained 11% market share in the last 7 years ( at now 83% ). 
Where as D its gain has been minimalist thanks to people 
leaving almost as fast as it gain.


There is a lesson the be learned in this somewhere...


I wholeheartedly agree, but I believe this direction is because 
that the "C++ old timers" are in the leadership. I don't think 
there are "too many" in the community.


I also wish to point out that I'm not attacking Walter or Alex; I 
love the language they've created, but I'm fairly annoyed with 
their allocation of resources. They need to stick by the language 
they've created.

Re: Forwarding arguments through a std.algorithm.map

[crimaniak via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 20:48:06 UTC, Nordlöw wrote:

If I have a function

bool f(Rs...)(Rs rs)

is it somehow possible to map and forward all its arguments 
`rs` to another function


bool g(Rs...)(Rs rs);


docs:
 https://dlang.org/phobos/std_traits.html#.Parameters
usage example:
 
https://github.com/crimaniak/d-vision/blob/master/src/vision/eventbus.d#L173

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:


Every day D becomes more like C++ 2.0, why can't it just be D?


Oddly enough, I think this is D's strength.

Golang tried to draw the line, and look where that got it. Now 
it's a limited language for a specific domain  (at least until Go 
3.0).


Rust decided (and Go to some extent), to introduce foreign syntax 
that was vastly different to what the majority of programmers are 
familiar with, and, it makes it difficult to transistion to 
because its syntax is so unlike the syntax most people will 
continue to have to work with.


D's strength, is that most C/C++/Java/C# programmers can just 
jump right in and use it. And, they can continue to go back and 
forth without syntax related psychosis developing.


betterc is just another way of supporting that crowd..and it's a 
very big crowd.


Your problem is not betterc, but something else. So focus on that 
instead.


And personally, depending on the problem, C# is better to program 
in than D. I still don't know why C# programmers are willing to 
give up C# and prefer to use D.

C# is vastly surperior for what it does.

D is also particulary useful for some problems.

Better to use both, not one or the other.

Thanks to not being Go or Rust, you can do that - cause concepts, 
syntax  etc, are really compatible with both.

Re: Vision document for H1 2018

[R via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:
Well, no. I'm more concerned with the fact that the D Language 
Foundation is focused on BetterC, yet does not mention DLLs at 
all.


For God's sake, if D is the future, why does it continue to 
leech off C/C++? Other languages like Rust and C# only have 
basic function calling C (FFI/PInvoke) yet are way more 
popular. I get the feeling that most of the C++ programmers who 
would come to D have already done so.


The most I'll ever need of interfacing with C and C++ is to be 
able to call their functions from D. I've no reason for BetterC.


And what's with the language design, anyway? D has been 
designed with features that C++ programmers don't want, then 
now the D Language Foundation is wasting effort to change the 
language to rope those programmers in? If D was meant to be C++ 
2.0, shouldn't it have been designed that way from the start?


I came to D from a C# background. I was looking a language that 
had a GC, was awesome to program in and was very fast. Why 
can't D own up to these facts, rather than becoming a leech of 
C++?


Every day D becomes more like C++ 2.0, why can't it just be D?


Point to the wall on the left side. That is what your talking to. 
D its focus on C++ as a bad plan has been made pushed by many 
people ( lots who left ). Its like asking Go for Generics.


And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again by 
asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And yet, 
its a priority when 71% say its not!


D simply is not equipped for dealing with people who come from 
languages like C#, Ruby, PHP, Python, ... because too many people 
here are C++ old timers ( yes, there are exceptions ) and they 
only think in that direction.


Kind of ironic when D keeps pushing for more features hoping that 
it will attract C++ developers and the young kid on the block 
Rust is already eating up that market. And "scripting" language 
like PHP, that everybody criticizes just keeps growing and gained 
11% market share in the last 7 years ( at now 83% ). Where as D 
its gain has been minimalist thanks to people leaving almost as 
fast as it gain.


There is a lesson the be learned in this somewhere...

List installed modules

[Roberto via Digitalmars-d-learn]

How do I list installed modules?

dmd --list-modules
datefmt
dateparser
std.algorithm
std.array
std.conv
std.datetime
std.digest
std.exception
std.file
std.format
std.getopt
std.json
std.math
...

[Issue 17363] @safety hole due to $ caching in slice expressions

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #4 from Walter Bright  ---
The only safe solution is for s[a..b] is to evaluate a and b first, then s.
Then the slice will be array bounds checked safely if it got resized.

(Currently, s is evaluated first.)

--

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:
On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit 
wrote:

On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:

[Omitted]


I also would like to point out that I don't care if some 
open-source developers decide to create BetterC in their free 
time. More power to them. It doesn't concern me.


What does concern me is that BetterC is the focus of the *D 
Language Foundation*. Why isn't interfacing with D more important?


I'm becoming more and more skeptical of the future of D.

Re: Vision document for H1 2018

[Dylan Graham via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit wrote:

On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


A reasonable point.

But.. in any case.. people work on what they are motivated to 
work on.


That's really all there is to it.

That's how the open source community works.

Top down, corporate direction, simply does not apply here.

One day you (or some other D programmer) might need betterC - 
who knows - and it'll be there for you - cause someone else was 
motivated to do it.


Well, no. I'm more concerned with the fact that the D Language 
Foundation is focused on BetterC, yet does not mention DLLs at 
all.


For God's sake, if D is the future, why does it continue to leech 
off C/C++? Other languages like Rust and C# only have basic 
function calling C (FFI/PInvoke) yet are way more popular. I get 
the feeling that most of the C++ programmers who would come to D 
have already done so.


The most I'll ever need of interfacing with C and C++ is to be 
able to call their functions from D. I've no reason for BetterC.


And what's with the language design, anyway? D has been designed 
with features that C++ programmers don't want, then now the D 
Language Foundation is wasting effort to change the language to 
rope those programmers in? If D was meant to be C++ 2.0, 
shouldn't it have been designed that way from the start?


I came to D from a C# background. I was looking a language that 
had a GC, was awesome to program in and was very fast. Why can't 
D own up to these facts, rather than becoming a leech of C++?


Every day D becomes more like C++ 2.0, why can't it just be D?

[Issue 17318] Delegates allow escaping reference to stack variable

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #4 from Walter Bright  ---


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

--

[Issue 18576] Compiler not doing RVO with auto returns

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #2 from Walter Bright  ---
*** Issue 17318 has been marked as a duplicate of this issue. ***

--

[Issue 16528] @safe inference does not work for mutually recursive functions

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

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

--- Comment #3 from Walter Bright  ---
A minimal test case:

void fun1()()
{
fun2();
}

void fun2()()
{
fun1();
}

@safe void test()
{
fun1();
}

--

Re: DUB and Gtk-d reduce size of huge executable, build dynamic dependencies

[CSim via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 15:46:58 UTC, Gerald wrote:

On Wednesday, 7 March 2018 at 10:51:49 UTC, CSim wrote:

Hi,

I'm trying to decide whether it is better to use DLang for Gtk 
development or Vala/Genie.


When I make a simple Vala/Genie Gtk executable the file is 
tiny whereas the DLang file is huge.  First I used the default 
Dub build and the file was in excess of 60mb (assuming this 
includes debug build).  Using dub build=release the file is 
still more than 7 mb.  Using a native Vala/Genie build the 
file is less than 500k.


Trying to understand what is going on, but I assume from this 
that Dub is linking static dependencies, whereas the 
Vala/Genie builds will link to dynamic libraries.



So my (two pronged) question is this:  Is there any way to 
specify in dub.json to build and link dependencies as dynamic 
libraries, and are there any other tips that can be used to 
reduce these (relatively) huge executables?


Personally, I do not worry too much about the executable size, 
however a couple of tips as follows:


a. If this is on linux use "strip" to remove symbols out of the 
executable


b. In dub.json you can specify just the portions of GtkD that 
your application depends on, i.e.:


"dependencies": {
"gtk-d:gtkd": {
"version": "3.7.5"
},
"gtk-d:vte": {
"version": "3.7.5"
}
}

Is what I use in tilix (https://github.com/gnunn1/tilix)

c. You can dynamically link to GtkD, in tilix I have the config 
below to do so. Interestingly on ldc it doesn't make any 
difference in size though using ldd I can see the dependency to 
GtkD. With DMD it is smaller however I cannpt run it since the 
Arch Linux GtkD package is compiled with ldc2.


{
"name": "dynamic",
"targetType": "executable",
"libs": ["gtkd-3"],
"libs-linux": ["X11"],
"lflags": ["-defaultlib=libgtkd-3.so"],
"versions": ["StdLoggerDisableTrace"]
}


Thank you for this - I didn't have much luck with DUB/DMD but 
I'll give it another try.  The only thing I could get to work 
properly so far is LDC2 (1.8.0) and Make (4.2.1).  Meson (0.44.1) 
+ LDC2 did not work (using -XLinker by default - I had to hand 
edit the ninja.build file which kind of defeats the purpose of 
using Meson).


I managed to produce an executable less than 100k, whereas before 
it was between 6mb minimum.  Of course the shared LDC runtime and 
phobos libs were needed as well as the gtkd-3 lib - these are 
about 40mb cumulatively (about 23mb when debugs are removed).  
Here is a snippet from the Makefile containing the DLang settings 
(trying to combine DLang with other existing C and CPP libs too 
but this is not shown):


 Begin Makefile ==

# General settings
TARGET := app_d
LIB_DIR := ./lib
BUILD_DIR := ./build

# Assemble all source files.
SRC.d := -name *.d
SRC_DIRS := ./source
SRCS := $(shell find $(SRC_DIRS) $(SRC.d))

# Assemble all include directories
HDR_DIRS := ./source
INC_DIRS := $(shell find $(HDR_DIRS) -type d)
INC_FLAGS := $(addprefix -I,$(INC_DIRS))

# D source settings
DC := ldc2
DCFLAGS := $(INC_FLAGS) -I/usr/local/include/d/gtkd-3/ 
-enable-color -wi -g -O0
DLFLAGS := -link-defaultlib-shared 
-L-L/usr/local/lib/x86_64-linux-gnu/ -L-rpath=$(LIB_DIR) 
-L-lgtkd-3 -L-ldl

COMPILE.d = $(DC) $(DCFLAGS) -c $<
OUTPUT.d = -of $@
BUILD.d = $(DC) $(DCFLAGS) $^ $(DLFLAGS)

# Assemble all objects to be built.
ALL_OBJECTS := $(SRCS:%=$(BUILD_DIR)/%.o)

# Compile D source to object files.
$(BUILD_DIR)/%.d.o:%.d
$(COMPILE.d) $(OUTPUT.d)

# Make the target at the top level.
$(TARGET):$(ALL_OBJECTS)
$(BUILD.d) $(OUTPUT.d)

# Build everything.
all: $(TARGET)

== End Makefile =

And here is the file tree (I just copied the libs over from the 
default LDC2 install):


├── app_d
├── build
│   └── source
│   └── app.d.o
├── lib
│   ├── libdruntime-ldc-debug-shared.so -> 
libdruntime-ldc-debug-shared.so.78

│   ├── libdruntime-ldc-debug-shared.so.2.0.78
│   ├── libdruntime-ldc-debug-shared.so.78 -> 
libdruntime-ldc-debug-shared.so.2.0.78

│   ├── libdruntime-ldc-shared.so -> libdruntime-ldc-shared.so.78
│   ├── libdruntime-ldc-shared.so.2.0.78
│   ├── libdruntime-ldc-shared.so.78 -> 
libdruntime-ldc-shared.so.2.0.78

│   ├── libgtkd-3.so -> libgtkd-3.so.0
│   ├── libgtkd-3.so.0 -> libgtkd-3.so.0.8.0
│   ├── libgtkd-3.so.0.8.0
│   ├── libphobos2-ldc-debug-shared.so -> 
libphobos2-ldc-debug-shared.so.78

│   ├── libphobos2-ldc-debug-shared.so.2.0.78
│   ├── libphobos2-ldc-debug-shared.so.78 -> 
libphobos2-ldc-debug-shared.so.2.0.78

│   ├── libphobos2-ldc-shared.so -> libphobos2-ldc-shared.so.78
│   ├── libphobos2-ldc-shared.so.2.0.78
│   └── libphobos2-ldc-shared.so.78 -> 
libphobos2-ldc-shared.so.2.0.78

├── Makefile
└── source
└── app.d

Anyway, I wanted to see if I could produce something smaller than 
a 

Re: UFCS in generic libraries, silent hijacking, and compile errors.

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, March 10, 2018 21:50:42 aliak via Digitalmars-d-learn wrote:
> What are the recommended guidelines for using/not using UFCS in
> writing generic libraries?
>
> I ask because if you have an internal generic free function that
> you use on types in a generic algorithm via ufcs, then everything
> works fine until the type being operated on has a member function
> with a similar name.

The idea is that the type can provide its own version of the function that
is better optimized for it - e.g. it could potentially provide a member
function find that is more efficient for it than
std.algorithm.searching.find. That's actually the only technical reason why
UFCS is superior to the normal function call syntax. Everything else is a
matter of personal preference, though some folks prefer UFCS enough that
they use it everywhere. And as long as the code isn't generic, that's
usually not a problem, but using UFCS in generic code with a function that
isn't well-known can risk problems if it happens to match a member function.
The main reason that this isn't generally a problem is that most generic
code operates on either a fairly specific subset of types or on a specific
API where types implementing that API don't usually implement extra
functions (in particular, ranges normally only define the range API
functions, so it's rare that they have member functions that conflict with
anything). But if you're worried about it or want a specific function to be
called that definitely isn't a member function, then just don't use UFCS.
The situation that you're concerned about is not one that seems to be much
of an issue in practice. That doesn't mean that it's never a problem, but
from what I've seen, it's very rarely a problem, and it's easy to work
around if you run into a particular case where it is a problem.

The one case that I am aware of where best practice is to avoid UFCS is with
put for output ranges, but that has nothing to with your concerns here.
Rather, it has to do with the fact that std.range.primitives.put has a lot
of overloads for handling various arguments (particularly when handling
ranges of characters), and almost no one implements their output ranges with
all of those overloads. So, if you use put with UFCS, you tend to run into
problems if you do anything other than put a single element of the exact
type at a time, whereas the free function handles more cases (even if they
ultimately end up calling that member function with a single argument of the
exact type). We probably shouldn't have had the free function and the member
function share the same name.

> Is there something I'm not seeing as to why UFCS is not part of
> the overload set, and is there a way other than not using UFCS to
> prevent the silent hijacking?

If it were part of the overload set, then you have problems calling member
functions, particularly because there is no way to call a member function
other than with UFCS, whereas you can call free functions without UFCS, and
if you _really_ want to be sure that a very specific function is called,
then you can even give its entire module path when calling it. When UFCS was
introduced, it was decided that having member functions always win out would
cause the fewest problems.

- Jonathan M Davis

[Issue 16206] traits getOverloads fails when one of the overload is a templatized function

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

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

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #1 from Adam D. Ruppe  ---
ah yes i just hit this too and was about to submit. same thing on module level

void foo()() {}
void foo(int) {}

void main() {
foo(); // works
foo(0); // also works so they seem to be overloaded...

// yet this empty
pragma(msg, __traits(getOverloads, mixin(__MODULE__), "foo"));

// note: if you swap the order of the declarations above, it will
// actually show one foo in the message
}

--

Re: Embedded Linux really needs Dlang for the IOT market

[aberba via Digitalmars-d]

On Saturday, 10 March 2018 at 19:52:50 UTC, Cym13 wrote:

On Friday, 9 March 2018 at 11:35:58 UTC, aberba wrote:

On Friday, 9 March 2018 at 09:12:28 UTC, Radu wrote:

[...]


A tutorial or guide on "cross tool-chain for your system" will 
be very helpful. Say in ARM. Not that obvious to someone like 
me.


Looks like this gem went unnoticed for too long: 
https://fkromer.gitbooks.io/d-on-embedded-linux-arm/content/


Wow!

UFCS in generic libraries, silent hijacking, and compile errors.

[aliak via Digitalmars-d-learn]

What are the recommended guidelines for using/not using UFCS in 
writing generic libraries?


I ask because if you have an internal generic free function that 
you use on types in a generic algorithm via ufcs, then everything 
works fine until the type being operated on has a member function 
with a similar name.


If the signature matches the free function then the member 
function is called instead of the free function (silently) and if 
the signature does not match then you get a compiler error.


I.e.:

auto identity(T)(T t) { return t; }
auto fun(T)(T t) {
return t.identity;
}

void main() {
fun(3).writeln; // ok, print 3

struct S1 {}
fun(S1()).writeln; // ok, prints S1()

struct S2 { int identity() { return 77; } }
fun(S2()).writeln; // silent hijack, prints 77

struct S3 { int identity(int i) { return i + 2; } }
fun(S3()).writeln; // compile error
}

So the problem is that fun wants to use a utility function that 
it knows about, but it turns out that T can hijack that internal, 
private, utility if you use ufcs.


So basically, it seems like ufcs is fun until it doesn't work, 
and it's not really obvious that you can run in to these problems 
with ufcs.


I feel like the last case where it's a compilation error should 
maybe be ok though, since the function being called is actually 
undefined so ufcs should kick in. The problem as I understand it 
is that ufcs is not part of an overload set. Making it part of it 
would not prevent the silent hijack, but would remove the 
compilation problem.


Is there something I'm not seeing as to why UFCS is not part of 
the overload set, and is there a way other than not using UFCS to 
prevent the silent hijacking?


Cheers
- Ali

Re: Forwarding arguments through a std.algorithm.map

[ag0aep6g via Digitalmars-d-learn]

On 03/10/2018 09:48 PM, Nordlöw wrote:

If I have a function

     bool f(Rs...)(Rs rs)

is it somehow possible to map and forward all its arguments `rs` to 
another function


     bool g(Rs...)(Rs rs);

through a call to some map-and-forward-like-function `forwardMap` in 
something like


     bool f(Rs...)(Rs rs)
     {
     alias someArbitraryFun = _ => _;
     return g(forwardMap!(someArbitraryFun)(rs));
     }

?


Not with that syntax, as far as I know. A function can't return an alias 
seq like that.


But it can return a std.typecons.Tuple. You'd have to add `.expand` then:

return g(forwardMap!someArbitraryFun(rs).expand);


What should the definition of forwardMap look like?


Not tested beyond `f(1, 2.3, "foo")`:


auto forwardMap(alias fun, Ts ...)(Ts things)
{
import std.meta: aliasSeqOf, staticMap;
import std.range: iota;
import std.typecons: Tuple;
alias NewType(size_t i) = typeof(fun(things[i]));
alias NewTypes = staticMap!(NewType,
aliasSeqOf!(iota(things.length)));
Tuple!NewTypes results;
static foreach (i, thing; things) results[i] = fun(thing);
return results;
}


I wouldn't call it "forwardMap". "tupleMap" or "seqMap" maybe?


Does Phobos contain something like this already?


Not that I know of.

Re: Implementing tail-const in D

[sclytrack via Digitalmars-d]

On Monday, 29 January 2018 at 13:07:05 UTC, Simen Kjærås wrote:
On Thursday, 25 January 2018 at 21:33:10 UTC, Simen Kjærås 
wrote:

On Thursday, 25 January 2018 at 19:54:55 UTC, H. S. Teoh wrote:
In fact, if the standard implementation of opHeadMutable is 
basically the same across all types (or most types), it could 
even be provided as a mixin template in the library, then all 
you have to do is to `mixin headMutable` or something along 
those lines, and off you go.


I believe this should be possible


I wrote up a more formal description of what I'm suggesting:

https://gist.github.com/Biotronic/c6eefeb9796309360a5e8696d91d924d

--
  Simen



@headUnqualified
struct HeadUnqualifiedType1
{
HeadUnqualifiedType2 field;
}

tailQualifierHeadUnqualified(const) HeadUnqualifiedType1 a;

//Stupid opaque data types.

Re: Lazy caching map()?

[aliak via Digitalmars-d]

On Friday, 9 March 2018 at 19:41:46 UTC, H. S. Teoh wrote:
Today I found myself needing a lazy, caching version of map() 
on an array.  More precisely, given an array `T[] src` of 
source data and a function func(T) that's pretty expensive to 
compute, return an object `result` such that:


- result[i] == func(src[i]), for 0 ≤ i < src.length.

- If result[j] is never actually used, func(src[j]) is never 
invoked

  (lazy).

- If result[j] is referenced multiple times, a cached value is 
returned
  after the first time, i.e., the result of func(src[j]) is 
cached, and

  func(src[j]) is never invoked more than once.

I couldn't figure out how to build this using Phobos 
primitives, so I wrote my own implementation of it.  Pretty 
simple, really, it's just a wrapper struct that lazily 
initializes an array of Nullable!T and lazily populates it with 
func(j) when opIndex(j) is invoked, and just returns the cached 
value if opIndex(j) has been invoked before.


Can this be done using current Phobos primitives?


T


Unless I'm misunderstanding your requirements, are you looking 
for std.functionl.memoize?


auto fun(int a) {
writeln("here");
return a + 1;
}

void main() {
auto a = [1, 2, 3];
auto b = a.map!(memoize!fun);

writeln(b[1]);
writeln(b[1]);
writeln(b[1]);
}

will print "here" just once.

Re: Consume binary files

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, March 10, 2018 19:22:43 Bogdan via Digitalmars-d-learn wrote:
> On Saturday, 10 March 2018 at 18:49:48 UTC, Jonathan M Davis
>
> wrote:
> > Check out
> >
> > https://dlang.org/phobos/std_bitmanip.html#peek
> > https://dlang.org/phobos/std_bitmanip.html#read
> >
> > They can be used to read integral values from a range of
> > ubytes. You can use either std.file.read or std.stdio.File to
> > read from the file and than those functions from std.bitmanip
> > to convert the ubytes to integrals. std.file.read would be the
> > easiest to use, since it just gives you a single dynamic array
> > to deal with, but it does mean reading in the entire file at
> > once.
>
> Yes, thank you! That's much better, even if the source buffer
> gets consumed.

read consumes and peek just looks, though you need random access to peek
beyond the front of the range.

- Jonathan M Davis

Forwarding arguments through a std.algorithm.map

[Nordlöw via Digitalmars-d-learn]

If I have a function

bool f(Rs...)(Rs rs)

is it somehow possible to map and forward all its arguments `rs` 
to another function


bool g(Rs...)(Rs rs);

through a call to some map-and-forward-like-function `forwardMap` 
in something like


bool f(Rs...)(Rs rs)
{
alias someArbitraryFun = _ => _;
return g(forwardMap!(someArbitraryFun)(rs));
}

?

What should the definition of forwardMap look like?

Does Phobos contain something like this already?

Granular GC

[Amorphorious via Digitalmars-d]

The GC sucks because it requires one to use it or jump through 
many hoops and unsafe techniques to get away from it.


It would be better if we simply had more control over the GC.

1. Allow for granular GC - Multiple independent GC's that handle 
independent parts of the D ecosystem each of which can be 
overridden in code if desired.


One GC for the main user program(allocations, etc), One for D 
internals such as slices, One for exception handling, One for 
lambda's/delegates, etc.


The idea is that by having better resolution each GC can be 
tailored for it's specific purpose. For example, having a GC that 
handles the exception handling can be tailored so that it uses 
smaller memory and does not need to escape the memory reason to 
scan for false pointers, etc. It can also does not need to be run 
very often and should be relatively fast... in fact, if no 
exceptions are on the stack then it should exist immediately.


Similarly, lambda and delegates would have a relatively simple 
and fast GC since no false pointers need to be scanned, etc. In 
fact, some simple escape analysis should allow local allocations 
to bypass the GC.


What these do is reduce the overhead that might trigger a 
complete GC scan for no real purpose other than that is the way 
the current GC is designed.


When new GC topologies are added they simply replace the old. The 
main idea is to granularize the GC which simply requires 
modifying the compiler to use the specific GC(e.g., when slices 
are allocated, instead of allocating with the GC, it allocates 
with GC.Slices, or whatever).


The goal here is to still allow most of the D dependent GC 
functionality to persist but not have to throw the baby out with 
the bath water. E.g., keep the GC for exceptions(if it still uses 
it), lambda's/delegates, but allow one to use manual memory 
management for slices, or any combination one ones.  The main 
problem with the GC is stop the world and it's scanning for false 
pointers. But we really don't have to have an all or nothing 
attitude which is what is forced on us by a poor design.

Re: Embedded Linux really needs Dlang for the IOT market

[Cym13 via Digitalmars-d]

On Friday, 9 March 2018 at 11:35:58 UTC, aberba wrote:

On Friday, 9 March 2018 at 09:12:28 UTC, Radu wrote:

On Friday, 9 March 2018 at 03:09:16 UTC, dangbinghoo wrote:

[...]


I'm working in BAS(Building Automation System) sector, and I 
use Dlang daily for some advance products targeting ARM/Mips 
boards.


D on Glibc/Linux/ARM works great today! It is well supported 
and getting LDC to cross-compile is as easy as those 100 and 
so words say! I'm using Ubuntu shell on Windows (WSL) and this 
makes things even more exciting. Actually the hardest part is 
getting the C cross tool-chain for your system, not LDC, I 
find this pretty amusing.


A tutorial or guide on "cross tool-chain for your system" will 
be very helpful. Say in ARM. Not that obvious to someone like 
me.


Looks like this gem went unnoticed for too long: 
https://fkromer.gitbooks.io/d-on-embedded-linux-arm/content/

Re: Making recursively-defined traits iterative using `static foreach`

[Nordlöw via Digitalmars-d]

On Saturday, 10 March 2018 at 18:26:48 UTC, Simen Kjærås wrote:
Is there a way to break the `static foreach` loop prematurely 
as quickly as `allSameTypeIterative` becomes false?


Sure:

@property
bool allSameTypeIterative(V...)()
//if (allSatisfy!(isType, V))
{
foreach (Vi; V)
if (Vi != V[0]) return false;
return true;
}

No, it's not quite the same, but it's easier to read and gives 
the same result.


--
  Simen


That will trigger CTFE, but I'm trying to avoid that.

Re: Vision document for H1 2018

[Meta via Digitalmars-d-announce]

On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level 
priority - locking down the language definition. This is in 
recognition of the fact that we need a precise definition of 
the language going forward.



Thanks,

Andrei


Establish the DIP as a clear, solid means to get a language 
enhancement going


Very excited about this one. Hopefully some faith can be restored 
in the process.

Re: Consume binary files

[Bogdan via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 18:49:48 UTC, Jonathan M Davis 
wrote:

Check out

https://dlang.org/phobos/std_bitmanip.html#peek 
https://dlang.org/phobos/std_bitmanip.html#read


They can be used to read integral values from a range of 
ubytes. You can use either std.file.read or std.stdio.File to 
read from the file and than those functions from std.bitmanip 
to convert the ubytes to integrals. std.file.read would be the 
easiest to use, since it just gives you a single dynamic array 
to deal with, but it does mean reading in the entire file at 
once.


- Jonathan M Davis


Yes, thank you! That's much better, even if the source buffer 
gets consumed.

Re: FALSE programming language: D implementation

[Rémy Mouëza via Digitalmars-d]

On Saturday, 10 March 2018 at 11:47:48 UTC, snowCat wrote:
Recently, the task of implementing the FALSE programming 
language on D has come up and I have faced the problem of 
splitting the FALSE expression into a list of strings from its 
typical elements: blocks of comments, numbers, strings and 
operators.

How to properly implement such a partition, tell me please.
Or at least tell me how to describe his grammar in Pegged.
Your name in the article about the implementation of my blog is 
guaranteed.


I implemented a small concatenative language in 2016 and used 
Pegged for the lexing.
I uploaded the source on github: 
https://github.com/remy-j-a-moueza/stacky.

The Pegged grammar is at the beginning of `stacky.d`.
Pegged is also pretty well documented in its wiki and tutorial 
(https://github.com/PhilippeSigaud/Pegged/wiki/Pegged-Tutorial).


As for a hand made lexer, the last time I clearly remember 
working on one was in 2007, on D1, trying to lex C++.
I copied part of that code here: 
https://gist.github.com/remy-j-a-moueza/8909819cbf972430bfbb16dff768b97d


The algorithm is mainly:
- try to match a regular expression
-- on a match: create a token for what has been matched, move 
forward in your string input, loop to the next iteration,

-- on error: try again with another regular expression.
By the end you should have accumulated your tokens.

There is a lot of resources online about parsing, in various 
programming languages and libraries, way better than what I have 
provided. Whatever the tools, the principles stay the same. 
Whatever you can learn somewhere else will still be usable in D, 
just a bit differently.


I hope this help.
Have fun.

Re: Consume binary files

[Mark Fisher via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 18:26:43 UTC, Bogdan wrote:
I'm working on a pet project which involves reading various 
structure types, or just multi-byte values (uin32_t, uint16_t, 
etc) from files, or just from ubyte arrays.



I think you should use ranged types.

Re: Consume binary files

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, March 10, 2018 18:31:23 Bogdan via Digitalmars-d-learn wrote:
> ... I accidentally posted that before it was complete because I
> kept pressing TAB in order to indent ...
>
> Anyway, I'd like to know if there exists such a thing as
>
> ```
>  int a = stream.ReadInt32();
> ```

Check out

https://dlang.org/phobos/std_bitmanip.html#peek
https://dlang.org/phobos/std_bitmanip.html#read

They can be used to read integral values from a range of ubytes. You can use
either std.file.read or std.stdio.File to read from the file and than those
functions from std.bitmanip to convert the ubytes to integrals.
std.file.read would be the easiest to use, since it just gives you a single
dynamic array to deal with, but it does mean reading in the entire file at
once.

- Jonathan M Davis

Re: Consume binary files

[Bogdan via Digitalmars-d-learn]

... I accidentally posted that before it was complete because I 
kept pressing TAB in order to indent ...


Anyway, I'd like to know if there exists such a thing as

```
int a = stream.ReadInt32();
```

Consume binary files

[Bogdan via Digitalmars-d-learn]

I'm working on a pet project which involves reading various 
structure types, or just multi-byte values (uin32_t, uint16_t, 
etc) from files, or just from ubyte arrays.


Here's how I've been dealing with some of these situations so far:

```
/// Helper structure used to read each of the file 
descriptors in a HOG file

struct HogFileDescriptor
{
align(1):
char[13] fileName;
int fileSize;
}

ubyte[HogFileDescriptor.sizeof] buffer;

File f = File(filename, "r");

// while bytes left in file
f.rawRead(buffer);
hfd = cast(HogFileDescriptor*) buffer.ptr;

Re: Making recursively-defined traits iterative using `static foreach`

[Simen Kjærås via Digitalmars-d]

On Saturday, 10 March 2018 at 13:30:18 UTC, Nordlöw wrote:

On Saturday, 10 March 2018 at 09:47:55 UTC, Nordlöw wrote:
Now that we have `static foreach` I just realized we can 
start...


My recent definition now looks like

template allSameTypeIterative(V...)
// TODO restrict `V` to types only
{
static if (V.length <= 1)
{
enum allSameTypeIterative = true;
}
else
{
static foreach (Vi; V[1 .. $])
{
static if (!is(typeof(allSameTypeIterative) == 
bool) && // not yet defined
   !is(V[0] == Vi)) // 10% faster than 
`!isSame(V[0], Vi)`

{
enum allSameTypeIterative = false;
}
}
static if (!is(typeof(allSameTypeIterative) == bool)) 
// if not yet defined

{
enum allSameTypeIterative = true;
}
}
}

Is there a way to break the `static foreach` loop prematurely 
as quickly as `allSameTypeIterative` becomes false?


Sure:

@property
bool allSameTypeIterative(V...)()
//if (allSatisfy!(isType, V))
{
foreach (Vi; V)
if (Vi != V[0]) return false;
return true;
}

No, it's not quite the same, but it's easier to read and gives 
the same result.


--
  Simen

Re: Do forum posts use any markup language?

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 18:02:48 UTC, Bogdan wrote:
I'd like to distinguish between regular text and code, maybe 
have quotes, etc.


You can write with email plain text conventions. The forum 
software recognizes just some of it,  but the readers will know 
what you mean.


So like quote lines get leading `>` (forum parses this). You can 
put `---` or ``` around code blocks (people know what you mean), 
stuff like that.

Re: dpldocs now has cross-package search (experimental)

[Adam D. Ruppe via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 16:49:44 UTC, Martin Tschierschke 
wrote:
There is a bug, I just tried "mouse event" in the search box 
and got a strange result.


oh yikes a recursive javascript redirect. fixed that.

The search still kinda sucks, but it is better than nothing. If 
you put in a full name, it should be the first result. Otherwise, 
it tries a full text search that is a bit spotty.

Do forum posts use any markup language?

[Bogdan via Digitalmars-d-learn]

I'd like to distinguish between regular text and code, maybe have 
quotes, etc.

Re: Generic Property Implementation

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 9 March 2018 at 23:34:56 UTC, Mike Franklin wrote:

On Friday, 9 March 2018 at 14:46:04 UTC, Simen Kjærås wrote:

1) Wrong return type:
unittest {
S s;
auto a = s.field;
// Fails - typeof(a) is Property!((get) => this.n, (set) 
=> this.n = set)

assert(is(typeof(a) == int));
}


This looks like a related issue:  
https://issues.dlang.org/show_bug.cgi?id=16657.  That's is a 
deal-breaker for me, but I think it could be fixed.


This has nothing to do with alias this, opCmp, or opEquals. It's 
simply that instead of returning an int, like the original 
property did, s.field returns a wrapper type. There's no real way 
around this.


Actually, there may be a more interesting way to implement the 
DIP I mentioned - what if named mixin templates could have 
overloaded operators and alias this? What if this worked:


struct S {
int n;
mixin property!(get => n, set => n = set) field;
}

template property(fns...) {
alias getter = findGetter!fns;
alias setter = findSetter!fns;

auto get() { return getter(DummyType.init); }
alias get this;
alias setter opAssign;

auto opOpAssign(string op, T)(T value) { /* ... */ }
// other overloads
}

unittest {
S s;
auto a = s.field; // Not a type, so alias this is used.
assert(is(typeof(a) == int));
// overloaded operators
s.field += 4;
++s.field;
}

From what I can see, the only necessary change would be that 
alias this and operator overloads be looked for in named mixin 
templates. Sounds doable. This would both enable 
auto-decaying/rvalue types, and allow for a bunch of interesting 
stuff with operator overloads.


...but there's an issue with this compared to real rvalue types - 
you can't return them from a function. One use case for rvalue 
types is short-circuiting when (a op1 b op2 c) can be done faster 
than ((a op1 b) op2 c), for instance when a, b, and c are 
BigInts, and op1 = ^^, op2 = %. Named mixin templates with 
overloaded operators cannot do this.



2) Noisy syntax:
If I had my druthers, mixin templates would be mixin'd 
automatically, and eponymous mixin templates would be a thing.


Yes, this would be nice, but I don't think it's a deal-breaker.


Agreed. I filed an issue on the eponymous mixin templates:
https://issues.dlang.org/show_bug.cgi?id=18586



3) Stringy functions:
The string literal functions are an eyesore, but would require 
some compiler work to fix.


Yeah, that's quite unfortunate; writing code in strings stinks.
 I actually prefer the DIP for this issue alone.


I'm not sure how fixable this is, but I am sure that there's 
plenty of benefit to being able to write code like this:


struct S {
int n, m;
SomeType!(() => n + m) a;
}

over this:

struct S {
int n, m;
auto a() { return SomeType!(() => n + m)(); }
}

Anyways, I filed a bug for it:
https://issues.dlang.org/show_bug.cgi?id=18587


If all of the issues you've identified were addressed, you'd 
end up with something like this (formatted in a C# way).


struct S {
int n;
property!
(
get =>
{
n
},
set =>
{
n = set
}
) field;
}

That's actually pretty darn good.  It makes me wonder if I 
should work on fixing those issues or continue with the DIP.


The real benefit to doing it outside the DIP is that the features 
can be used in other contexts. Rvalue types definitely have some 
more uses, the 'this.n' issue is simply a bug, eponymous mixin 
templates seem useful to me, and being able to use delegates as 
template parameters outside of member functions would make many 
things clearer.



If you don't have any objections I'd like to incorporate this 
implementation and your analysis into the DIP.


Of course.


Thank you again for doing this; you've saved me a awful lot of 
time, and have done more than I probably could have.


Pleasure. I've been spending some time on this myself, so it's 
not the first time I've tried to make a palatable implementation.


--
  Simen

[Issue 18588] New: alias this inside named mixin template

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

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

  Issue ID: 18588
   Summary: alias this inside named mixin template
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

struct S {
mixin foo!() bar;
}

template foo() {
int n;
alias n this;
}

unittest {
int n = S.init;
}

The alias this is inside a named member of S, and it is counterintuitive that
it affects S.

--

Re: dpldocs now has cross-package search (experimental)

[Martin Tschierschke via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 16:35:56 UTC, Adam D. Ruppe wrote:
On Saturday, 10 March 2018 at 16:03:39 UTC, Martin Tschierschke 
wrote:
Cool, and if you are in the mood of using only arsd, for 
example find an example for a trigger on mouse request:

http://search.dpldocs.info/search-docs.html?searchTerm=arsd+mouse


Yup.

You can also search inside a particular package/version by 
going to it and using the upper right search box there.


http://arsd-official.dpldocs.info/v2.0.0/search-results.html#!mouse

for example will just search v2.0.0 of the arsd-official 
package.



There is a bug, I just tried "mouse event" in the search box and 
got a strange result.

[Issue 18587] New: Context pointer not set for delegate template parameter when declared in struct body

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

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

  Issue ID: 18587
   Summary: Context pointer not set for delegate template
parameter when declared in struct body
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

struct S {
int n;
R!(() => n) a;
}

struct R(alias fn) {
int get() {
return fn();
}
}

unittest {
auto s = S(3);
assert(s.a.get() == 3);
}

The above code fails with 'Error: need 'this' for 'n' of type 'int''.
It is clear that the intended semantics of the above code is similar to this:

struct S {
   int n;
   auto a() { return R!(() => n)(); }
}

struct R(alias fn) {
int get() {
return fn();
}
}

unittest {
auto s = S(3);
assert(s.a.get() == 3);
}

However, the latter example works, while the former doesn't. This leads to
unnecessary boilerplate and unreadable code.

--

Re: dpldocs now has cross-package search (experimental)

[Adam D. Ruppe via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 16:03:39 UTC, Martin Tschierschke 
wrote:
Cool, and if you are in the mood of using only arsd, for 
example find an example for a trigger on mouse request:

http://search.dpldocs.info/search-docs.html?searchTerm=arsd+mouse


Yup.

You can also search inside a particular package/version by going 
to it and using the upper right search box there.


http://arsd-official.dpldocs.info/v2.0.0/search-results.html#!mouse

for example will just search v2.0.0 of the arsd-official package.


and i just hit a huge module on my thing:
core.exception.OutOfMemoryError@core/exception.d(702): Memory 
allocation failed


uh oh, the search went up to 3.2 GB now. That shouldn't have 
happened - even the beefier hardware can't support all that!


So I still need to do some more optimizations before promoting 
this from "experimental" but we'll get there.

[Issue 18586] New: Eponymous mixin templates

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

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

  Issue ID: 18586
   Summary: Eponymous mixin templates
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

The eponymous template trick is very useful in other cases, but there seems to
be an oversight in that mixin templates don't benefit from it.

The usefulness of this lies in a reduced reliance on string mixins, and a
decoupling of the mixin template arguments from the name of the mixed-in code.
Consider:

struct S {
int n;
mixin fun!("myfunction", "return n;");
}

mixin template fun(string funName, string body) {
mixin("auto "~funName~"() { "~body~" }");
}

unittest {
auto s = S(3);
assert(s.myfunction == 3);
}

That's the code you currently have to write to mix in a function with a
specific name. With eponymous templates, the function name wouldn't need to be
passed:

struct S {
int n;
mixin fun!"return n;" myfunction ;
}

mixin template fun(string body) {
mixin("auto fun() { "~body~" }");
}

unittest {
auto s = S(3);
assert(s.myfunction == 3);
}

--

Re: dpldocs now has cross-package search (experimental)

[Martin Tschierschke via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 00:09:18 UTC, Adam D. Ruppe wrote:

Looking for http libs? Behold:

http://search.dpldocs.info/?q=http


Oh my. Eats 2 GB of ram but with the newest patrons 
 I sprung for the beefier 
host. Only searches projects already on the site as of the 
beginning of each day (it loads what has already been 
generated, it doesn't seek to generate more at this time).


It loads one of my own deprecated modules as the top result. 
lol, it could still use some work. But it is started now.


Cool, and if you are in the mood of using only arsd, for example 
find an example for a trigger on mouse request:

http://search.dpldocs.info/search-docs.html?searchTerm=arsd+mouse

Re: DUB and Gtk-d reduce size of huge executable, build dynamic dependencies

[Gerald via Digitalmars-d-learn]

On Wednesday, 7 March 2018 at 10:51:49 UTC, CSim wrote:

Hi,

I'm trying to decide whether it is better to use DLang for Gtk 
development or Vala/Genie.


When I make a simple Vala/Genie Gtk executable the file is tiny 
whereas the DLang file is huge.  First I used the default Dub 
build and the file was in excess of 60mb (assuming this 
includes debug build).  Using dub build=release the file is 
still more than 7 mb.  Using a native Vala/Genie build the file 
is less than 500k.


Trying to understand what is going on, but I assume from this 
that Dub is linking static dependencies, whereas the Vala/Genie 
builds will link to dynamic libraries.



So my (two pronged) question is this:  Is there any way to 
specify in dub.json to build and link dependencies as dynamic 
libraries, and are there any other tips that can be used to 
reduce these (relatively) huge executables?


Personally, I do not worry too much about the executable size, 
however a couple of tips as follows:


a. If this is on linux use "strip" to remove symbols out of the 
executable


b. In dub.json you can specify just the portions of GtkD that 
your application depends on, i.e.:


"dependencies": {
"gtk-d:gtkd": {
"version": "3.7.5"
},
"gtk-d:vte": {
"version": "3.7.5"
}
}

Is what I use in tilix (https://github.com/gnunn1/tilix)

c. You can dynamically link to GtkD, in tilix I have the config 
below to do so. Interestingly on ldc it doesn't make any 
difference in size though using ldd I can see the dependency to 
GtkD. With DMD it is smaller however I cannpt run it since the 
Arch Linux GtkD package is compiled with ldc2.


{
"name": "dynamic",
"targetType": "executable",
"libs": ["gtkd-3"],
"libs-linux": ["X11"],
"lflags": ["-defaultlib=libgtkd-3.so"],
"versions": ["StdLoggerDisableTrace"]
}

Re: Embedded Linux really needs Dlang for the IOT market

[Martin Tschierschke via Digitalmars-d]

On Friday, 9 March 2018 at 12:41:52 UTC, Binghoo Dang wrote:

On Friday, 9 March 2018 at 09:12:28 UTC, Radu wrote:

[...]


I'm working in BAS(Building Automation System) sector, and I 
use Dlang daily for some advance products targeting ARM/Mips 
boards.


[...]


That's great, it looks that what I need to do is just try! And, 
I would write a paper after I get everything working. thanks!


Yes, please write down your steps to success and place it 
somewhere it can be found :-)

(https://wiki.dlang.org/) There is not to much documentation!

Re: State of D 2018 Survey

[rumbu via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 14:24:42 UTC, Johannes Loher wrote:

Is there a way to directly view the results without taking the 
survey again?


https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig

Re: Making recursively-defined traits iterative using `static foreach`

[Nordlöw via Digitalmars-d]

On Saturday, 10 March 2018 at 13:30:18 UTC, Nordlöw wrote:

On Saturday, 10 March 2018 at 09:47:55 UTC, Nordlöw wrote:
Now that we have `static foreach` I just realized we can 
start...


My recent definition now looks like

template allSameTypeIterative(V...)
// TODO restrict `V` to types only
{
static if (V.length <= 1)
{
enum allSameTypeIterative = true;
}
else
{
static foreach (Vi; V[1 .. $])
{
static if (!is(typeof(allSameTypeIterative) == 
bool) && // not yet defined
   !is(V[0] == Vi)) // 10% faster than 
`!isSame(V[0], Vi)`

{
enum allSameTypeIterative = false;
}
}
static if (!is(typeof(allSameTypeIterative) == bool)) 
// if not yet defined

{
enum allSameTypeIterative = true;
}
}
}

Is there a way to break the `static foreach` loop prematurely 
as quickly as `allSameTypeIterative` becomes false?


After benchmarking using

https://github.com/nordlow/phobos-next/blob/master/benchmarks/iterative-traits/source/app.d

the iterative-version speed-up ranges from 1.1 to 10x for my 
specific sets of input. The higher speed-up is thanks to


- reducing the template instantiation count from log(n), in the 
recursive case, to 1 in iterative case and
- a static if loop that prevents successive calls when, for 
instance,

  - predicate is true in `anySatisfyIterative and
  - predicate is false in `allSatisfyIterative and

At

https://github.com/nordlow/phobos-next/blob/master/benchmarks/iterative-traits/source/app.d

the compilation-times are written in the comments for each kind 
of benchmark.

Re: Vibe.d web interface tutorial

[Martin Tschierschke via Digitalmars-d-announce]

On Friday, 9 March 2018 at 16:34:52 UTC, aberba wrote:

On Friday, 9 March 2018 at 16:32:28 UTC, aberba wrote:

New blog post for the learning audience

aberba.com/2018/using-vibe-d-web-interface


http://aberba.com/2018/using-vibe-d-web-interface


Thank you! I linke it.

Re: Embedded Linux really needs Dlang for the IOT market

[dangbinghoo via Digitalmars-d]

On Friday, 9 March 2018 at 14:30:44 UTC, Radu wrote:

On Friday, 9 March 2018 at 11:35:58 UTC, aberba wrote:

[...]


For LDC on ubuntu is is pretty straight forward

1. Get cross tools for ARM, let's say ARM HF (hardware floating 
point)



[...]


2. Install LDC

3. Build cross libraries for LDC

From https://wiki.dlang.org/Building_LDC_runtime_libraries:


[...]


Your cross compiled druntime and phobos libs will be the result 
of this step, they are located in the 
`/path/to/ldc-arm-linux-hf/lib` folder.


4. Compile your code


[...]


You now have an linux arm hf binary that can run on your target 
device.


wow ! this is the real tutorial! thanks!

Re: State of D 2018 Survey

[Johannes Loher via Digitalmars-d-announce]

Am 28.02.2018 um 14:41 schrieb Mike Parker:
> About a month ago, Sebastian Wilzbach sent an email out to a few of the
> core D folks asking for feedback on a survey he had put together. He
> thought it would be useful for the Foundation to use in order to make
> decisions about where to expend development efforts. Eventually Andrei
> gave his stamp of approval, the survey questions were tweaked, and then
> it was ready to roll.
> 
> Of course I would love for you to read my blog post announcing it, but
> if you want to skip the prose and go straight to the good stuff, here's
> the survey link:
> 
> https://seb134.typeform.com/to/H1GTak
> 
> The blog:
> https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/
> 
> Reddit:
> https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/
> 

Is there a way to directly view the results without taking the survey again?

What principle difference between structure and Tuple?

[Suliman via Digitalmars-d-learn]

writeln(is(Tuple!(string, int) == struct)); // true

What is real user case where I should use Tuple instead of Struct?

Re: Making recursively-defined traits iterative using `static foreach`

[Nordlöw via Digitalmars-d]

On Saturday, 10 March 2018 at 09:47:55 UTC, Nordlöw wrote:
Now that we have `static foreach` I just realized we can 
start...


My recent definition now looks like

template allSameTypeIterative(V...)
// TODO restrict `V` to types only
{
static if (V.length <= 1)
{
enum allSameTypeIterative = true;
}
else
{
static foreach (Vi; V[1 .. $])
{
static if (!is(typeof(allSameTypeIterative) == bool) 
&& // not yet defined
   !is(V[0] == Vi)) // 10% faster than 
`!isSame(V[0], Vi)`

{
enum allSameTypeIterative = false;
}
}
static if (!is(typeof(allSameTypeIterative) == bool)) // 
if not yet defined

{
enum allSameTypeIterative = true;
}
}
}

Is there a way to break the `static foreach` loop prematurely as 
quickly as `allSameTypeIterative` becomes false?

Why Pay For Learning a Foreign Language?

[Globibo via Digitalmars-d-learn]

A major rationale behind paying to learn a new foreign language 
in a good language school is to enjoy the prospect of greater job 
opportunity and an opportunity to earn more money. But is that 
perception really true? Will learning a new language enable a 
person to earn higher salary than before? Today, there is an 
availability of increased online learning resources as well as no 
dearth of good foreign language schools. So, there is hardly any 
reason why you should not pay to learn a new foreign language, 
When you become a bilingual or multilingual, you can not only 
brag out your skills in front of your colleagues and friends but 
can also get an edge over others and stand out in a highly 
competitive job market.




For example. 25 percent of people living in the U.S., claim that 
they are able to converse in a foreign language. In fact, there 
are many people all over the world who strongly believe that 
knowing a foreign language comes extremely handy at the 
workplace. Now this belief is not exactly unfounded since there 
is a good return on investment when a person pays to learn a 
different language.


When you learn another language, there is a possibility of wage 
increases. Plus, the skill also opens up a host of excellent job 
opportunities, which would definitely be much less in the case of 
all those employees who can communicate only in a single 
language. However, the benefits do not just stop here. Paying to 
learn a new foreign language can also keep a human brain healthy 
and in good shape for a longer time period.


More information on :
www.language-school.hk

Re: LDC / BetterC / _d_run_main

[Richard via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 10:57:05 UTC, Johan Engelen wrote:

On Saturday, 10 March 2018 at 07:54:33 UTC, Mike Franklin wrote:

On Saturday, 10 March 2018 at 02:25:38 UTC, Richard wrote:

Hi,
I've been trying to see if I can get an mbed project to work 
with Dlang

basically compiling D code for use on a Cortex-M Proccessor


You might be interested in the following, if you're not 
already aware:

 * https://github.com/JinShil/stm32f42_discovery_demo
 * https://bitbucket.org/timosi/minlibd


There is also: https://github.com/kubo39/stm32f407discovery and 
its submodules.


The STM32 demo only supports GDC right now, but I'll be 
updating it to support LDC when 2.079.0 lands there.


Awesome.

-Johan


That's interesting
I've uploaded by own setup over here if anyone's interested

  * https://github.com/grbd/GBD.Dlang.MbedBlinkyTest

Re: LDC / BetterC / _d_run_main

[Uknown via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 12:00:12 UTC, Richard wrote:

On Saturday, 10 March 2018 at 07:54:33 UTC, Mike Franklin wrote:

On Saturday, 10 March 2018 at 02:25:38 UTC, Richard wrote:

[snip]
Based on the above this seems to work fine so I'll use this 
since it's the simplest option.

```
extern(C) int main(int argc, char** argv) {
return d_main();
}

int d_main() {
  // Do stuff
}
```


You can simplify it further:

```
extern(C) int main(int argc, char** argv {
//Do stuff
}
```


This compiles but main() is never called btw
```
import core.stdc.stdio;

private alias extern(C) int function(char[][] args) 
MainFuncType;
extern (C) int _d_run_main(int argc, char **argv, void* 
mainFunc)

{
MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}

int main() {
  // Do stuff
}
```
I tried compiling with
ldc2 -defaultlib= -debuglib= -mtriple=thumb-none-linux-eabi 
-mcpu=cortex-m3 --od=. -c -betterC main.d


I think you should not put `-betterC` since you are trying to use 
_d_run_main, which is only called when in regular mode.

Re: Vision document for H1 2018

[Aurélien Plazzotta via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:
Hello, the vision document of the Founation for the first six 
months of 2018 is here:


https://wiki.dlang.org/Vision/2018H1



According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


Just ignore it. And don't forget the primary betterC's goal.
It was never designed to please some C developers to take profit 
from D without dealing with D full runtime but to help migrating 
from historical C/C++ compiler backend to a fully D native 
compiler backend.


The objective is to obtain bootstraping and get rid of all other 
language's dependencies, which will be a huge advantage and 
advertising for D use and in extenso, D community and 
penetration-market.


Convincing C developpers to try out betterC is "just" a temporary 
(and positive) side-effect.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote:
I'm talking about the D Foundation priority list, not about the 
open source community surrounding it. I have nothing against 
betterC, the community is free to work on it, but I don't 
understand why it's a *priority* for the D foundation. Is there 
any funding involved requesting explicitly betterC support?


perhaps this question can be one of many, that the community ask 
the members of the D foundation, on stage, during the Q and A at 
the upcoming Dconf ;-)


there will be a roasting.. won't there?

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote:


I'm talking about the D Foundation priority list, not about the 
open source community surrounding it. I have nothing against 
betterC, the community is free to work on it, but I don't 
understand why it's a *priority* for the D foundation. Is there 
any funding involved requesting explicitly betterC support?


I think cause interoperating with C/C++, as well as encouraging 
migrating C/C++ code over D..has always been a key objective for 
Andrei and Walter (as least that's the impression I get - as a 
relative newcomer to D).


So I doesn't surprise me that it would be (remain) a priority for 
the D foundation, which they (and others) represent.


All power to em...

Although... I'm just not convinced that C programmers will give 
up C, and C++ programmers will give up C++ ... well... certainly 
I don't see any mass migration on the horizon of my crystal ball.


Everyone will end up programming in C++, Java, or .NET .. says 
the crystal ball.

Re: LDC / BetterC / _d_run_main

[Richard via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 07:54:33 UTC, Mike Franklin wrote:

On Saturday, 10 March 2018 at 02:25:38 UTC, Richard wrote:

Hi,
I've been trying to see if I can get an mbed project to work 
with Dlang

basically compiling D code for use on a Cortex-M Proccessor


You might be interested in the following, if you're not already 
aware:

 * https://github.com/JinShil/stm32f42_discovery_demo
 * https://bitbucket.org/timosi/minlibd

The STM32 demo only supports GDC right now, but I'll be 
updating it to support LDC when 2.079.0 lands there.  2.079.0 
removes some coupling of the compiler to the runtime, so I 
should be able to avoid the following bugs:


https://github.com/ldc-developers/ldc/issues/created_by/JinShil


so I tried this instead
```
extern (C) int _d_run_main(int argc, char **argv, void* 
mainFunc) {

MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}
```

but nope that didn't seem to work ether, compiles okay but the 
code in main() (D space) isn't called
I'd imagine this should be a simple thing, anyone got any 
ideas?


The following worked fine for me on my x64 Linux desktop with 
LDC version 1.8.0 (DMD v2.078.3, LLVM 5.0.1)


``` main.d
import core.stdc.stdio;

private alias extern(C) int function(char[][] args) 
MainFuncType;
extern (C) int _d_run_main(int argc, char **argv, void* 
mainFunc)

{
MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}

void main()
{
printf("Hello, World!\n");
}
```

Compile with: ldc2 -defaultlib= -debuglib= -betterC main.d

Mike



Based on the above this seems to work fine so I'll use this since 
it's the simplest option.

```
extern(C) int main(int argc, char** argv) {
return d_main();
}

int d_main() {
  // Do stuff
}
```


This compiles but main() is never called btw
```
import core.stdc.stdio;

private alias extern(C) int function(char[][] args) MainFuncType;
extern (C) int _d_run_main(int argc, char **argv, void* mainFunc)
{
MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}

int main() {
  // Do stuff
}
```
I tried compiling with
ldc2 -defaultlib= -debuglib= -mtriple=thumb-none-linux-eabi 
-mcpu=cortex-m3 --od=. -c -betterC main.d

Re: Vision document for H1 2018

[rumbu via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit wrote:

On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


A reasonable point.

But.. in any case.. people work on what they are motivated to 
work on.


That's really all there is to it.

That's how the open source community works.



I'm talking about the D Foundation priority list, not about the 
open source community surrounding it. I have nothing against 
betterC, the community is free to work on it, but I don't 
understand why it's a *priority* for the D foundation. Is there 
any funding involved requesting explicitly betterC support?

FALSE programming language: D implementation

[snowCat via Digitalmars-d]

Recently, the task of implementing the FALSE programming language 
on D has come up and I have faced the problem of splitting the 
FALSE expression into a list of strings from its typical 
elements: blocks of comments, numbers, strings and operators.

How to properly implement such a partition, tell me please.
Or at least tell me how to describe his grammar in Pegged.
Your name in the article about the implementation of my blog is 
guaranteed.

Re: Vision document for H1 2018

[psychoticRabbit via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


who cares what 'the majority' want... I mean really.

stuff em!

(ohh... that was in jest.. don't take that seriously)

Re: Vision document for H1 2018

[Mike Parker via Digitalmars-d-announce]

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:



According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


1. The vision document was started before the survey and the 
survey isn't closed, so the survey results don't factor into it 
yet.


2. The survey results will serve as a set of guidelines for 
future directions, not as a set of absolute directives. It wasn't 
a controlled survey and it doesn't reflect the entire D community.


3. Work on BetterC was started a long time ago and isn't going to 
be abandoned over night.


If something shows up as high priority in the survey, then it 
makes sense to evaluate its impact and see how we can devote more 
resources to it going forward. If something shows up as low 
priority, then we have to take a number of factors into account, 
(e.g. Is it being worked on already? Are there commercial 
interests who *do* consider it a priority? Etc.).


In other words, when setting goals post-survey, the results will 
factor into the decisions, but they won't necessarily be the 
deciding factor. The survey is a means of getting community input 
in one place, as opposed to scattered across the forums and 
reddit comments.