[Issue 15992] [REG2.072a] ICE with field variable of instantiated struct

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/201b124e6c1784c19bdd012bdec7577452d82338
fix Issue 15992 - ICE with field variable of instantiated struct

When a template is instantiated in function body, it usually gets no chance to
run `semantic2`, because inserted module's `semanticRun` would be greater than
`PASSsemantic2done` (function bodies are analyzed in global `semantic3` stage).

Therefore we should append template instances to global deferred `semantic2`
list as same as for `semantic3`.

https://github.com/dlang/dmd/commit/298d0102d27a50ef048c3bceb6761b470b4bc18c
Merge pull request #5780 from 9rnsr/fix15992

[REG2.072a] Issue 15992 - ICE with field variable of instantiated struct

--

[Issue 15995] std.conv.text and friends can be made faster with std.array.appender

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15995
Issue 15995 depends on issue 15992, which changed state.

Issue 15992 Summary: [REG2.072a] ICE with field variable of instantiated struct
https://issues.dlang.org/show_bug.cgi?id=15992

   What|Removed |Added

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

--

Re: DIP: Tail call optimization

[A.B via Digitalmars-d-announce]

On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:

Hi everyone (=

I've just added a new proposal to add a new attribute to ensure 
TCO is applied.


The proposal is really simple, but I'm clueless on how to 
implement it and also interested on getting feedback on it.



The proposal it's ready for merge on the new [DIPs 
repo](https://github.com/dlang/DIPs/pull/6)


--
Dietrich


That's crap...I disassemble DMD output some time to time. It 
already does TCO.

Definitively a lol day...

Re: Card on fire

[Jack Stouffer via Digitalmars-d]

On Sunday, 10 July 2016 at 02:43:42 UTC, Andrei Alexandrescu 
wrote:
Got a text from Walter - his famous fanless graphics card 
caught fire along with the motherboard. He'll be outta 
commission for a few days. -- Andrei


Glad he's ok.

Maybe go overboard with the fans this time ;)

Re: UB in D

[Andrei Alexandrescu via Digitalmars-d]

On 7/9/16 11:52 PM, Observer wrote:

On Sunday, 10 July 2016 at 02:29:15 UTC, Andrei Alexandrescu wrote:

You're overthinking this. Undefined is undefined. We're done here.


Andrei, you're underthinking this.  You're treating it like an
elegant academic exercise in an ivory tower, without consideration
for the practical realities of using the language productively
(i.e., getting direct feedback when the programmer makes mistakes,
which we all do, so s/he doesn't need to spend hours in a debugger).


Oh, I'm all for defining formerly undefined behavior. But don't call it 
undefined. I'm just fact checking over here. -- Andrei

DIP: Tail call optimization

[Dietrich Daroch via Digitalmars-d-announce]

Hi everyone (=

I've just added a new proposal to add a new attribute to ensure 
TCO is applied.


The proposal is really simple, but I'm clueless on how to 
implement it and also interested on getting feedback on it.



The proposal it's ready for merge on the new [DIPs 
repo](https://github.com/dlang/DIPs/pull/6)


--
Dietrich

Re: Vision for the D language - stabilizing complexity?

[Meta via Digitalmars-d]

On Sunday, 10 July 2016 at 02:44:14 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 9 July 2016 at 08:39:10 UTC, Walter Bright wrote:
Seems that in order to make it useful, users had to extend it. 
This doesn't fit the criteria.


Scheme is a simple functional language which is easy to extend. 
Why would you conflate "useful" with "used for writing complex 
programs"?


Anyway, there are many other examples, but less known.

Wirth's Pascal had the same problem. He invented an elegant, 
simple, consistent, and useless language. The usable Pascal 
systems all had a boatload of dirty, incompatible extensions.


I am not sure if Pascal is elegant, but it most certainly is 
useful. So I don't think I agree with your definition of 
"useful".



What programmers think of as "intuitive" is often a collection 
of special cases.


I think I would need examples to understand what you mean here.


I agree with Walter here. Scheme is not a language that you can 
generally do useful things in. If you want to do anything 
non-trivial, you switch to Racket (which is not as minimalistic 
and "pure" as Scheme).

Re: Card on fire

[A.B via Digitalmars-d]

On Sunday, 10 July 2016 at 02:43:42 UTC, Andrei Alexandrescu 
wrote:
Got a text from Walter - his famous fanless graphics card 
caught fire along with the motherboard. He'll be outta 
commission for a few days. -- Andrei


lol

https://www.youtube.com/watch?v=NOErZuzZpS8

Re: UB in D

[Observer via Digitalmars-d]

On Sunday, 10 July 2016 at 02:29:15 UTC, Andrei Alexandrescu 
wrote:
You're overthinking this. Undefined is undefined. We're done 
here.


Andrei, you're underthinking this.  You're treating it like an
elegant academic exercise in an ivory tower, without consideration
for the practical realities of using the language productively
(i.e., getting direct feedback when the programmer makes mistakes,
which we all do, so s/he doesn't need to spend hours in a 
debugger).

Re: D is crap

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 9 July 2016 at 09:15:19 UTC, Chris wrote:
Yes, of course the "write-once-run-everywhere" fairy tale 
helped to spread Java, but while it was gaining traction GC 
became a feature everybody wanted. Sorry, but there is not a 
single book or introduction to Java that doesn't go on about 
how great GC is.


Just like there is no C++ book that does not rant about how great 
RAII is... What do you expect from a language evangelic? The 
first Java implementation Hotspot inherited its technology from 
StrongTalk, a Smalltalk successor. It was not a Java phenomenon, 
and FWIW both Lisp, Simula and Algol68 were garbage collected.


What was "new" with Java was compile-once-run-everywhere. 
Although, that wasn't new either, but it was at least marketable 
as new.


Java was the main catalyst for GC - or at least for people 
demanding it. Practically everybody who had gone through IT 
courses, college etc. with Java (and there were loads) wanted 
GC. It was a given for many people.


Well, yes, of course Java being used in universities created a 
demand for Java and similar languages. But GC languages were 
extensively used in universities before Java.


Yes, it didn't last long. But the fact that they bothered to 
introduce it, shows you how big GC was/is.


No, it shows how demanding manual reference counting was in 
Objective-C on regular programmers. GC is the first go to 
solution for easy memory management, and has been so since the 
60s. Most high level languages use garbage collection.

exceptions vs error codes

[Superstar64 via Digitalmars-d]

In terms of performance and code generation exceptions are faster 
in the regular path while error codes are faster in the error 
path.


Would it be possible and a good idea to have a language feature 
that allows some exceptions to use error code code generation.

Re: Vision for the D language - stabilizing complexity?

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 9 July 2016 at 08:39:10 UTC, Walter Bright wrote:
Seems that in order to make it useful, users had to extend it. 
This doesn't fit the criteria.


Scheme is a simple functional language which is easy to extend. 
Why would you conflate "useful" with "used for writing complex 
programs"?


Anyway, there are many other examples, but less known.

Wirth's Pascal had the same problem. He invented an elegant, 
simple, consistent, and useless language. The usable Pascal 
systems all had a boatload of dirty, incompatible extensions.


I am not sure if Pascal is elegant, but it most certainly is 
useful. So I don't think I agree with your definition of "useful".



What programmers think of as "intuitive" is often a collection 
of special cases.


I think I would need examples to understand what you mean here.

Card on fire

[Andrei Alexandrescu via Digitalmars-d]

Got a text from Walter - his famous fanless graphics card caught fire 
along with the motherboard. He'll be outta commission for a few days. -- 
Andrei

Re: Code coverage in Phobos

[Seb via Digitalmars-d]

On Wednesday, 25 May 2016 at 02:34:44 UTC, Seb wrote:

On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote:
Okay I see that for the long run we need a better way to 
handle the testing infrastructure :/


Actually the idea of achieving "100% coverage" is that we test 
every line at least once and don't let this testing by done by 
users.

So to refresh the discussion - there were two general ideas

1) Find "bad", "dangerous" modules, e.g.

/xml.d 64%
/zlib.d 60%
/experimental/allocator/typed.d 54%
/experimental/allocator/building_blocks/segregator.d 50%
/experimental/allocator/building_blocks/bucketizer.d 48%
/encoding.d 66%
/container/binaryheap.d 59%
/digest/digest.d 72%

2) Increase coverage for generic, platform-independent modules 
like std.algorithm to 100%


I know it's a lot of work, but shouldn't that make our jobs us 
maintainers easier (=catch the bugs before you have to fix 
them?). Therefore I am bumping this ;-)


Just a quick follow-up on this. I finally managed to work a bit 
on the export to Codecov.io - it's pretty neat as it will warn 
reviewers if the coverage decreases due to changes in a PR.
Moreover according to Codecov.io, Phobos currently has an overall 
coverage of 88.15% (the actual coverage is a bit higher, because 
I had to disable a few tests for Travis and missing, "uncovered" 
lines are also reported for e.g. deprecated lines).


So if someone wants to improve not well-tested modules, at [1] is 
a list of all modules in Phobos with their coverage. Some 
highlights include:


regex: 51%
encoding.d: 62%
mathspecial: 57%
mmfile: 61%
process: 69%
socket: 66%
zlib: 60%

Hopefully in a few days this will be part of Phobos (see [2] for 
details) and thus automatically updated ;-)


[1] 
https://codecov.io/gh/wilzbach/phobos/tree/5fc9eb90076101c0266fb3491ac68527d3520fba/std

[2] https://github.com/dlang/phobos/pull/4587

Re: Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

On 7/9/16 6:58 PM, Andrew Godfrey wrote:

On Saturday, 9 July 2016 at 16:38:02 UTC, Max Samukha wrote:

On Saturday, 9 July 2016 at 14:58:55 UTC, Andrew Godfrey wrote:

On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote:

On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote:




This is a tangent from the subject of this thread, but: No, that just
says how it is implemented, not what it means / intends. See "the 7
stages of naming", here:
http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/

(That resource is talking about identifier naming, not keywords. But
it applies anyway.)


You have a point, but the name is still not 'just bonkers', all things
considered. Metonymy is justified in many cases, and I think this is
one of them. What better name would you propose?


