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

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

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

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

Re: DIP: Tail call optimization

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

Re: Card on fire

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

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

DIP: Tail call optimization

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

Re: Vision for the D language - stabilizing complexity?

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

Re: Card on fire

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

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

Re: D is crap

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

exceptions vs error codes

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?

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

Card on fire

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

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

Re: Vision for the D language - stabilizing complexity?

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:

Re: UB in 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

Re: D is crap

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

Re: D is crap

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,

Re: D is crap

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

Re: UB in 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

Re: Vision document for H2 2016

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

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

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

Re: UB in 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

Re: UB in 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

Re: Go's march to low-latency GC

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

Re: Go's march to low-latency GC

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. --

Re: Vision for the D language - stabilizing complexity?

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

Re: UB in D

On 10.07.2016 00:36, Timon Gehr wrote: the language semantics don't *doesn't

UB in 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:

Re: Announcing new DIP handling process

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

Re: Vision for the D language - stabilizing complexity?

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

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

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

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

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

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

https://issues.dlang.org/show_bug.cgi?id=16188 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: Go's march to low-latency GC

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

Re: Announcing new DIP handling process

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

Probably a real simple compile-time reflection question?

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);

Re: Accessing contents of associative arrays in an optimal way

Thank you!

Re: Accessing contents of associative arrays in an optimal way

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

Re: Singleton Pattern

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

Re: Accessing contents of associative arrays in an optimal way

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

Re: Singleton Pattern

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

Accessing contents of associative arrays in an optimal way

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

Re: Battle-plan for CTFE

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

Re: Go's march to low-latency GC

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.

Very interesting slides about Fibers

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

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.),

Re: Go's march to low-latency GC

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.

Re: Go's march to low-latency GC

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

Re: Vision for the D language - stabilizing complexity?

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 =

Re: Announcing new DIP handling process

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

Re: Go's march to low-latency GC

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

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

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

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

Re: Vision for the D language - stabilizing complexity?

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

Re: Vision for the D language - stabilizing complexity?

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

Re: Vision document for H2 2016

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

Re: Vision document for H2 2016

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

Re: NanoSVG port

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?

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

Re: Variadic Tuple of Structs with Mixed Types

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 ...) =

Re: Vision for the D language - stabilizing complexity?

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.

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

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

Re: std.experimental.randomized_unittest_benchmark is ready for comments

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

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

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

Re: Vision for the D language - stabilizing complexity?

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

Re: Vision for the D language - stabilizing complexity?

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

Re: Announcing new DIP handling process

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

Re: Go's march to low-latency GC

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

Re: Announcing new DIP handling process

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:

Re: NanoSVG port

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

Announcing new DIP handling process

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

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

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

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

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?

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.

Re: D is crap

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,

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

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

Re: Vision for the D language - stabilizing complexity?

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

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

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.

Re: Vision for the D language - stabilizing complexity?

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

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

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

Re: Vision for the D language - stabilizing complexity?

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

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

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

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

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

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?

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

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

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

Seems pretty silly to me...

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

https://issues.dlang.org/show_bug.cgi?id=16225 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

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

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

Re: D is crap

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

NanoSVG port

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.

[Issue 16085] wrong visibility warning for overloaded alias symbol

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 > > >

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

https://issues.dlang.org/show_bug.cgi?id=16188 Walter Bright changed: What|Removed |Added CC|

Re: D is crap

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

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

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

Re: Vision for the D language - stabilizing complexity?

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

Re: Different function attributes between debug and release build

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

Re: D is crap

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?

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

  1   2   >