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
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
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
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
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
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
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:
http
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 be
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
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.
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 and
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
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:
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.
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
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
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
elements
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.
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 {
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
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
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
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
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
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
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
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
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 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 digitalmars-d@puremagic.com
wrote:
Jonathan is right. what this PR does is changing one (somewhat
confusing) terminology to another, even more
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 digitalmars-d@puremagic.com
wrote:
sorry for the late answer.
Don't think I'm being flippant, but I have trouble
interpreting such feedback, because
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 digitalmars-d@puremagic.com
wrote:
In either case, we are passing a reference by value.
yes. but passing null class will not allow to call it's
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 digitalmars-d@puremagic.com
wrote:
maybe just call that slice views? ;-)
really, uncommon term will (at least it should ;-) make user to
read
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 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
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
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()
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
On Sunday, 25 July 2010 at 14:10:10 UTC, Simen kjaeraas wrote:
bearophile bearophileh...@lycos.com 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
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.
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,
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 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 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
On Thursday, 11 February 2016 at 08:37:29 UTC, Andrea Fontana
wrote:
Check this:
http://digger.k3.1azy.net/trend/
Very nice!
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
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
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 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 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++
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
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
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
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
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
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.
We do
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
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, 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
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
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
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
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
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
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 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
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.
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
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
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
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
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
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
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,
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
On 8/26/14, 9:46 AM, Dicebot wrote:
...and it has just been merged! ^_^
Thanks Walter!
Nice! This felt like a glaring hole,
and you've filled it!
On Friday, 29 August 2014 at 02:10:46 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
In D you just use '.' throughout and it Just Works(tm).
Unless the property you're accessing is also a pointer property,
like
sizeof. Then you have to be careful. The below prints 4 then 8
(on 32-bit):
On Friday, 29 August 2014 at 05:05:55 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Fri, Aug 29, 2014 at 04:37:37AM +, Andrew Godfrey via
Digitalmars-d-learn wrote:
Unless the property you're accessing is also a pointer
property, like
sizeof. Then you have to be careful.
True. Though
On Tuesday, 2 September 2014 at 14:06:04 UTC, seany wrote:
How do I read unicode chars that has code points \u1FFF and
higher from a file?
file.getcw() reads only part of the char, and D identifies this
character as an array of three or four characters.
Importing std.uni does not change the
Is it common for a C++ library you want to interface to, to use
std library types in its interface? Things like iterators or
maybe containers.
Do those hit any of the hard cases, so that you'd need to
change the std library to resolve the issue?
I really don't think that it's an issue in general, but if you
do want to
guarantee that nothing affects the capacity of your array, then
you're going
to need to either wrap all access to it
I agree with everything Jonathan said in both threads EXCEPT that
this is not an issue.
The
On Sunday, 12 June 2016 at 08:15:37 UTC, ag0aep6g wrote:
On 06/12/2016 05:16 AM, Andrew Godfrey wrote:
Eg it says ".chars returns the number of characters (aka
graphemes)"
Does this count the number of graphemes, or the number of
grapheme
clusters? Later on with \r\n it pretty much says that
On Saturday, 11 June 2016 at 18:33:04 UTC, ag0aep6g wrote:
On 06/11/2016 06:47 PM, Andrew Godfrey wrote:
OTOH, it mentions both graphemes and grapheme clusters,
without much
distinction. So I'm not exactly sure which is the default
focus.
What distinction is there to be made? As far as I
On Saturday, 11 June 2016 at 19:43:45 UTC, ag0aep6g wrote:
On 06/11/2016 09:25 PM, Andrew Godfrey wrote:
That's the distinction, yes. The article mentions both in a
way that
makes me unsure if Perl 6 confused the terms (or maybe it's
just the
article that isn't being clear).
But how would
On Wednesday, 11 May 2016 at 12:11:32 UTC, Guillaume Chatelet
wrote:
It looks good:
https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-perl-6-and-you/
Especially, it works in graphemes, and ".codes" lets you count
code points. The article isn't even mentioning "code units".
OTOH, it
On Sunday, 31 July 2016 at 05:41:55 UTC, AntonSotov wrote:
2 Seb
Thank you!
is (T: typeof (null)) - very comfortable
An example of Seb's warning:
What happens if you have:
string s = null;
MyFunc(s);
I'm guessing it doesn't do what you want. But it isn't clear what
you want - null is a
On Monday, 11 July 2016 at 17:31:23 UTC, Dietrich Daroch wrote:
On Monday, 11 July 2016 at 16:27:38 UTC, Andrew Godfrey wrote:
[...]
* It must not be ignorable by the compiler.
* It must generate an error if that compiler would be unable
to do the TCO. Otherwise, the compiler *may* (not
On Thursday, 14 July 2016 at 14:01:29 UTC, Kagamin wrote:
On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote:
Um, no, I revived it so that people searching for answers
wouldn't be led astray by idiots who pretend to know
everything.
My word is not COM specification of course,
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu
wrote:
https://wiki.dlang.org/Vision/2016H2 -- Andrei
I see that this thread has sparked a lot of "ideas for the
future". That's a great outcome but many of them don't belong in
this vision document, and in fact some probably
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
Btw here's a thread from 2014 that touches on the idea of a
"tailrec" annotation. At the time, Walter viewed the optimization
as the compiler's business and not something he'd elevate to a
language feature:
http://forum.dlang.org/post/lqp6pu$1kkv$1...@digitalmars.com
On Monday, 11 July 2016 at 10:25:36 UTC, Tofu Ninja wrote:
On Sunday, 10 July 2016 at 13:15:38 UTC, Andrew Godfrey wrote:
Btw here's a thread from 2014 that touches on the idea of a
"tailrec" annotation. At the time, Walter viewed the
optimization as the compiler's business and not something
On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote:
On Monday, 11 July 2016 at 14:36:22 UTC, Andrew Godfrey wrote:
On Monday, 11 July 2016 at 10:25:36 UTC, Tofu Ninja wrote:
On Sunday, 10 July 2016 at 13:15:38 UTC, Andrew Godfrey wrote:
Btw here's a thread from 2014 that touches on
On Tuesday, 16 May 2017 at 08:32:56 UTC, Nordlöw wrote:
What's the status of atomicity of file-copying and -moving
(renaming) using std.file on different platforms?
For renaming that's a good question, but for copying, no-one
should make atomicity guarantees. It's inherently non-atomic, and
This looks very nice, but I'm having trouble getting it to work
on Windows with DMD.
What static linker are you using? DmdDCompiler is defined to need
one,
but the code in detect_static_linker expects the linker to
support the "--version" command-line parameter (or "/?" if the
linker is
I just updated to 2.074.0. I see there's still a README.TXT which
tells me
(on windows) to download dmc, "which contains the linker and
necessary libraries".
Is this out of date? I see a "link.exe" in the dmd package.
Granted it's a bit older, but do I care?
95 matches
Mail list logo