First, I'm not proposing a change to existing keywords, I'm using
existing examples to talk about future language changes. Second, I had
to look up "metonymy" in Wikipedia. Using its example: Suppose
"Hollywood" referred to both the LA movie industry and, say, the jewelry
industry; that's roughly equivalent to the pattern I'm talking about.


Way ahead of ya. The average English noun has 7.8 meanings, and the 
average verb has 12.



Others in this thread have suggested alternatives, many of those have
things to criticize, but I would prefer something cryptic over something
that has multiple subtly-different meanings in the language.
I'm drawn to "#if", except people might end up thinking D has a macro
preprocessor. "ifct" seems fine except I'm not sure everyone would agree
how to pronounce it. Compile-time context seems significant enough that
maybe it warrants punctuation, like "*if" or "$if".


No. As an aside I see your point but "static if" is the worst example to 
support it, by a mile.



I especially want to establish: If we were adding a new feature as
significant as "static if", and we decided a keyword was better than
punctuation, could we stomach the cost of making a new keyword, or would
we shoehorn it either into one of the existing keywords unused in that
context, or start talking about using attributes? I have a lot of
experience with backward-compatibility but I still don't understand the
reticence to introduce new keywords (assuming a freely available
migration tool).


It just depends. There is no rigid strategy here. Worrying about the 
hypothetical possibility seems unnecessary.



Andrei

Re: UB in D

[Andrei Alexandrescu via Digitalmars-d]

On 7/9/16 7:44 PM, H. S. Teoh via Digitalmars-d wrote:

On Sat, Jul 09, 2016 at 07:17:59PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:

On 07/09/2016 06:36 PM, Timon Gehr wrote:

Undefined behaviour means the language semantics don't define a
successor state for a computation that has not terminated. Do you
agree with that definition? If not, what /is/ UB in D, and why is it
called UB?


Yah, I was joking with Walter that effectively the moment you define
undefined behavior it's not undefined any longer :o). It happens to
the best of us. I think we're all aligned here.

There's some interesting interaction here. Consider:

int fun(int x)
{
int[10] y;
...
return ++y[9 >> x];
}

Now, under the "shift by negative numbers is undefined" rule, the
compiler is free to eliminate the bounds check from the indexing
because it's always within bounds for all defined programs. If it
isn't, memory corruption may ensue. However, if the compiler says
"shift by negative numbers is implementation-specified", the the
compiler cannot portably eliminate the bounds check.


I find this rather disturbing, actually.  There is a fine line between
taking advantage of assert's to elide stuff that the programmer promises
will not happen, and eliding something that's defined to be UB and
thereby resulting in memory corruption.


Nah, this is cut and dried. You should just continue being nicely 
turbed. "Shifting by a negative integer has undefined behavior" is what 
it is. Now I'm not saying it's good to define it that way, just that if 
it's defined that way then these are the consequences.



In the above example, I'd be OK with the compiler eliding the bounds
check if there an assert(x >= 0) either in the function body or in the
in-contract.  Having the compiler elide the bounds check without any
assert or any other indication that the programmer has made assurances
that UB won't occur is very scary to me, as plain ole carelessness can
easily lead to exploitable security holes.  I hope D doesn't become an
example of this kind of security hole.


Yeah, we'd ideally like very little UB and no UB in safe code. I think 
we should define shift with out-of-bounds values as "implementation 
specified".



At the very least, I'd expect the compiler to warn that the function
argument may cause UB, and suggest that an in-contract or assert be
added.


You should expect the compiler to do what the language definition 
prescribes.



On a more technical note, I think eliding the bounds check on the
grounds that shifting by negative x is UB is based on a fallacy.


No.


Eliding
a bounds check should only be done when the compiler has the assurance
that the bounds check is not needed. Just because a particular construct
is UB does not meet this condition, because, being UB, there is no way
to tell if the bounds check is needed or not, therefore the correct
behaviour IMO is to leave the bounds check in. The elision should only
happen if the compiler is assured that it's actually not needed.

To elide simply because negative x is UB basically amounts to saying
"the programmer ought to know better than writing UB code, so therefore
let's just assume that the programmer never makes a mistake and barge
ahead fearlessly FTW!". We all know where blind trust in programmer
reliability leads: security holes galore because humans make mistakes.
Assuming humans don't make mistakes, which is what this kind of
exploitation of UB essentially boils down to, leads to madness.


You're overthinking this. Undefined is undefined. We're done here.


Andrei

Re: D is crap

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 9 July 2016 at 11:27:13 UTC, ketmar wrote:
and with refcounting i have to *explicitly* mark all the code 
as "no refcounting here", or accept refcounting overhead for 
nothing.


That would be automatic reference counting ;-)... Reference 
counting is ok for shared ownership, but in most cases overkill. 
Garbage collection is also useful in some settings, e.g. in some 
types of graph manipulation. Where things go wrong for D is to 
use primitive global garbage collection. It would have worked out 
ok if it provided only primitive local garbage collection.


So what D needs is:

1. local garbage collection (for a single fiber or a facade to a 
graph).


2. solid global ownership management (for both resources and 
memory).


Most newbies can then happily write single-threaded code as 
usual. More advanced programmers need to deal with shared 
ownership. Which they might have to do anyway, since garbage 
collection does not handle resources.

Re: D is crap

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 9 July 2016 at 11:10:22 UTC, bachmeier wrote:

On Saturday, 9 July 2016 at 08:06:54 UTC, ketmar wrote:
On Saturday, 9 July 2016 at 07:52:57 UTC, Ola Fosheim Grøstad 
wrote:

removed the GC

...

replaced it with automatic reference counting.


you *do* know that refcounting *is* GC, do you? ;-)


And that's a very important point, because the choice of RC vs 
other types of GC ignores the fact that they're both GC, and 
old school programmers didn't want anything to do with a 
"feature" that would slow down their code. RC would have been 
an even worse choice when D started because it is [claimed to 
be] slower than other types of GC.


No, manual reference counting is not particularly slow. Automatic 
reference counting is also not considered to be slower than GC.


Reference counting is not capable of catching cyclic reference, 
which is why garbage collection is considered to be a more 
general solution to the problem.


This is pretty much 101 memory management.

Re: D is crap

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 9 July 2016 at 08:06:54 UTC, ketmar wrote:
On Saturday, 9 July 2016 at 07:52:57 UTC, Ola Fosheim Grøstad 
wrote:

removed the GC

...

replaced it with automatic reference counting.


you *do* know that refcounting *is* GC, do you? ;-)


Reference counting is a technique for collecting garbage, but the 
term «garbage collection» is typically used for techniques that 
catch cycles by tracing down chains of pointers:


https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Tracing_garbage_collectors

Re: UB in D

[Observer via Digitalmars-d]

On Saturday, 9 July 2016 at 23:44:07 UTC, H. S. Teoh wrote:
On a more technical note, I think eliding the bounds check on 
the grounds that shifting by negative x is UB is based on a 
fallacy. Eliding a bounds check should only be done when the 
compiler has the assurance that the bounds check is not needed. 
Just because a particular construct is UB does not meet this 
condition, because, being UB, there is no way to tell if the 
bounds check is needed or not, therefore the correct behaviour 
IMO is to leave the bounds check in. The elision should only 
happen if the compiler is assured that it's actually not needed.


To elide simply because negative x is UB basically amounts to 
saying "the programmer ought to know better than writing UB 
code, so therefore let's just assume that the programmer never 
makes a mistake and barge ahead fearlessly FTW!". We all know 
where blind trust in programmer reliability leads: security 
holes galore because humans make mistakes. Assuming humans 
don't make mistakes, which is what this kind of exploitation of 
UB essentially boils down to, leads to madness.


There is also a huge practical benefit in leaving such checks
in the code.  I've worked a lot in Perl over the last decade,
and one soon finds that it has great error-checking sprinkled
throughout the implementation.  Based on that experience, I can
tell you it's tremendously helpful for development efforts if
unexpected problems are detected immediately when they occur,
as opposed to forcing the programmer to debug based on the wild
particles left over after an atom-smashing experiment.

Re: Vision document for H2 2016

[Chris Wright via Digitalmars-d-announce]

On Sat, 09 Jul 2016 19:17:31 +, Eugene wrote:

> On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote:
>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
> 
> is it possible to make a modular D language(and a compiler), so one just
> could release new features of the language without releasing a new
> version of a compiler(ldc, etc.), and these features would be just
> extensions of the compilers?

That would be kind of terrible by default.

What ensures that two different modules are compatible? Nothing, by 
default. What happens if you try including two incompatible compiler 
modules in one project? Presumably an error. What if I try to depend on 
two libraries that have incompatible compiler modules? I can't.

So it's a lot of work and would just fragment the language.

[Issue 16259] New: entropy in std.numeric fails in release unittest

[via Digitalmars-d-bugs]

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

  Issue ID: 16259
   Summary: entropy in std.numeric fails in release unittest
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Just run 

```
make std.numeric.test
```

in an up-to-date Phobos clone, it will fail due to entropy returning -nan.

Funnily adding `writeln(e)` in the foreach solves the problem.

--

Re: UB in D

[H. S. Teoh via Digitalmars-d]

On Sat, Jul 09, 2016 at 07:17:59PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 07/09/2016 06:36 PM, Timon Gehr wrote:
> > Undefined behaviour means the language semantics don't define a
> > successor state for a computation that has not terminated. Do you
> > agree with that definition? If not, what /is/ UB in D, and why is it
> > called UB?
> 
> Yah, I was joking with Walter that effectively the moment you define
> undefined behavior it's not undefined any longer :o). It happens to
> the best of us. I think we're all aligned here.
> 
> There's some interesting interaction here. Consider:
> 
> int fun(int x)
> {
> int[10] y;
> ...
> return ++y[9 >> x];
> }
> 
> Now, under the "shift by negative numbers is undefined" rule, the
> compiler is free to eliminate the bounds check from the indexing
> because it's always within bounds for all defined programs. If it
> isn't, memory corruption may ensue. However, if the compiler says
> "shift by negative numbers is implementation-specified", the the
> compiler cannot portably eliminate the bounds check.

I find this rather disturbing, actually.  There is a fine line between
taking advantage of assert's to elide stuff that the programmer promises
will not happen, and eliding something that's defined to be UB and
thereby resulting in memory corruption.

