On Monday, 10 April 2017 at 06:17:43 UTC, Dukc wrote:
On Monday, 10 April 2017 at 02:04:35 UTC, Andrew Godfrey wrote:
On Monday, 10 April 2017 at 01:54:54 UTC, Walter Bright wrote:
throw new E(string);
Did you mean to use the "scope" keyword somewhere in the line
above?
No. In the scope
On Monday, 10 April 2017 at 01:54:54 UTC, Walter Bright wrote:
On 4/9/2017 6:32 PM, Andrew Godfrey wrote:
Ok. So then if I have created a refcounted Exception, and
later (in another
function) I take a reference to it (by stuffing it into a
struct field, say),
how does that work?
You can't, b
On Monday, 10 April 2017 at 00:48:39 UTC, Walter Bright wrote:
On 4/9/2017 5:12 PM, Andrew Godfrey wrote:
Is it general?
No.
If not, what is special about Exceptions that makes it work
here?
It only works because all ways that such exceptions can leak
are controlled. D doesn't have copy c
On Sunday, 9 April 2017 at 20:15:46 UTC, Walter Bright wrote:
On 4/9/2017 1:35 AM, Dukc wrote:
object aMemoryLeak;
void someFunc()
{ throw (aMemoryLeak = new Exception("hello world!"));
}
Would the compiler warn about this or make the exception
normally garbage
collected?
That would be a
On Sunday, 9 April 2017 at 03:26:14 UTC, Walter Bright wrote:
My previous version did not survive implementation. Here's the
revised version. I have submitted it as a DIP, and there's a
trial implementation up:
[...]
Just a quick note to reduce confusion for reviewers:
The number of parent
On Wednesday, 3 August 2016 at 23:00:11 UTC, Seb wrote:
There was a recent discussion on Phobos about D's floating
point behavior [1]. I think Ilya summarized quite elegantly our
problem:
[...]
In my experience (production-quality FP coding in C++), you are
in error merely by combining floa
On Thursday, 21 July 2016 at 08:40:03 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote:
ideas that would require a major version change. The thing
about that is that it can't be done incrementally; it's the
rare kind of thing that would need to be
On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote:
On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad
wrote:
Not sure what you mean.
1. It is more time consuming to write an analysis engine that
can cover convoluted machinery than simple machinery.
2. It it more difficult
On Wednesday, 20 July 2016 at 20:12:14 UTC, Jack Stouffer wrote:
On Tuesday, 19 July 2016 at 15:22:19 UTC, Andrew Godfrey wrote:
[...]
Something being dfix-able is not enough for the simple reason
that legacy code in D is already becoming a thing, despite D2
only existing for nine years. A c
On Tuesday, 19 July 2016 at 09:49:50 UTC, Chris wrote:
On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote:
2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d <
digitalmars-d@puremagic.com>:
I've never seen a definitive "No" to breaking changes.
W
On Thursday, 14 July 2016 at 20:01:54 UTC, Walter Bright wrote:
On 7/14/2016 11:49 AM, Steven Schveighoffer wrote:
In C++, the compiler has to reload x, because it may have
changed.
That's right. I learned that the hard way, when the original
optimizer would assume that x hadn't changed. It b
On Monday, 18 July 2016 at 09:45:39 UTC, Chris wrote:
On Sunday, 17 July 2016 at 02:17:52 UTC, Andrew Godfrey wrote:
On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote:
On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
Walter called Prolog "singularly useless". You have been
referring to
On Sunday, 17 July 2016 at 12:38:46 UTC, Andrei Alexandrescu
wrote:
On 7/15/16 10:43 AM, Andrew Godfrey wrote:
On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter
wrote:
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh
wrote:
I think the one that hurts the most is fixing "C++ fa
On Sunday, 17 July 2016 at 02:07:19 UTC, pineapple wrote:
On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote:
2) I wonder if an "uninitialized" feature would be worthwhile.
That is, a value you can initialize a variable to, equal to
'init', but that static analyzers know you don't me
On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote:
On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
Walter called Prolog "singularly useless". You have been
referring to changes
that would amount to a new major version of D as "a cleanup".
From the forums,
my sense is that there IS a gr
On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote:
On 7/16/2016 5:32 AM, Andrew Godfrey wrote:
[...]
Thanks for taking the time to post about your experience with
it. Comparing D with SAL is a worthwhile exercise.
[...]
I've seen SAL before, but have not studied it. My impr
On Saturday, 16 July 2016 at 07:14:03 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote:
On 7/14/2016 6:26 AM, Chris wrote:
Now, now. Where's your sense of humor?
The thing is, he's just here to troll us. His posts all follow
the same pattern of r
On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote:
But in C++, everything is @system. I'm not sure how people
successfully create enormous programs with it.
I work on Microsoft Word. I'm not sure how much I can share about
internal verification tools, but I can say: We do have SA
On Saturday, 16 July 2016 at 04:24:39 UTC, Walter Bright wrote:
On 7/15/2016 8:25 PM, Andrew Godfrey wrote:
I agree and I like mechanically checkable things. But I also
like compiler
features that mix mechanical checking with the ability to
attest to something
that can't be mechanically checked
On Friday, 15 July 2016 at 23:00:45 UTC, Walter Bright wrote:
On 7/15/2016 1:48 PM, Shachar Shemesh wrote:
On 15/07/16 22:50, Walter Bright wrote:
You can do logical const in D just like in C++, and get those
performance gains. You just can't call it "const". But you
can call it
/*logical_co
On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote:
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote:
I think the one that hurts the most is fixing "C++ fault" #3.
It means there are many scenarios in which I could put const
in C++, and I simply can't in D, because
On Saturday, 9 July 2016 at 22:20:22 UTC, Timon Gehr wrote:
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 mean
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 thi
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
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. Th
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" -
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
Generally it's not a feasible strategy to assign (or assume as
reader) a single context-independent meaning to a keyword.
That may be overstating it, yes. But I am looking here for a
positive statement about what kind of addition is "beyond the
pale". For example, in C++, "enum class" uses tw
This question is (I've just realized) the primary concern I have
about the future of D (and hence whether it's worth depending on).
I looked at the 2015H1 vision, and don't see an answer to this
there.
So, an example to illustrate the question: In a recent thread, I
saw code that used an "al
On Wednesday, 6 July 2016 at 07:38:50 UTC, qznc wrote:
On Wednesday, 6 July 2016 at 07:22:26 UTC, Tofu Ninja wrote:
Problem with that is ldc and gdc are always a few versions
behind dmd.
LDC is quite close now.
LDC v1.0.0 was released June 6 with DMD 2.070.2 compatibility.
DMD 2.070.2 was re
On Monday, 30 May 2016 at 18:26:32 UTC, Adam D. Ruppe wrote:
On Monday, 30 May 2016 at 17:14:47 UTC, Andrew Godfrey wrote:
I like "make string iteration explicit" but I wonder about
other constructs. E.g. What about "sort an array of strings"?
How would you tell a generic sort function whether
I like "make string iteration explicit" but I wonder about other
constructs. E.g. What about "sort an array of strings"? How would
you tell a generic sort function whether you want it to interpret
strings by code unit vs code point vs grapheme?
On Saturday, 28 May 2016 at 19:04:14 UTC, Walter Bright wrote:
On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote:
So it harkens back to the original mistake: strings should NOT
be arrays with
the respective primitives.
An array of code units provides consistency, predictability,
flexibility, a
On Thursday, 11 February 2016 at 08:37:29 UTC, Andrea Fontana
wrote:
Check this:
http://digger.k3.1azy.net/trend/
Very nice!
I just upgraded from DMD 2.065.0 (so about 2 years old) to
2.070.0, and noticed a difference in compilation speed. I'll
detail what I see, in case it's interesting, but really I just
want to ask: What should I expect? I know that DMD is now
selfhosting, and I know there's a tradeoff between com
On Tuesday, 2 September 2014 at 13:15:02 UTC, Dicebot wrote:
On Tuesday, 2 September 2014 at 08:24:42 UTC, ketmar via
Digitalmars-d wrote:
please note that i'm not trying to say that D developers doing
everything wrong nor that they are incompetent. D is great.
but we can
make it even better. j
On Sunday, 25 July 2010 at 14:10:10 UTC, Simen kjaeraas wrote:
bearophile wrote:
I suggest all people in all D newsgroups, to write code that
runs, not uncompilable snippets. All errors in the last
Walter's talk can be avoided in few minutes running the code.
In Python newsgroups 90% of the
On Friday, 29 August 2014 at 04:29:31 UTC, Vladimir Panteleev
wrote:
On Friday, 29 August 2014 at 04:21:54 UTC, Andrew Godfrey wrote:
The first parameter of formattedRead is a non-const ref. Is
there
a good reason for this?
formattedRead takes an input range as the first parameter, and
consu
The first parameter of formattedRead is a non-const ref. Is there
a good reason for this?
e.g. the below doesn't compile, but if I remove the 'const' from
Foo.normalize, then it succeeds:
unittest {
import std.datetime;
struct Foo {
string date;
DateTime normalize() con
On Monday, 25 August 2014 at 08:07:58 UTC, Marc Schütz wrote:
On Sunday, 24 August 2014 at 18:43:36 UTC, Dmitry Olshansky
wrote:
24-Aug-2014 22:19, Andrew Godfrey пишет:
The OP and the question of auto-decoding share the same root
problem:
Even though D does a lot better with UTF than other lan
On Sunday, 24 August 2014 at 18:43:36 UTC, Dmitry Olshansky wrote:
24-Aug-2014 22:19, Andrew Godfrey пишет:
The OP and the question of auto-decoding share the same root
problem:
Even though D does a lot better with UTF than other languages
I've used,
it still confuses characters with code point
The OP and the question of auto-decoding share the same root
problem: Even though D does a lot better with UTF than other
languages I've used, it still confuses characters with code
points somewhat. "Element type is some character" is an example
from OP. So clarify for me:
If a programmer makes
On Thursday, 21 August 2014 at 03:53:42 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 21 Aug 2014 03:24:35 +
Andrew Godfrey via Digitalmars-d
wrote:
maybe just call that "slice views"? ;-)
really, uncommon term will (at least it should ;-) make user to
read
about that "sl
On Wednesday, 20 August 2014 at 00:13:32 UTC, ketmar via
Digitalmars-d wrote:
On Tue, 19 Aug 2014 23:58:57 +
Andrew Godfrey via Digitalmars-d
wrote:
In either case, we are "passing a reference by value".
yes. but passing null class will not allow to call it's
methods, an
On Sunday, 17 August 2014 at 07:33:01 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 14 Aug 2014 06:46:40 +
Andrew Godfrey via Digitalmars-d
wrote:
sorry for the late answer.
Don't think I'm being flippant, but I have trouble
interpreting such feedback, because D'
On Monday, 11 August 2014 at 19:43:26 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 11 Aug 2014 07:04:41 +
Andrew Godfrey via Digitalmars-d
wrote:
Jonathan is right. what this PR does is changing one (somewhat
confusing) terminology to another, even more confusing one.
Thanks for adding
Reminder: The PR is ready for review:
https://github.com/D-Programming-Language/dlang.org/pull/623
Jonathan has summarized his position in the commments.
What do the rest of you think?
H. S. Teoh, Jakob, Ali, Marc, Dominikus, Chris -
your impression of whether this clears up the confusion would
On Tuesday, 5 August 2014 at 09:42:26 UTC, Ola Fosheim Grøstad
wrote:
But I don't think this path is all that new… so I hope Walter,
if he continues walking down this path, remains unrelenting and
keeps walking past "assert as assume" until he finds truly new
territory in the realm of formal me
On Sunday, 3 August 2014 at 15:06:56 UTC, Walter Bright wrote:
On 8/2/2014 1:06 PM, Artur Skawina via Digitalmars-d wrote:
There's nothing wrong with `assume`, it's very useful for
optimizations.
But it's too dangerous to tack `assume` onto `assert`. If they
are kept
separate then it's at least
On Saturday, 2 August 2014 at 21:36:11 UTC, Tobias Pankrath wrote:
On Saturday, 2 August 2014 at 21:25:40 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei
Alexandrescu wrote:
Hmmm... code that fails assertions is hardly working. --
Andrei
It is not the code t
On Saturday, 2 August 2014 at 10:21:44 UTC, Artur Skawina via
Digitalmars-d wrote:
On 08/02/14 11:36, Chris Cain via Digitalmars-d wrote:
On Saturday, 2 August 2014 at 07:36:34 UTC, Tofu Ninja wrote:
...
Look, this is the point I'm trying to make. Given the English
definition of assert
We'
On Saturday, 2 August 2014 at 05:59:14 UTC, Timon Gehr wrote:
On 08/02/2014 05:34 AM, Andrew Godfrey wrote:
Suppose I call some logging function which has a faulty
assertion in it.
What about Walter's position prevents that assertion's effects
from
escaping the logging function and infecting m
On Friday, 1 August 2014 at 21:36:14 UTC, Chris Cain wrote:
On Friday, 1 August 2014 at 07:51:32 UTC, Andrew Godfrey wrote:
Going through other .dd files, I found an error in
expression.dd.
It says "For static or dynamic arrays, identity is defined as
referring
to the same array elements and t
Suppose I call some logging function which has a faulty assertion
in it. What about Walter's position prevents that assertion's
effects from escaping the logging function and infecting my code?
I know cross-module optimization is hard hence this may be
unlikely, but still it shows something mis
On Friday, 1 August 2014 at 03:58:22 UTC, Walter Bright wrote:
If you look at the Wikipedia article,
http://en.wikipedia.org/wiki/Assertion_(software_development)
you'll see a more high level view of what assert is all about,
rather than a worm's eye view the C standard takes. (It even
use
On Friday, 1 August 2014 at 07:51:32 UTC, Andrew Godfrey wrote:
Going through other .dd files, I found an error in
expression.dd.
It says "For static or dynamic arrays, identity is defined as
referring
to the same array elements and the same number of elements."
Well, in fact:
unittest {
Pull request:
https://github.com/D-Programming-Language/dlang.org/pull/623
fyi, I will be away for 3 weeks, mostly unavailable but
may be able to respond occasionally.
Going through other .dd files, I found an error in expression.dd.
It says "For static or dynamic arrays, identity is defined as
referring
to the same array elements and the same number of elements."
Well, in fact:
unittest {
// expression.dd says that equality AND IDENTITY compare
element
On Thursday, 31 July 2014 at 16:37:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 31, 2014 at 03:44:35PM +0200, Daniel Gibson via
Digitalmars-d wrote:
[...]
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get why anyone would w
On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright wrote:
2. The compiler can make use of assert expressions to improve
optimization, even in -release mode.
For the domain I'm currently working in - a
very large codebase (> 1 MLOC, C/C++) for an application program,
I have to echo what o
What about T[] is _not_ a dynamic array?
Now that I've done this exercise I can answer more crisply:
When T[] is an lvalue, it behaves like a reference, not a dynamic
array.
fyi, here's what I have so far.
I haven't yet added the cross-references we talked about at the
start of the thread. I'll be away for a few weeks soon, so
won't have much more time until after that.
I'm hoping this link is public. It seemed public:
https://github.com/AndrewGodfrey/dlang.org/comm
On Tuesday, 29 July 2014 at 20:06:28 UTC, Marc Schütz wrote:
int[3] a = [1, 0, -1];
int[] b = a;
int[] c = new int[4];
b[] = c[1..4];
assert(a[2] == 0);
// This copies a slice of the slice c onto the slice b
(which refers to a).
Playing the devil's advocate:
Yes, it does s
On Tuesday, 29 July 2014 at 08:41:48 UTC, Marc Schütz wrote:
On Tuesday, 29 July 2014 at 07:46:34 UTC, Andrew Godfrey wrote:
I gave this a try, and overall it looks like an improvement,
but I think we need another name than "slice". The reason is
that the slice operator is a distinct thing an
On Sunday, 27 July 2014 at 05:51:46 UTC, Jakob Ovrum wrote:
On Saturday, 26 July 2014 at 23:06:02 UTC, Andrew Godfrey wrote:
Thereafter can come sub-slice examples and so on.
Does this make sense?
Yes, the reference documentation is pretty terrible with naming
of various array concepts.
IIR
The array article does a great job explaining a lot about D
arrays, and it definitely has helped people understand them.
But it uses the wrong terminology, and that's my point. In D,
T[] is a dynamic array and a slice. As far as D is concerned,
there is no difference. T[] normally refers to a b
Conflating both concepts with the same name is why the article
was so dearly needed in the first place.
Except that no concepts are being conflated.
Yes, they are. Consider again the sentence I quoted: "Slicing an
array means to specify a subarray of it." The word "it" is wrong;
for it to
On Friday, 25 July 2014 at 15:55:50 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jul 25, 2014 at 03:07:53PM +, Andrew Godfrey via
Digitalmars-d wrote:
On Friday, 25 July 2014 at 04:38:40 UTC, Jonathan M Davis via
Digitalmars-d
wrote:
>You really should read this article:
>
On Friday, 25 July 2014 at 04:38:40 UTC, Jonathan M Davis via
Digitalmars-d wrote:
You really should read this article:
http://dlang.org/d-array-article.html
Thank you, that was educational.
What I needed to read was that "A slice does not own the array,
it references the array." - which I kn
Is this a bug? Or am I misunderstanding
something?
import std.stdio, std.string;
import std.array;
unittest {
int[] a;
a.reserve(10);
a.length++;
int *p = &(a[0]);
a.length++; // Increase size. Shouldn't reallocate.
int *p2 = &(a[0]);
assert(p == p2); // And indeed
My understanding is that it can be done
but only with annotations or whole program analysis.
I think that's true but you don't necessarily have to annotate
every function.
a) possibly there's something interesting to do at the module
level. I think more than one thing. E.g. A module that doe
On Monday, 21 July 2014 at 22:10:06 UTC, bearophile wrote:
Tobias Müller:
Wouldn't it be more useful to have a modified/annotated return
statement for that?
I don't know.
I see what you're saying, and it works for the quick sort
example. I'm not sure it covers all tailrec cases, but it see
On Sunday, 20 July 2014 at 06:06:16 UTC, bearophile wrote:
Andrew Godfrey:
2) Annotations about when a function does not expect
re-entrancy
to be possible based on call-graph analysis.
I don't understand. Assuming I know tAhis
(http://en.wikipedia.org/wiki/Reentrancy_%28computing%29 ) can
Returning to the earlier question, of helping to avoid stack
overflows:
I can easily think of two things the language could do.
(Forgive me if D already has them - I have read a fair amount but
not all the minutiae.)
1) A function annotation that means "I will call myself
recursively, and when I
74 matches
Mail list logo