In the above example, I'd be OK with the compiler eliding the bounds
check if there an assert(x >= 0) either in the function body or in the
in-contract.  Having the compiler elide the bounds check without any
assert or any other indication that the programmer has made assurances
that UB won't occur is very scary to me, as plain ole carelessness can
easily lead to exploitable security holes.  I hope D doesn't become an
example of this kind of security hole.

At the very least, I'd expect the compiler to warn that the function
argument may cause UB, and suggest that an in-contract or assert be
added.

On a more technical note, I think eliding the bounds check on the
grounds that shifting by negative x is UB is based on a fallacy. Eliding
a bounds check should only be done when the compiler has the assurance
that the bounds check is not needed. Just because a particular construct
is UB does not meet this condition, because, being UB, there is no way
to tell if the bounds check is needed or not, therefore the correct
behaviour IMO is to leave the bounds check in. The elision should only
happen if the compiler is assured that it's actually not needed.

To elide simply because negative x is UB basically amounts to saying
"the programmer ought to know better than writing UB code, so therefore
let's just assume that the programmer never makes a mistake and barge
ahead fearlessly FTW!". We all know where blind trust in programmer
reliability leads: security holes galore because humans make mistakes.
Assuming humans don't make mistakes, which is what this kind of
exploitation of UB essentially boils down to, leads to madness.


> It's a nice example illustrating how things that seem to have nothing
> with memory corruption do effect it.
[...]


T

-- 
Stop staring at me like that! It's offens... no, you'll hurt your eyes!

Re: UB in D

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2016 06:36 PM, Timon Gehr wrote:

Undefined behaviour means the language semantics don't define a
successor state for a computation that has not terminated. Do you agree
with that definition? If not, what /is/ UB in D, and why is it called UB?


Yah, I was joking with Walter that effectively the moment you define 
undefined behavior it's not undefined any longer :o). It happens to the 
best of us. I think we're all aligned here.


There's some interesting interaction here. Consider:

int fun(int x)
{
int[10] y;
...
return ++y[9 >> x];
}

Now, under the "shift by negative numbers is undefined" rule, the 
compiler is free to eliminate the bounds check from the indexing because 
it's always within bounds for all defined programs. If it isn't, memory 
corruption may ensue. However, if the compiler says "shift by negative 
numbers is implementation-specified", the the compiler cannot portably 
eliminate the bounds check.


It's a nice example illustrating how things that seem to have nothing 
with memory corruption do effect it.



Andrei

Re: Go's march to low-latency GC

[ZombineDev via Digitalmars-d]

On Saturday, 9 July 2016 at 21:25:34 UTC, Dejan Lekic wrote:
On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu 
wrote:
I wish we could amass the experts able to make similar things 
happen for us.


I humbly believe it is not just about amassing experts, but 
also making it easy to do experiments. Phobos/druntime should 
provide set of APIs for literally everything so people can do 
their own implementations of ANY standard library module(s). I 
wish D offered module interfaces the same way Modula-3 did...


To work on new GC in D one needs to remove the old one, and 
replace it with his/her new implementation, while with 
competition it is more/less implementation of few interfaces, 
and instructing compiler to use the new GC...


https://github.com/dlang/druntime/blob/master/src/gc/gcinterface.d
https://github.com/dlang/druntime/blob/master/src/gc/impl/manual/gc.d

What else do you need to start working on a new GC implementation?

Re: Go's march to low-latency GC

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2016 03:42 PM, Martin Nowak wrote:

We sort of have an agreement that we don't want to pay 5% for write
barriers, so the common algorithmic GC improvements aren't available for
us.


Yah, I was thinking in a more general sense. Plenty of improvements of 
all kinds are within reach. -- Andrei

Re: Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

On Saturday, 9 July 2016 at 16:38:02 UTC, Max Samukha wrote:

On Saturday, 9 July 2016 at 14:58:55 UTC, Andrew Godfrey wrote:

On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote:
On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey 
wrote:




This is a tangent from the subject of this thread, but: No, 
that just says how it is implemented, not what it means / 
intends. See "the 7 stages of naming", here: 
http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/


(That resource is talking about identifier naming, not 
keywords. But it applies anyway.)


You have a point, but the name is still not 'just bonkers', all 
things considered. Metonymy is justified in many cases, and I 
think this is one of them. What better name would you propose?


First, I'm not proposing a change to existing keywords, I'm using 
existing examples to talk about future language changes. Second, 
I had to look up "metonymy" in Wikipedia. Using its example: 
Suppose "Hollywood" referred to both the LA movie industry and, 
say, the jewelry industry; that's roughly equivalent to the 
pattern I'm talking about.


Others in this thread have suggested alternatives, many of those 
have things to criticize, but I would prefer something cryptic 
over something that has multiple subtly-different meanings in the 
language.
I'm drawn to "#if", except people might end up thinking D has a 
macro preprocessor. "ifct" seems fine except I'm not sure 
everyone would agree how to pronounce it. Compile-time context 
seems significant enough that maybe it warrants punctuation, like 
"*if" or "$if".


I especially want to establish: If we were adding a new feature 
as significant as "static if", and we decided a keyword was 
better than punctuation, could we stomach the cost of making a 
new keyword, or would we shoehorn it either into one of the 
existing keywords unused in that context, or start talking about 
using attributes? I have a lot of experience with 
backward-compatibility but I still don't understand the reticence 
to introduce new keywords (assuming a freely available migration 
tool).

Re: UB in D

[Timon Gehr via Digitalmars-d]

On 10.07.2016 00:36, Timon Gehr wrote:

the language semantics don't


*doesn't

UB in D

[Timon Gehr via Digitalmars-d]

On 09.07.2016 02:26, Walter Bright wrote:

On 7/8/2016 2:33 PM, Timon Gehr wrote:

On 08.07.2016 21:26, Andrei Alexandrescu wrote:

Where is the reference to Walter's promotion of UB in @safe code?


Only found this, but IIRC, there was another discussion:

http://www.digitalmars.com/d/archives/digitalmars/D/C_compiler_vs_D_compiler_272670.html#N272689




I don't agree with the notion that all UB's can lead to memory
corruption. deadalix's hypothetical fails because "proving it always
passes" cannot be done at the same time as "remove this code path
because it is undefined".
...


It's not the same branch. The code path that is removed ensures that the 
other branch always passes. Anyway, deadalnix was just illustrating how 
a compiler might introduce memory corruption in practice. The 
specification should not /allow/ the compiler to do so in the first 
place. @safe is checked in the front end and UB is exploited by the back 
end. The front end needs to be independent of the back end. Using the 
standard definitions of terms, any UB that makes it into the back end is 
allowed to introduce memory corruption -- the front end cannot know, so 
how can it verify it does not happen?



I don't agree with the interpretation of UB in C++ that some C++
compiler authors do ...


Undefined behaviour means the language semantics don't define a 
successor state for a computation that has not terminated. Do you agree 
with that definition? If not, what /is/ UB in D, and why is it called UB?

Re: Announcing new DIP handling process

[ZombineDev via Digitalmars-d-announce]

On Saturday, 9 July 2016 at 21:21:54 UTC, Dicebot wrote:

On 07/09/2016 09:11 PM, ZombineDev wrote:
Can the new DIP process be used to evaluate library proposals? 
That way a high level design could be fleshed out and approved 
before the contributor goes too far with implementing a design 
which would be rejected.


It is quite hard. To reasonably evaluate library proposal one 
has to have at least proof of concept implementation showing 
intended API. It isn't easy to fit into abstract DIP format.


It depends on the domain and scope of the proposal. See for 
example the C++17 file system API: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r0.html#class-path. I think you'll agree that such a proposal can easily be evaluated solely on its interface, without any need to look at the implementation.


In other domains, such as algorithms, metaprogramming and 
concurrency / parallelism a proof of concept is much more needed.


I think the main question is: Is this design feasible? If there's 
any doubt, a proof of concept should be required.


I can't advise much on this part because I have been trying to 
stay away from Phobos affairs for a long time and don't know 
existing status quo about it.


The status quo is that all larger library additions should be 
approved by Walter or Andrei and new modules should go through 
the review process http://wiki.dlang.org/Review/Process. What I 
currently find missing in the review process is a way to get a 
consensus on the high-level design. If a larger design issue is 
brought up during the review process it may require a significant 
rewrite which is a waste of the contributor's time and can be 
very demotivating.

Re: Vision for the D language - stabilizing complexity?

[Timon Gehr via Digitalmars-d]

On 09.07.2016 06:39, Andrew Godfrey wrote:

On Friday, 8 July 2016 at 21:23:24 UTC, Timon Gehr wrote:

On 08.07.2016 04:25, Andrew Godfrey wrote:


Another example is "return" used for monads in eg Haskell - even if it
only has one meaning in Haskell, it is too mixed up with a different
meaning in other common languages. D's "static if" - which is a killer
feature if I ignore the keyword - gives me a similar feeling (though
it's much less egregious than "return" in monads).


'return' in Haskell is perfectly fine.


This (long) talk does a good job of explaining the problem with using
the name 'return' in monads.

https://www.infoq.com/presentations/functional-pros-cons#downloadPdf
...


The reason you linked to this (long) talk instead of a more digestible 
source is that the presenter manages to bring across his flawed 
argumentation in a way that is charismatic enough to fool a biased 
audience.


It's a reasonable name. 'return' creates a computation that returns the 
given value. This is a different corner in language design space, why 
should C constrain Haskell's design in any way?



Others have said it shorter.


Thanks for providing the links to that material.


I took this example because it crosses
languages. Of course we can't avoid clashing with other languages, there
are only so many keywords to use. But there's definitely a principle
here worth considering, that is if you care about D adoption.
...


I was complaining about the cheap shot at Haskell. This has become way 
too fashionable.



C# vs C++ have an example of a keyword clash too ("volatile" I think?)



That's a better example.

[Issue 16188] [REG2.069] ICE on invalid code

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/8fbedf504bed737241f734f7c8883693ba069472
fix Issue 16188 - [REG2.069] ICE on invalid code

https://github.com/dlang/dmd/commit/920e870e848e7668a15219cb004e422e25448d3e
removed change in declaration.d unrelated to Issue 16188

- I assume it was an attempt at showing the correct error
  message during opDispatch semantics (by rerunning semantic).
  But as we still get the wrong error message and this change
  isn't necessary to fix 16188, we better not merge it into stable.

https://github.com/dlang/dmd/commit/b3c0283c4b2acbc24919c9dfdb0f68a7ba1f2bfb
Merge pull request #5927 from MartinNowak/fix16188

fix Issue 16188 - [REG2.069] ICE on invalid code

--

Re: Probably a real simple compile-time reflection question?

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

On Saturday, 9 July 2016 at 21:12:24 UTC, WhatMeWorry wrote:

foreach( i, str; myClassMembers)


What are you doing to get myClassMembers?

If it is __traits(allMembers), it just gives you the *names* of 
the members. To get the actual thing, you then do 
__traits(getMember, object, str) and can check the type of that.


Also, is there a way to get __traits(allMembers  to work 
recursively?  Say, with struct containing structs.


You can always just call it recursively once you get the member :)

[Issue 16188] [REG2.069] ICE on invalid code

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Go's march to low-latency GC

[Dejan Lekic via Digitalmars-d]

On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu 
wrote:
I wish we could amass the experts able to make similar things 
happen for us.


I humbly believe it is not just about amassing experts, but also 
making it easy to do experiments. Phobos/druntime should provide 
set of APIs for literally everything so people can do their own 
implementations of ANY standard library module(s). I wish D 
offered module interfaces the same way Modula-3 did...


To work on new GC in D one needs to remove the old one, and 
replace it with his/her new implementation, while with 
competition it is more/less implementation of few interfaces, and 
instructing compiler to use the new GC...

Re: Announcing new DIP handling process

[Dicebot via Digitalmars-d-announce]

On 07/09/2016 09:11 PM, ZombineDev wrote:
> Can the new DIP process be used to evaluate library proposals? That way
> a high level design could be fleshed out and approved before the
> contributor goes too far with implementing a design which would be
> rejected.

It is quite hard. To reasonably evaluate library proposal one has to
have at least proof of concept implementation showing intended API. It
isn't easy to fit into abstract DIP format.

I can't advise much on this part because I have been trying to stay away
from Phobos affairs for a long time and don't know existing status quo
about it.

Probably a real simple compile-time reflection question?

[WhatMeWorry via Digitalmars-d-learn]

class C
{
this(){ _i = 0; _j = 0; }
void setVar(int i) { _i = i; }
int getVar() { return _i; }
int _i;
int _j;
}

writeln("C");
foreach( i, str; myClassMembers)
{
writeln("member ", i, " = ", str);
TypeInfo ti = typeid(str);
writeln("type id is ", ti);
writeln("type is ", typeof(str).stringof);
}


C
member 0 = __ctor
type id is immutable(char)[]
type is string
member 1 = _i
type id is immutable(char)[]
type is string
member 2 = setVar
type id is immutable(char)[]
type is string
member 3 = getVar
type id is immutable(char)[]
type is string
 . . .
the same all the way through the class

I'm trying to get at least the type int for the _i member?  Also, 
is there a way to get __traits(allMembers  to work recursively?  
Say, with struct containing structs.


Thanks,
kyle

Re: Accessing contents of associative arrays in an optimal way

[phant0m via Digitalmars-d-learn]

Thank you!

Re: Accessing contents of associative arrays in an optimal way

[ag0aep6g via Digitalmars-d-learn]

On 07/09/2016 10:32 PM, phant0m wrote:

As far as I know, AA implemented as a hashtable. So, will there be two
searches performed (one search for each line)?
records[3].value = 10;
records[3].name = "name";


Yup. A good optimizer may be able to eliminate one, but conceptually 
there are two lookups.



How can I access elements of this AA by a "reference"? In C++ I can use
reference to an element of the map:
Foo& foo = records.find(3).second;
foo.value = 10;
foo.name = "name";


You can take the address of `records[3]`:


Foo* foo = [3];
foo.value = 10;
foo.name = "name";


If `records[3]` may be not set, you can use `3 in records` to get a 
pointer to the value or null if the key isn't set:



Foo* foo = 3 in records;
if (foo is null) {records[0] = Foo.init; foo = 3 in records;}
foo.value = 10;
foo.name = "name";

Re: Singleton Pattern

[Ali Çehreli via Digitalmars-d-learn]

On 07/09/2016 01:35 PM, Suliman wrote:
> On Thursday, 5 January 2012 at 22:53:12 UTC, Ali Çehreli wrote:
>> On 01/05/2012 02:15 PM, asm wrote:
>>> how can i implementing the singleton pattern in D?
>>
>> Is singleton still alive? ;)

I'm glad I was alive in 2012. :o)

>> An idea is to instantiate the object in the module's static this().
>>
>> Ali
>
> Yeah, same question, what difference between singleton and `static 
this()`?


I'm now aware of the difference between 'static this()' and 'shared 
static this()'.:


shared static this(): Executed once for the whole program

static this(): Executed per thread

Ali

Re: Accessing contents of associative arrays in an optimal way

[Ali Çehreli via Digitalmars-d-learn]

On 07/09/2016 01:32 PM, phant0m wrote:
> Suppose I have AA of structures:
>
> struct Foo {
>  int value;
>  string name;
> }
>
> Foo[int] records;
>
> As far as I know, AA implemented as a hashtable. So, will there be two
> searches performed (one search for each line)?
> records[3].value = 10;
> records[3].name = "name";

Yes, two searches. Although it is slower, it's still O(1). :)

> How can I access elements of this AA by a "reference"?

The 'in' operator returns a pointer to the element:

import std.stdio;

struct Foo {
 int value;
 string name;
}

void main() {
Foo[int] records;
records[3] = Foo(42, "hello");

if (auto record = 3 in records) {
record.value = 10;
record.name = "name";
}

writeln(records);
}

Ali

Re: Singleton Pattern

[Suliman via Digitalmars-d-learn]

On Thursday, 5 January 2012 at 22:53:12 UTC, Ali Çehreli wrote:

On 01/05/2012 02:15 PM, asm wrote:

how can i implementing the singleton pattern in D?


Is singleton still alive? ;)

An idea is to instantiate the object in the module's static 
this().


Ali


Yeah, same question, what difference between singleton and 
`static this()`?

Accessing contents of associative arrays in an optimal way

[phant0m via Digitalmars-d-learn]

Suppose I have AA of structures:

struct Foo {
int value;
string name;
}

Foo[int] records;

As far as I know, AA implemented as a hashtable. So, will there 
be two searches performed (one search for each line)?

records[3].value = 10;
records[3].name = "name";

How can I access elements of this AA by a "reference"? In C++ I 
can use reference to an element of the map:

Foo& foo = records.find(3).second;
foo.value = 10;
foo.name = "name";

I found that in D I can use a "with" keyword to achieve the same 
effect:

with(values[0]) {
value = 10;
name = "name";
}

Is this the only optimal way?

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:

Hi Guys,

I have been looking into the DMD now to see what I can do about 
CTFE.

[  ]
I will post more details as soon as I dive deeper into the code.


I decided to keep a gist updated to represent the current state 
the new engine can handle.


https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e

This is the currentState after approx. 50 hours of work

Re: Go's march to low-latency GC

[Martin Nowak via Digitalmars-d]

On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu 
wrote:

On 7/7/16 6:36 PM, Enamex wrote:

https://news.ycombinator.com/item?id=12042198

^ reposting a link in the right place.


A very nice article and success story. We've had similar 
stories with several products at Facebook. There is of course 
the opposite view - an orders-of-magnitude improvement means 
there was quite a lot of waste just before that.


Exactly, how someone can run a big site with 2 second pauses in 
the GC code is beyond me.


I wish we could amass the experts able to make similar things 
happen for us.


We sort of have an agreement that we don't want to pay 5% for 
write barriers, so the common algorithmic GC improvements aren't 
available for us.
There is still connectivity based GC [¹], which is an interesting 
idea, but AFAIK it hasn't been widely tried.
Maybe someone has an idea for optional write barriers, i.e. zero 
cost if you don't use them. Or we agree that it's worth to have 
different incompatible binaries.


[¹]: https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf

In any case now that we made the GC pluggable we should port the 
forking GC. It has almost no latency at the price of higher peak 
memory usage and throughput, the same trade-offs you have with 
any concurrent mark phase.
Moving the sweeping to background GC threads is sth. we should be 
doing anyhow.


Overall I think we should focus more on good deterministic MM 
alternatives, rather than investing years of engineering into our 
GC, or hoping for silver bullets.

Very interesting slides about Fibers

[Suliman via Digitalmars-d]

Maybe somebody will interesting  
http://twvideo01.ubm-us.net/o1/vault/gdc2015/presentations/Gyrling_Christian_Parallelizing_The_Naughty.pdf

Re: Vision document for H2 2016

[Eugene via Digitalmars-d-announce]

On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu 
wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


is it possible to make a modular D language(and a compiler), so 
one just could release new features of the language without 
releasing a new version of a compiler(ldc, etc.), and these 
features would be just extensions of the compilers?

Re: Go's march to low-latency GC

[bob belcher via Digitalmars-d]

On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu 
wrote:

On 7/7/16 6:36 PM, Enamex wrote:

https://news.ycombinator.com/item?id=12042198

^ reposting a link in the right place.


A very nice article and success story. We've had similar 
stories with several products at Facebook. There is of course 
the opposite view - an orders-of-magnitude improvement means 
there was quite a lot of waste just before that.


I wish we could amass the experts able to make similar things 
happen for us.



Andrei


kickstarter for improve gc :)

Re: Go's march to low-latency GC

[Chris Wright via Digitalmars-d]

On Fri, 08 Jul 2016 22:35:05 +0200, Martin Nowak wrote:

> On 07/08/2016 07:45 AM, ikod wrote:
>> Correct me if I'm wrong, but in D fibers allocate stack statically, so
>> we have to preallocate large stacks.
>> 
>> If yes - can we allocate stack frames on demand from some non-GC area?
> 
> Fiber stacks are just mapped virtual memory pages that the kernel only
> backs with physical memory when they're actually used. So they already
> are allocated on demand.

The downside is that it's difficult to release that memory. On the other 
hand, Go had a lot of problems with its implementation in part because it 
released memory. At some point you start telling users: if you want a 
fiber that does a huge recursion, dispose of it when you're done. It's 
cheap enough to create another fiber later.

Re: Vision for the D language - stabilizing complexity?

[ag0aep6g via Digitalmars-d]

On 07/09/2016 07:09 PM, Seb wrote:

I agree that overloading keywords in different contexts in problematic.
I think every newbie is surprised when he stumbled across the two
different usages of enum (finite, custom lists & CT evaluation),


`enum e = 1;` can be seen as a shorthand for `enum {e = 1}`. Makes 
perfect sense then. Though I wouldn't be surprised if there are actually 
subtle differences between the two.

Re: Announcing new DIP handling process

[ZombineDev via Digitalmars-d-announce]

On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote:
After quite some preliminary discussions and preparations, new 
D Improvement Proposals handling process is finally happenning. 
Please read description and explanation here:


https://github.com/dlang/DIPs

## Rationale

There are two main goals for going this way:

1) Ensure communication between language authors and DIP 
authors, establish better sense of actually contributing as 
opposed to simply throwing ideas into the black box.


2) Improve overall quality of DIP documents to the point where 
language authors can reasonably review them without spending 
too much time on trivialities.


Additional benefit I am hoping for is to have a centralized 
place to subscribe to learn about all coming major changes 
coming to language for those who can't keep up with NG 
regularly.


## Old DIPs

Right now https://github.com/dlang/DIPs repository contains 
archive folder with already implemented proposals imported from 
wiki (please tell me if there are any other already implemented 
DIPs that were not marked as such in wiki).


All authors of existing DIPs who want to keep pursuing the idea 
will have to re-submit them as a pull requests towards new 
repo. This is required so that we can filter abandoned 
proposals and focus on documents that have active authors 
backing them.


## DIP manager

I will act as a DIP manager for the time being. Please note 
that role of DIP manager does not imply any decision power 
regarding DIP approval, it remains an exclusive domain of 
language authors.


Can the new DIP process be used to evaluate library proposals? 
That way a high level design could be fleshed out and approved 
before the contributor goes too far with implementing a design 
which would be rejected.

Re: Go's march to low-latency GC

[Andrei Alexandrescu via Digitalmars-d]

On 7/7/16 6:36 PM, Enamex wrote:

https://news.ycombinator.com/item?id=12042198

^ reposting a link in the right place.


A very nice article and success story. We've had similar stories with 
several products at Facebook. There is of course the opposite view - an 
orders-of-magnitude improvement means there was quite a lot of waste 
just before that.


I wish we could amass the experts able to make similar things happen for us.


Andrei

[Issue 16028] Incorrect cache size returned from core.cpuid

[via Digitalmars-d-bugs]

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

--- Comment #2 from Илья Ярошенко  ---
Replacement for core.cpuid: https://github.com/libmir/cpuid

--

Re: Go's march to low-latency GC

[ikod via Digitalmars-d]

On Saturday, 9 July 2016 at 13:48:41 UTC, Dicebot wrote:

On 07/09/2016 02:48 AM, ikod wrote:

If I made a wrong guess and
ask for too small stack then programm may crash. If I ask for 
too large

stack then I probably waste resources.


Nope, this is exactly the point. You can demand crazy 10 MB of 
stack for each fiber and only the actually used part will be 
allocated by kernel.


Thanks, nice to know.

Re: Vision for the D language - stabilizing complexity?

[Seb via Digitalmars-d]

On Saturday, 9 July 2016 at 16:38:02 UTC, Max Samukha wrote:

On Saturday, 9 July 2016 at 14:58:55 UTC, Andrew Godfrey wrote:

On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote:
On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey 
wrote:




This is a tangent from the subject of this thread, but: No, 
that just says how it is implemented, not what it means / 
intends. See "the 7 stages of naming", here: 
http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/


(That resource is talking about identifier naming, not 
keywords. But it applies anyway.)


You have a point, but the name is still not 'just bonkers', all 
things considered. Metonymy is justified in many cases, and I 
think this is one of them. What better name would you propose?



I agree that overloading keywords in different contexts in 
problematic. I think every newbie is surprised when he stumbled 
across the two different usages of enum (finite, custom lists & 
CT evaluation), but let's focus on the future. Something that's 
worrying me a bit, is that we don't have a clear naming 
convention for Phobos.


There is a good wiki entry that shows the problem [1].
Basically an intuitive name should follow a standard convention, 
s.t. you can "guess" it and the name can also tell more 
information, e.g. is it a lazy operation? (aka returns a range).


`split` and `splitter` are good examples, but then in other 
module you might find (1) adjectives: `transposed`, `indexed` (2) 
prepositions: byUTF, or (3) just nouns: setUnion, 
cartesianProduct, permutations, recurrence.


Disclaimer: This is just a friendly reminder that names are 
important and as they are very hard to change, great care should 
be put on choosing them in the future ;-)


[1] http://wiki.dlang.org/Naming_conventions

Re: Vision for the D language - stabilizing complexity?

[Max Samukha via Digitalmars-d]

On Saturday, 9 July 2016 at 14:58:55 UTC, Andrew Godfrey wrote:

On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote:

On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote:



This is a tangent from the subject of this thread, but: No, 
that just says how it is implemented, not what it means / 
intends. See "the 7 stages of naming", here: 
http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/


(That resource is talking about identifier naming, not 
keywords. But it applies anyway.)


You have a point, but the name is still not 'just bonkers', all 
things considered. Metonymy is justified in many cases, and I 
think this is one of them. What better name would you propose?

Re: Vision document for H2 2016

[Robert M. Münch via Digitalmars-d-announce]

On 2016-07-08 20:46:21 +, Walter Bright said:


On 7/8/2016 6:51 AM, Robert M. Münch wrote:

1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO or CEO on
...


I have yet to find any engineering product in any field that doesn't 
have open issues. A more practical question is does the product deliver 
enough value to make up for its deficiencies.


I totally agree. But often it takes quite some time & experience to 
understand how the open deficiencies impact my context. I have seen to 
many tools where you can reach 80% and than things get hard / 
impossible. IMO a good or bad products is decided on the last 20%...




3. How about a "D Master" online certificate? scrum.org is doing that. You have
...


It's a great idea, do you want to work on it?


I would love to but it's unrealistic within the next 6 months... sorry.

I brought it up as an idea that can be put on the mid / long term 
roadmap, to shape the picture of D in the long run. I think these 
things are important for companies to see / know about before they will 
make a decision. It's a long, very long journey to establish a language 
in the "mainstream"...


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Vision document for H2 2016

[Robert M. Münch via Digitalmars-d-announce]

On 2016-07-08 18:07:39 +, Andrei Alexandrescu said:


On 07/08/2016 09:51 AM, Robert M. Münch wrote:

1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO or
CEO on D I the first thing I ask is: "Are they doing a lot of new stuff?
And if, is this thing / last releasae that bullet proof stable that
there are not annoying open issued?" Any other answer then "yes" would
get my "no" to use D.


This needs to be balanced with the zeroth thing you ask, which is: "how 
does it help us with our work better than the competition?" We're not 
working on many new things, but we do work on things that impact that 
question.


IMO D has a lot to put on the table, and that should work seemlessly. 
So, the elevator-pitch for D is possible. However, it's a personal 
taste what is "better than..." and if helps or not.


My rule of thumb, after many years of experience is, that I'm very 
conservative when it comes to base technology stuff. Less is more, slow 
moving & high quality is better than fast & fancy.




2. Case-Studies: ...


There are some. I'd love to see such.


Are these listed somewhere?



3. How about a "D Master" online certificate? scrum.org is doing that.
... 

Will keep that in mind, although there's some stigma associated with this.


Which? That these things are of low quality?

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: NanoSVG port

[ketmar via Digitalmars-d-announce]

just make sure to download the latest version by the given link 
before you want to try it. ;-)


glad to see that you found it useful

Re: Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

On Friday, 8 July 2016 at 20:11:11 UTC, H. S. Teoh wrote:

But yeah, D *has* overloaded the "static" keyword perhaps a 
little more than it ought to have.  But at the end of the day 
it's just syntax... there are far more pressing issues to worry 
about than syntax at the moment.

T


Okay, so now you are illustrating the *exact* problem I am trying 
to point out with this thread: Without trying to undo the 
mistakes of the past, could we please have a link (in the vision 
doc) to a long-term language-design vision, so that potential 
adopters know what to expect in 5 years or 10 years?
If by then, D will be as unwieldy as C++ is now, then it isn't 
the improvement over C++ that it currently appears to be.


"More pressing issues" is what the current vision doc is about, 
and I'm not suggesting substantial changes to it. Except for the 
time it may take the leadership to write down their long term 
intentions and - possibly as an outcome of that - to resolve 
their differences.


I also think it could increase efficiency in the forums; any 
language proposal which violates the long term vision could be 
referred to that doc instead of clumsily exploring little bits of 
it.

Re: Variadic Tuple of Structs with Mixed Types

[jmh530 via Digitalmars-d-learn]

On Saturday, 9 July 2016 at 05:40:10 UTC, ag0aep6g wrote:



template bar(T, U...)
if (U.length > 1)
{
import std.meta : staticMap;
import std.typecons : Tuple;

alias baz(A) = Tuple!(T, A);
alias V = staticMap!(baz, U);
alias TupleToFoo(T : Tuple!(Types), Types ...) = Foo!Types;
// Alternative TupleToFoo with less complex syntax:
// alias TupleToFoo(T) = Foo!(T.Types);
alias bar = staticMap!(TupleToFoo, V);
}


Or with a more lightweight, custom wrapper:


template bar(T, U...)
if (U.length > 1)
{
import std.meta : staticMap;

template Box(stuff ...) { alias contents = stuff; }

alias baz(A) = Box!(T, A);
alias V = staticMap!(baz, U);
alias BoxToFoo(alias box) = Foo!(box.contents);
alias bar = staticMap!(BoxToFoo, V);
}



I'll give this a try. Thanks.

Re: Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote:

On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote:

Aha! But I don't! It feels intuitive, possibly the best use of 
"static". But that is immaterial, what matters is the sum of 
all meanings of "static" in this language. The "single 
instance per class" meaning of "static" is just bonkers. I've 
had that meaning burned into my brain for a couple of decades, 
from C++. But I don't have to like it!
I could stomach it, though, if that was the only use of the 
keyword. (Or if the other meanings couldn't be used in the 
same contexts).


The name is fine. It comes from 'statically bound/dispatched', 
that is 'resolved at compile time'.


This is a tangent from the subject of this thread, but: No, that 
just says how it is implemented, not what it means / intends. See 
"the 7 stages of naming", here: 
http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/


(That resource is talking about identifier naming, not keywords. 
But it applies anyway.)

[Issue 16258] New: std.net.curl (download) failed

[via Digitalmars-d-bugs]

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

  Issue ID: 16258
   Summary: std.net.curl (download) failed
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: skeli...@yandex.com

Hi, I tried this example in here -
https://dlang.org/phobos/std_net_curl.html#download , but after running gdc
program.d -o program, it spit out this errors.

hello.d:2:9: error: unexpected ( in declarator
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
 ^
hello.d:2:10: error: basic type expected, not "d-lang.appspot.com/testUrl2"
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
  ^
hello.d:2:10: error: found '"d-lang.appspot.com/testUrl2"' when expecting ')'
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
  ^
hello.d:2:39: error: no identifier for declarator download(int)
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
   ^
hello.d:2:39: error: semicolon expected following function declaration
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
   ^
hello.d:2:39: error: Declaration expected, not ','
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
   ^
skelirox@pc:~$ gdc hello.d -o hello
hello.d:2:9: error: unexpected ( in declarator
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
 ^
hello.d:2:10: error: basic type expected, not "d-lang.appspot.com/testUrl2"
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
  ^
hello.d:2:10: error: found '"d-lang.appspot.com/testUrl2"' when expecting ')'
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
  ^
hello.d:2:39: error: no identifier for declarator download(int)
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
   ^
hello.d:2:39: error: semicolon expected following function declaration
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
   ^
hello.d:2:39: error: Declaration expected, not ','
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
   ^
skelirox@pc:~$ gdc-5 hello.d -o hello
hello.d:2:9: error: unexpected ( in declarator
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
 ^
hello.d:2:10: error: basic type expected, not "d-lang.appspot.com/testUrl2"
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
  ^
hello.d:2:10: error: found '"d-lang.appspot.com/testUrl2"' when expecting ')'
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
  ^
hello.d:2:39: error: no identifier for declarator download(int)
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
   ^
hello.d:2:39: error: semicolon expected following function declaration
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");
   ^
hello.d:2:39: error: Declaration expected, not ','
 download("d-lang.appspot.com/testUrl2", "/tmp/downloaded-http-file");


I don't think the error is because the link.

--

Re: std.experimental.randomized_unittest_benchmark is ready for comments

[Seb via Digitalmars-d]

On Sunday, 19 June 2016 at 16:15:15 UTC, Robert burner Schadek 
wrote:

Thank you Seb for taking over the review management.

Some additional feature for the proposed module is.

* Simple way to create test data for user defined types
* Benchmark data is stored into csv file for comparing the 
benchmark results between runs
* Standalone tool to create gnuplot graphs from generated csv 
benchmark files


The long time vision (2+ years) is to have a benchmark for 
every function in phobos and have the resulting graph on the 
Dlang webpage (merged PRs -> webpage). So we can track the 
performance of everything.


Just a short ping at the general public to give their comments & 
feedback ;-)

Re: Why is ElementType!(char[]) == dchar?

[H. S. Teoh via Digitalmars-d-learn]

On Sat, Jul 09, 2016 at 11:57:36PM +1200, rikki cattermole via 
Digitalmars-d-learn wrote:
> On 09/07/2016 11:46 PM, Tofu Ninja wrote:
> > On Saturday, 9 July 2016 at 11:35:24 UTC, Tofu Ninja wrote:
> > > On Saturday, 9 July 2016 at 11:29:18 UTC, ketmar wrote:
> > > > On Saturday, 9 July 2016 at 11:24:01 UTC, Tofu Ninja wrote:
> > > > > Seems pretty silly to me...
> > > > 
> > > > due to universally beloved autodecoding.
> > > 
> > > Hmmm... I dont really know the history of autodecoding, why was that
> > > supposed to be a good idea?
> > 
> > Hmm, well I fixed my problem that originally prompted me to ask this by
> > using ubyte instead of char. Still kinda curious on the whole
> > autodecoding thing and why it's even a thing.
> 
> In this case, its not aut odecoding.
[...]

Actually, this is exactly what autodecoding is about. The .front of
string and wstring are always decoded to dchar.  A long time ago when
this was first written it was deemed a good idea, but over the years
experience has shown that it was a bad design (though some may argue
this point). Nowadays we're trying to steer away from it, but due to the
large amount of Phobos code that depends on it, it's probably here to
stay for the next little while yet.  (My hope is that eventually it will
become irrelevant and deprecable... but we're far from that right now.)


T

-- 
What doesn't kill me makes me stranger.

Re: Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2016 12:32 AM, Andrew Godfrey wrote:

On Friday, 8 July 2016 at 18:16:03 UTC, Andrei Alexandrescu wrote:

On 07/07/2016 10:25 PM, Andrew Godfrey wrote:

D's "static if" - which is a killer feature if I ignore the keyword -
gives me a similar feeling (though it's much less egregious than
"return" in monads). "static" is a terribly non-descriptive name because
there are so many senses in which a thing could be "dynamic".


You may well be literally the only person on Earth who dislikes the
use of "static" in "static if". -- Andrei


Aha! But I don't!


Great to hear you don't dislike it! :o) -- Andrei

Re: Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2016 04:57 AM, Observer wrote:


Also, Andrei, if you're listening, I've spotted another TDPL errata.
On page 459, the Index entry for "static, obligatory joke about overuse
of" lists page 345, but in fact the joke is in the footnote at the bottom
of page 68.


Added to http://erdani.com/tdpl/errata. Thanks! -- Andrei

Re: Announcing new DIP handling process

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/09/2016 09:11 AM, Seb wrote:

On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote:

After quite some preliminary discussions and preparations, new D
Improvement Proposals handling process is finally happenning. Please
read description and explanation here:

[...]


Sweet! A bit of noise:

https://www.reddit.com/r/programming/comments/4s08h4/the_d_language_has_a_new_dip_d_improvement/

https://news.ycombinator.com/item?id=12061181


Thanks! Don't forget hackerne.ws looks at referrer and automatically 
bans posts that come from an explicit link (like the one above). What 
you need to do is post and then let people know what time the post was. 
Then they can see the post by going to the "new" section and look for 
posts around that time. -- Andrei

Re: Go's march to low-latency GC

[Dicebot via Digitalmars-d]

On 07/09/2016 02:48 AM, ikod wrote:
> If I made a wrong guess and
> ask for too small stack then programm may crash. If I ask for too large
> stack then I probably waste resources.

Nope, this is exactly the point. You can demand crazy 10 MB of stack for
each fiber and only the actually used part will be allocated by kernel.

Re: Announcing new DIP handling process

[Seb via Digitalmars-d-announce]

On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote:
After quite some preliminary discussions and preparations, new 
D Improvement Proposals handling process is finally happenning. 
Please read description and explanation here:


[...]


Sweet! A bit of noise:

https://www.reddit.com/r/programming/comments/4s08h4/the_d_language_has_a_new_dip_d_improvement/
https://news.ycombinator.com/item?id=12061181

Re: NanoSVG port

[Dmitry via Digitalmars-d-announce]

On Saturday, 9 July 2016 at 11:06:34 UTC, ketmar wrote:
i also made NanoSVG[1] port[2]: simple SVG parser and 
rasterizer. it is using `malloc()` to allocate memory, but 
otherwise was rewritten to use `const(char)[]` input for svg, 
and do not use `sscanf()` from libc.


the port lives in NanoVG package, but it is actually completely 
independent.



[1] https://github.com/memononen/nanosvg
[2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/nanovg/svg.d


I will definitely try it (but not very soon).
Thank you!

Announcing new DIP handling process

[Dicebot via Digitalmars-d-announce]

After quite some preliminary discussions and preparations, new D
Improvement Proposals handling process is finally happenning. Please
read description and explanation here:

https://github.com/dlang/DIPs

## Rationale

There are two main goals for going this way:

1) Ensure communication between language authors and DIP authors,
establish better sense of actually contributing as opposed to simply
throwing ideas into the black box.

2) Improve overall quality of DIP documents to the point where language
authors can reasonably review them without spending too much time on
trivialities.

Additional benefit I am hoping for is to have a centralized place to
subscribe to learn about all coming major changes coming to language for
those who can't keep up with NG regularly.

## Old DIPs

Right now https://github.com/dlang/DIPs repository contains archive
folder with already implemented proposals imported from wiki (please
tell me if there are any other already implemented DIPs that were not
marked as such in wiki).

All authors of existing DIPs who want to keep pursuing the idea will
have to re-submit them as a pull requests towards new repo. This is
required so that we can filter abandoned proposals and focus on
documents that have active authors backing them.

## DIP manager

I will act as a DIP manager for the time being. Please note that role of
DIP manager does not imply any decision power regarding DIP approval, it
remains an exclusive domain of language authors.

Re: Why is ElementType!(char[]) == dchar?

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

On Saturday, 9 July 2016 at 11:57:36 UTC, rikki cattermole wrote:
That implementation is weird in that it returns a dchar instead 
of the raw type. Which is decoding, but it is not auto 
decoding. Auto decoding involves the foreach statement.


You have that backwards. foreach only decodes if you specifically 
ask for it (by specifying wchar or dchar in the statement). 
Phobos does it automatically, whether you like it or not.

Re: Why is ElementType!(char[]) == dchar?

[ketmar via Digitalmars-d-learn]

On Saturday, 9 July 2016 at 11:57:36 UTC, rikki cattermole wrote:

In this case, its not aut odecoding.

ElementType is using std.range : front for array's since they 
do not provide a front method.


That implementation is weird in that it returns a dchar


hello, autodecoding.

Re: Vision for the D language - stabilizing complexity?

[Observer via Digitalmars-d]

On Saturday, 9 July 2016 at 11:49:49 UTC, burjui wrote:
I'm sorry, but these examples are horrible, except maybe 
"constant if", because none give a clue about compile-time and 
they are not even synonyms. ... You didn't even think about it, 
just picked the words from a book.


It's a process.  One comes up with an idea, mulls it over, tries
it out, evaluates, revises.  I'm not saying that any one of these
choices is definitely better.  What I'm saying is that someone
claimed earlier that "static" wasn't a good choice, but gave no
examples of possible alternatives, or how to find one.  The point
is, an attempt to follow a process that often yields good results
for variable naming seems to not give great results in this case,
which I suppose argues for the status quo.

Re: D is crap

[Chris via Digitalmars-d]

On Saturday, 9 July 2016 at 11:10:22 UTC, bachmeier wrote:

On Saturday, 9 July 2016 at 08:06:54 UTC, ketmar wrote:
On Saturday, 9 July 2016 at 07:52:57 UTC, Ola Fosheim Grøstad 
wrote:

removed the GC

...

replaced it with automatic reference counting.


you *do* know that refcounting *is* GC, do you? ;-)


And that's a very important point, because the choice of RC vs 
other types of GC ignores the fact that they're both GC, and 
old school programmers didn't want anything to do with a 
"feature" that would slow down their code. RC would have been 
an even worse choice when D started because it is [claimed to 
be] slower than other types of GC. It's been a long time now, 
but I don't recall many arguments against Java's GC because of 
pauses. The objection was always that it would make the code 
run more slowly.


I remember reading an article by Apple about their GC in 
Objective-C and they said that it was a generational GC and that 
some objects would not be collected at all (if too old), if I 
remember correctly. Apparently it wasn't good enough, but that's 
about 7 years ago, so my memory might have been freed of some 
details :-)

Re: Why is ElementType!(char[]) == dchar?

[Lodovico Giaretta via Digitalmars-d-learn]

On Saturday, 9 July 2016 at 11:46:14 UTC, Tofu Ninja wrote:

On Saturday, 9 July 2016 at 11:35:24 UTC, Tofu Ninja wrote:

On Saturday, 9 July 2016 at 11:29:18 UTC, ketmar wrote:

On Saturday, 9 July 2016 at 11:24:01 UTC, Tofu Ninja wrote:

Seems pretty silly to me...


due to universally beloved autodecoding.


Hmmm... I dont really know the history of autodecoding, why 
was that supposed to be a good idea?


Hmm, well I fixed my problem that originally prompted me to ask 
this by using ubyte instead of char. Still kinda curious on the 
whole autodecoding thing and why it's even a thing.


Another solution is to use ElementEncodingType, which is like 
ElementType but with a special hack for arrays of characters, to 
return the actual type and not the autodecoded one.

Re: Vision for the D language - stabilizing complexity?

[QAston via Digitalmars-d]

On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
All useful computer languages are unprincipled and complex due 
to a number of factors:


1. the underlying computer is unprincipled and complex (well 
known issues with integer and floating point arithmetic)


2. what programmers perceive as logical and intuitive is often 
neither logical nor intuitive to a computer (even Haskell has 
wackadoodle features to cater to illogical programmers)


3. what the language needs to do changes over time - the 
programming world is hardly static


4. new features tend to be added as adaptations of existing 
features (much like how evolution works)


5. new features have to be worked in without excessively 
breaking legacy compatibility


6. no language is conceived of as a whole and then implemented

7. the language designers are idiots and make mistakes


Of course, we try to minimize (7), but 1..6 are inevitable.


Letting consequences of those just happen is like a being a 
sailor and happily going the wrong way when the wind is not 
perfect. There are techniques both from the project management 
point of view and from language design point of view that can be 
applied to minimize and prevent those effects and aren't applied.


So, some examples:

About 6, 3 and 4. There's a thing called the MVP (minimal viable 
product) approach. You implement the minimally useful bare bones 
and leave as much wiggle room as possible for future changes. 
This doesn't need to be applied to the whole language, it can be 
applied per feature as well. Yes, you can't predict the future, 
that's not an excuse for not preparing for it and for possible 
change. When you're happy with the MVP you can accept it and do 
more experimentation with the knowledge you got from doing the 
MVP. See also: agile methodologies.


About 2 and 7. Some positive changes happen here, still listing 
possible solutions won't hurt. Have more peer review. Release 
more often, so people won't be bothered if their feature won't 
make it (it's weird that Andrei worked at facebook, yet he 
doesn't push for faster, less feature heavy releases). Release 
new features under feature gates (like -dip25 and 
std.experimetal), don't stabilize until people provide feedback 
and are happy with the result (yes there's an issue with people 
not testing the feature because of small D adoption - don't 
include the feature for it's own sake if people can't be bothered 
to test it). We're all idiots - so we need to experiment before 
we commit to something.


About 4 and 5. Those are partially combated by the MVP approach 
mentioned earlier- leaving as much as possible flexibility for as 
long as possible, so you can make decisions when you have the 
most information(i.e. as late as possible).


Another way to combat this is to build language from independent 
parts that can be composed together. As an example of this done 
right: concrete code, templating mechanisms and conditional 
compilation are all independent parts of the language that can be 
put together, so the effective number of features is a cross 
product of those 3. Deadalnix gave some examples of that done 
wrong in this thread - as he's implementing a D compiler from 
scratch he can see the unorthogonal parts easily. SDC is probably 
worth looking into. With independent features it's much easier to 
keep the feature set adaptable.


Another language design trick is to look at the whole language 
and try to hit as many birds as possible with as few (but not too 
few) stones as possible. There are numerous cases of problems 
being solved using different means each time a problem comes up. 
Look for a way to merge these categories of solutions into 
something coherent and deprecate the old mess. You don't have to 
drop the old ways, but new users will be glad to have a simpler 
model to learn, as old "special" solutions can be defined in 
terms of the new one. Do you really need pragmas, special 
variables and special constants when you could have nice 
namespaced intrinsics modules defined with existing and 
understood language rules? Do you need alias this when you could 
have opImplicitCast returning ref?


I didn't just make those up, there are languages which do all of 
those and more and they work within the same domain as D.

Re: Why is ElementType!(char[]) == dchar?

[rikki cattermole via Digitalmars-d-learn]

On 09/07/2016 11:46 PM, Tofu Ninja wrote:

On Saturday, 9 July 2016 at 11:35:24 UTC, Tofu Ninja wrote:

On Saturday, 9 July 2016 at 11:29:18 UTC, ketmar wrote:

On Saturday, 9 July 2016 at 11:24:01 UTC, Tofu Ninja wrote:

Seems pretty silly to me...


due to universally beloved autodecoding.


Hmmm... I dont really know the history of autodecoding, why was that
supposed to be a good idea?


Hmm, well I fixed my problem that originally prompted me to ask this by
using ubyte instead of char. Still kinda curious on the whole
autodecoding thing and why it's even a thing.


In this case, its not aut odecoding.

ElementType is using std.range : front for array's since they do not 
provide a front method.


That implementation is weird in that it returns a dchar instead of the 
raw type. Which is decoding, but it is not auto decoding. Auto decoding 
involves the foreach statement. So std.traits : ForeachType if that 
returned dchar then yes that would be because of auto decoding.

Re: Vision for the D language - stabilizing complexity?

[burjui via Digitalmars-d]

On Saturday, 9 July 2016 at 08:57:18 UTC, Observer wrote:

constant if
durable if
persistent if
adamant if
unalterable if
immutable if

Okay, that last one is a joke, considering that we're talking 
about keyword overloading. But the effort did spark some other 
brain cells to fire. So we could have had any of these:


exactly if
strictly if
only if


I'm sorry, but these examples are horrible, except maybe 
"constant if", because none give a clue about compile-time and 
they are not even synonyms. The last three are just plain 
nonsense, especially "strictly if" which implies that ordinary 
"if" is somehow not reliable. You didn't even think about it, 
just picked the words from a book.


"static if" is perfectly fine, if you just try to imagine what in 
"if" could be dynamic, because the only meaningful answer is: 
"The condition". If there is a context where "static" really 
needs to be replaced by a synonym, it's definitely not "static 
if".

Re: Why is ElementType!(char[]) == dchar?

[Tofu Ninja via Digitalmars-d-learn]

On Saturday, 9 July 2016 at 11:35:24 UTC, Tofu Ninja wrote:

On Saturday, 9 July 2016 at 11:29:18 UTC, ketmar wrote:

On Saturday, 9 July 2016 at 11:24:01 UTC, Tofu Ninja wrote:

Seems pretty silly to me...


due to universally beloved autodecoding.


Hmmm... I dont really know the history of autodecoding, why was 
that supposed to be a good idea?


Hmm, well I fixed my problem that originally prompted me to ask 
this by using ubyte instead of char. Still kinda curious on the 
whole autodecoding thing and why it's even a thing.

Re: Vision for the D language - stabilizing complexity?

[Walter Bright via Digitalmars-d]

On 7/9/2016 1:57 AM, Observer wrote:

As for me, the main thing I dislike about static if is that it blends in
visually a bit too well with run-time code segments.  C's #if structure
has its own problems, but I like the distinctiveness.


Ironically, "static if" has entered the C++ lexicon from D.

Re: Why is ElementType!(char[]) == dchar?

[Tofu Ninja via Digitalmars-d-learn]

On Saturday, 9 July 2016 at 11:29:18 UTC, ketmar wrote:

On Saturday, 9 July 2016 at 11:24:01 UTC, Tofu Ninja wrote:

Seems pretty silly to me...


due to universally beloved autodecoding.


Hmmm... I dont really know the history of autodecoding, why was 
that supposed to be a good idea?

Re: D is crap

[ketmar via Digitalmars-d]

On Saturday, 9 July 2016 at 11:10:22 UTC, bachmeier wrote:
p.s. also, it is funny that D's GC is actually *better* if one to 
avoid GC completely, yet people continue to ask for refcounting.


i meat: if i don't want to use GC in D, it is as easy as avoid 
`new` (and delegates with closures). any code that processing 
allocated objects, but never allocates itself doesn't need to be 
changed at all.


and with refcounting i have to *explicitly* mark all the code as 
"no refcounting here", or accept refcounting overhead for nothing.

Re: Why is ElementType!(char[]) == dchar?

[ketmar via Digitalmars-d-learn]

On Saturday, 9 July 2016 at 11:24:01 UTC, Tofu Ninja wrote:

Seems pretty silly to me...


due to universally beloved autodecoding.

Re: Why is ElementType!(char[]) == dchar?

[rikki cattermole via Digitalmars-d-learn]

On 09/07/2016 11:24 PM, Tofu Ninja wrote:

Seems pretty silly to me...


http://dlang.org/phobos/std_range_primitives.html#.front

Re: D is crap

[ketmar via Digitalmars-d]

On Saturday, 9 July 2016 at 11:10:22 UTC, bachmeier wrote:
The objection was always that it would make the code run more 
slowly.


i tend to ignore such persons completely after such a claim: they 
are obviously incompetent as programmers.


i also tend to ignore whole "@nogc" movement: it is just a failed 
marketing strategy, which (sadly) tends to consume alot of 
recources even today.

Why is ElementType!(char[]) == dchar?

[Tofu Ninja via Digitalmars-d-learn]

Seems pretty silly to me...

[Issue 16225] [REG 2.068] Internal error cod1.c 1338 with -O

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 16225] [REG 2.068] Internal error cod1.c 1338 with -O

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/ebbb2c6fb8856afb709bb1b05260df875a3790c4
fix Issue 16225 - [REG 2.068] Internal error cod1.c 1338 with -O

https://github.com/dlang/dmd/commit/8a4a90f51bbc185214f70ccb115cab147a5a7f62
Merge pull request #5924 from MartinNowak/fix16225

fix Issue 16225 - [REG 2.068] Internal error cod1.c 1338 with -O

--

Re: D is crap

[bachmeier via Digitalmars-d]

On Saturday, 9 July 2016 at 08:06:54 UTC, ketmar wrote:
On Saturday, 9 July 2016 at 07:52:57 UTC, Ola Fosheim Grøstad 
wrote:

removed the GC

...

replaced it with automatic reference counting.


you *do* know that refcounting *is* GC, do you? ;-)


And that's a very important point, because the choice of RC vs 
other types of GC ignores the fact that they're both GC, and old 
school programmers didn't want anything to do with a "feature" 
that would slow down their code. RC would have been an even worse 
choice when D started because it is [claimed to be] slower than 
other types of GC. It's been a long time now, but I don't recall 
many arguments against Java's GC because of pauses. The objection 
was always that it would make the code run more slowly.

NanoSVG port

[ketmar via Digitalmars-d-announce]

i also made NanoSVG[1] port[2]: simple SVG parser and rasterizer. 
it is using `malloc()` to allocate memory, but otherwise was 
rewritten to use `const(char)[]` input for svg, and do not use 
`sscanf()` from libc.


the port lives in NanoVG package, but it is actually completely 
independent.



[1] https://github.com/memononen/nanosvg
[2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/nanovg/svg.d

[Issue 16085] wrong visibility warning for overloaded alias symbol

[via Digitalmars-d-bugs]

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

--- Comment #10 from Walter Bright  ---
(In reply to Martin Nowak from comment #9)
> (In reply to Walter Bright from comment #8)
> > > The member "reallocate" should effectively hide the private import, yet 
> > > the
> > > deprecation message still appears.
> > 
> > The private import is hidden. The alias is not.
> 
> Don't quite get that comment. Imports are private by default, so are the
> selectively imported symbol aliases.

 import whatever : reallocate; // <- private

This is the equivalent of:

  alias reallocate = whatever.reallocate;

I.e. an actual alias is generated. The alias is not hidden. The import is.


> Already figured out what's wrong with the overload implementation in
> symbolIsVisible, just need to find time to fix it.

Please don't fix until we agree on what the result should be.

--

[Issue 16188] [REG2.069] ICE on invalid code

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/5925

--

Re: D is crap

[Chris via Digitalmars-d]

On Saturday, 9 July 2016 at 07:52:57 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 8 July 2016 at 22:25:37 UTC, Chris wrote:
after Java. And D was invented when GC was expected by many 
people.


The GC was by far the most criticised feature of D...



GC was a big selling point. Every Java book went on about how


Err... no, the big selling point that gave Java traction was 
portability and Java being marketed as designed for the 
internet and web. GC languages were already available and in 
use, but the JVM/.NET made it difficult for commercial 
development platforms. Portability and Microsoft's dominance 
was a big issue back then.




Yes, of course the "write-once-run-everywhere" fairy tale helped 
to spread Java, but while it was gaining traction GC became a 
feature everybody wanted. Sorry, but there is not a single book 
or introduction to Java that doesn't go on about how great GC is. 
Java was the main catalyst for GC - or at least for people 
demanding it. Practically everybody who had gone through IT 
courses, college etc. with Java (and there were loads) wanted GC. 
It was a given for many people.


blah ... Apple even added GC to Objective-C to appease the GC 
crowd.


Apple removed the GC rather quickly for the same reasons that 
makes GC a bad choice for D. And replaced it with automatic 
reference counting.


Yes, it didn't last long. But the fact that they bothered to 
introduce it, shows you how big GC was/is.

[Issue 16257] New: std.parallelism stress tests don't compile

[via Digitalmars-d-bugs]

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

  Issue ID: 16257
   Summary: std.parallelism stress tests don't compile
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: atila.ne...@gmail.com

../dmd/src/dmd -unittest -c -version=parallelismStressTest std/parallelism.d

std/parallelism.d(4484): Error: isNaN(X)(X x) if (isFloatingPoint!X) is not an
lvalue

--

Re: Vision for the D language - stabilizing complexity?

[Observer via Digitalmars-d]

On Friday, 8 July 2016 at 20:57:39 UTC, Walter Bright wrote:

On 7/7/2016 7:25 PM, Andrew Godfrey wrote:

"static" is a terribly non-descriptive name


That's why it's the go-to keyword for any functionality we 
can't think of a good name for, or if the name would be too 
long such as "launch_nucular_missiles".


For a moment I thought Walter was being comical.  But then I 
looked
at the Index in TDPL, and I see static class constructor, static 
class
destructor, static if, static import, static this, and just plain 
static.


Also, Andrei, if you're listening, I've spotted another TDPL 
errata.
On page 459, the Index entry for "static, obligatory joke about 
overuse
of" lists page 345, but in fact the joke is in the footnote at 
the bottom

of page 68.

As for me, the main thing I dislike about static if is that it 
blends in
visually a bit too well with run-time code segments.  C's #if 
structure

has its own problems, but I like the distinctiveness.

An earlier comment about wanting a different name got me to 
thinking.
For naming variables, I own two copies of a high-quality 
thesaurus.
One copy I keep at work, one copy I keep at home.  It's 
invaluable when
you get stuck at naming things.  Why not apply that same tool to 
naming
keywords as well?  So I looked.  I didn't see anything precisely 
on

target; maybe these come closest:

constant if
durable if
persistent if
adamant if
unalterable if
immutable if

Okay, that last one is a joke, considering that we're talking 
about
keyword overloading.  But the effort did spark some other brain 
cells

to fire.  So we could have had any of these:

exactly if
strictly if
only if

I do like the creative use of an adverb instead of an adjective 
in these
choices; the code reads like standard English instead of a clunky 
made-up
phrase.  I also especially like the briefness and precision of 
"only if",
and that may become my favorite way to think about this in the 
future.
(Is there some way I can "#define only static" to get this 
effect?)
In fact, it is presaged on page 48 of TDPL, from whence I quote:  
"the
basic plot is simple -- static if evaluates a compile-time 
expression and
compiles the controlled statement only if the expression is 
true".  So you
the language designers had the idea in hand, but then sadly 
overlooked it.

Re: Different function attributes between debug and release build

[Lodovico Giaretta via Digitalmars-d]

On Saturday, 9 July 2016 at 01:05:54 UTC, Walter Bright wrote:

On 7/8/2016 1:04 PM, Jerry wrote:

That is definetly a bug.


Not a bug until it is posted to Bugzilla!


Well, I didn't post it there directly because I wasn't sure it 
could be considered a bug. The reason it is not @nogc in debug 
mode is that it performs extra checks that may throw exceptions 
(so I guess it isn't nothrow either), which isn't bad per se, but 
makes it difficult to verify (using unittest) that code using it 
is @nogc.

Re: D is crap

[Walter Bright via Digitalmars-d]

On 7/8/2016 2:36 PM, Luís Marques wrote:

On Friday, 8 July 2016 at 21:26:19 UTC, Walter Bright wrote:

Only on Windows, and that's a common source of frustration for me :(


Linux too.


Not by default, right?


-g

Re: Vision for the D language - stabilizing complexity?

[Walter Bright via Digitalmars-d]

On 7/9/2016 12:37 AM, Ola Fosheim Grøstad wrote:

On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote:

On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote:

On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:

All useful computer languages are unprincipled and complex due to a number of
factors:


I think this is a very dangerous assumption. And also not true.


Feel free to post a counterexample. All you need is one!


Scheme.


I know little about Scheme, so I googled it.

  https://en.wikipedia.org/wiki/Scheme_(programming_language)

And the money shot:

"The elegant, minimalist design has made Scheme a popular target for language 
designers, hobbyists, and educators, and because of its small size, that of a 
typical interpreter, it is also a popular choice for embedded systems and 
scripting. This has resulted in scores of implementations, most of which differ 
from each other so much that porting programs from one implementation to another 
is quite difficult, and the small size of the standard language means that 
writing a useful program of any great complexity in standard, portable Scheme is 
almost impossible."


Seems that in order to make it useful, users had to extend it. This doesn't fit 
the criteria.


Wirth's Pascal had the same problem. He invented an elegant, simple, consistent, 
and useless language. The usable Pascal systems all had a boatload of dirty, 
incompatible extensions.




What is true is that it is difficult to gain traction if a language does not
look like a copy of a pre-existing and fairly popular language.


I.e. Reason #2:

"what programmers perceive as logical and intuitive is often neither logical
nor intuitive to a computer"


I don't understand what you mean by this.


What programmers think of as "intuitive" is often a collection of special cases.