On Saturday, 3 August 2013 at 00:51:21 UTC, F i L wrote:
I've brought this up on here awhile ago, and many people seemed
to be against it. Which I don't agree with, since the
ambiguities it creates are easily addressed (from a design
perspective at least) and only exist so that C-style code is
On Friday, 2 August 2013 at 08:47:31 UTC, Jonathan M Davis wrote:
Is it possible to test at runtime if those newer functions are
available,
use them if so, and a workaround if not?
I'm not sure. Possibly. Given that we previously had code that
checked the
version of Windows and used the A fun
monarch_dodra wrote:
Regardless of the existing merits, that would be a (massive)
breaking change, and as mentioned, it brings nothing we
couldn't do before...
Sure, but not if you do it like my second example:
auto func(auto a, auto b) // like C++14
That doesn't break anything, right?
On Friday, 2 August 2013 at 23:51:22 UTC, SteveGuo wrote:
I'm just a little bit worry about, when new os borns, D has to
support it, time goes by, D will become another overstuffed C++?
This is true of every non-trivial language, regardless if it's a
systems language. The JVM, for example, wil
What would be the correct forum to discuss a possible correction
to the D Language specification?
I started a thread on the Learn forum asking a question regarding
'import', it soon became apparent to me that there may be an
error in the specification. What is the correct forum in which to
di
On Saturday, 3 August 2013 at 08:59:41 UTC, F i L wrote:
monarch_dodra wrote:
Regardless of the existing merits, that would be a (massive)
breaking change, and as mentioned, it brings nothing we
couldn't do before...
Sure, but not if you do it like my second example:
auto func(auto a, aut
On Saturday, 3 August 2013 at 10:26:53 UTC, Andre Artus wrote:
What would be the correct forum to discuss a possible
correction to the D Language specification?
Do you want to discuss it, or just report it?
If it looks like an error, then just report the issue to the D
bug database:
http://
On Friday, 2 August 2013 at 20:34:04 UTC, SteveGuo wrote:
I'm not an expert on programming language, if I made a naive
issue, just forgive me:p
Can we declare a template function like this?
auto Add(a, b) // Note a, b do not have type, that means a and
b use template type
{
return a + b;
On Saturday, 3 August 2013 at 01:15:48 UTC, Andrei Alexandrescu
wrote:
On 2013-08-03 00:51:19 +, F i L said:
I've brought this up on here awhile ago, and many people
seemed to be against it. Which I don't agree with, since the
ambiguities it creates are easily addressed (from a design
per
On Saturday, 3 August 2013 at 10:31:47 UTC, Peter Alexander wrote:
On Saturday, 3 August 2013 at 10:26:53 UTC, Andre Artus wrote:
What would be the correct forum to discuss a possible
correction to the D Language specification?
Do you want to discuss it, or just report it?
If it looks like an
On Monday, 29 July 2013 at 05:05:54 UTC, Denis Shelomovskij wrote:
So is enhancement request filed?
Now it is: http://d.puremagic.com/issues/show_bug.cgi?id=10750
Sorry, I'm not following the lists closely right now due to
university work.
David
On Saturday, 3 August 2013 at 11:39:44 UTC, David Nadlinger wrote:
On Monday, 29 July 2013 at 05:05:54 UTC, Denis Shelomovskij
wrote:
So is enhancement request filed?
Now it is: http://d.puremagic.com/issues/show_bug.cgi?id=10750
Sorry, I'm not following the lists closely right now due to
un
On Friday, 11 May 2012 at 23:51:47 UTC, Mehrdad wrote:
On Friday, 11 May 2012 at 21:53:06 UTC, Jonathan M Davis wrote:
I know that haskell has such a function, and there were a
number of complaints previously that we _didn't_ have an any
function which does exactly what std.algorithm.any now do
On Saturday, 12 May 2012 at 03:42:10 UTC, Ary Manzana wrote:
On 5/12/12 3:40 AM, Mehrdad wrote:
On Friday, 11 May 2012 at 20:20:36 UTC, Jonathan M Davis wrote:
That's definitely an example of something that depends on your
background. std.algorithm.any does _exactly_ what it would do
in a
fun
On Saturday, 3 August 2013 at 11:22:42 UTC, Andre Artus wrote:
I'm not sure that I am explaining this properly as it seems
that at least 2 different people were under the impression I
was making a point quite different from the one I was trying to
make.
I understand. It seems that there are t
On Thursday, 1 August 2013 at 22:45:10 UTC, bearophile wrote:
Walter Bright:
But consider that optimizers are built to optimize typical
code patterns. Component programming is fairly non-existent in
C and C++, and is new in D. Hence, optimizers are not set up
to deal with those patterns (yet)
On Saturday, 3 August 2013 at 13:35:56 UTC, Andre Artus wrote:
import std.stdio;
import std.algorithm;
void main()
{
auto values = [ 1, 2, 3, 4, 5 ];
writeln(values
.map!(a => a * 10)
.map!(a => a / 3)
.filter!(a => !(a % 2)));
}
As stated this implies 3 separate traversals of th
switch (cond)
common: always executed code here
case A : etc...
}
instead of
if (cond) { always executed code here }
switch (cond)
case A : etc...
}
which requires modification of the condition twice when necessary
On Saturday, 3 August 2013 at 12:22:48 UTC, Peter Alexander wrote:
On Saturday, 3 August 2013 at 11:22:42 UTC, Andre Artus wrote:
I'm not sure that I am explaining this properly as it seems
that at least 2 different people were under the impression I
was making a point quite different from the
On Saturday, 3 August 2013 at 14:38:48 UTC, JS wrote:
switch (cond)
common: always executed code here
case A : etc...
}
instead of
if (cond) { always executed code here }
switch (cond)
case A : etc...
}
which requires modification of the condition twice when
ne
On Saturday, 3 August 2013 at 14:38:48 UTC, JS wrote:
switch (cond)
common: always executed code here
case A : etc...
}
instead of
if (cond) { always executed code here }
switch (cond)
case A : etc...
}
which requires modification of the condition twice when
ne
Am 03.08.2013 16:38, schrieb JS:
switch (cond)
common: always executed code here
case A : etc...
}
instead of
if (cond) { always executed code here }
switch (cond)
case A : etc...
}
which requires modification of the condition twice when necessary
s
On Saturday, 3 August 2013 at 13:46:38 UTC, David Nadlinger wrote:
On Saturday, 3 August 2013 at 13:35:56 UTC, Andre Artus wrote:
import std.stdio;
import std.algorithm;
void main()
{
auto values = [ 1, 2, 3, 4, 5 ];
writeln(values
.map!(a => a * 10)
.map!(a => a / 3)
.filter!(a => !(
I'm a bit confused about where we draw the line with purity, and
memory.
For example, take this "simple" function:
//
char[] getMutableHello() pure
{
return "hello".dup;
}
//
This seems like it will *always* create the same result, yet at
the same time, it calls the GC. "dup" coul
On 8/3/13 11:38 AM, JS wrote:
switch (cond)
common: always executed code here
case A : etc...
}
instead of
if (cond) { always executed code here }
switch (cond)
case A : etc...
}
which requires modification of the condition twice when necessary
Do you mea
On 08/03/2013 05:59 PM, monarch_dodra wrote:
I'm a bit confused about where we draw the line with purity, and memory.
For example, take this "simple" function:
//
char[] getMutableHello() pure
{
return "hello".dup;
}
//
This seems like it will *always* create the same result, yet
On Saturday, 3 August 2013 at 15:59:22 UTC, monarch_dodra wrote:
I'm a bit confused about where we draw the line with purity,
and memory.
For example, take this "simple" function:
//
char[] getMutableHello() pure
{
return "hello".dup;
}
//
This seems like it will *always* create t
monarch_dodra wrote:
I'm not sure auto is the best choice of keywords, given
potential clashes with auto ref:
What if you want to pass a by ref?
auto func(auto ref a, auto ref b) ?
auto func(ref auto a, ref auto b) ?
What if you want to pass them by *auto* ref?
auto func(auto auto ref a, auto
On Saturday, 3 August 2013 at 16:16:24 UTC, Ary Borenszweig wrote:
On 8/3/13 11:38 AM, JS wrote:
switch (cond)
common: always executed code here
case A : etc...
}
instead of
if (cond) { always executed code here }
switch (cond)
case A : etc...
}
which requires
On 8/3/13 10:21 AM, JS wrote:
On Saturday, 3 August 2013 at 16:16:24 UTC, Ary Borenszweig wrote:
On 8/3/13 11:38 AM, JS wrote:
switch (cond)
common: always executed code here
case A : etc...
}
instead of
if (cond) { always executed code here }
switch (cond)
case A : etc
I can see you saving a little bit of typing with this, but it's
not worth it.
On Fri, Aug 02, 2013 at 06:07:02PM -0700, Andrei Alexandrescu wrote:
> On 2013-08-02 23:27:20 +, Timon Gehr said:
> >Also, you may want to replace some of the manually implemented
> >ranges where this makes sense.
> >
> >Eg, datesInYear can be expressed more to the point as:
> >
> >
> >auto dat
On Fri, Aug 02, 2013 at 04:29:39PM -0700, H. S. Teoh wrote:
[...]
> How would you translate this to the new syntax:
>
> class A(T,U)
> {
> T fun1(U x) { ... }
> U fun2(T x) { ... }
> V fun3(V)(V x) { ... }
> auto fun4(T)(T x) { ..
On 8/3/2013 10:45 AM, w0rp wrote:
I can see you saving a little bit of typing with this, but it's
not worth it.
It would be a very unconventional syntactic form, and my experience with such
things is it'll see very, very little use.
On 8/3/2013 6:46 AM, David Nadlinger wrote:
In this example, no, as all involved ranges are evaluated lazily. (I see your
general point, though.)
The rules for ranges do not specify if they are done eagerly, lazily, or in
parallel. Meaning, of course, that a library writer could provide all th
I am getting an internal error on page : http://www.dsource.org/
On Sat, Aug 03, 2013 at 04:12:58AM +0200, Timon Gehr wrote:
> On 08/03/2013 01:05 AM, H. S. Teoh wrote:
> >
> >Actually, I just pulled git HEAD again, and it's still working fine.
> >Maybe you just need to update your repo?
> >...
>
> I think it pulled in the wrong version of druntime.
OK, I've w
On Saturday, 3 August 2013 at 18:04:03 UTC, Walter Bright wrote:
On 8/3/2013 10:45 AM, w0rp wrote:
I can see you saving a little bit of typing with this, but it's
not worth it.
It would be a very unconventional syntactic form, and my
experience with such things is it'll see very, very little
On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
I can see you saving a little bit of typing with this, but it's
not worth it.
Um, it can actually save a lot of type and errors.
having two places to change is very error prone.
if (cond) { }
switch(cond)
If the condition is complex an
On Saturday, 3 August 2013 at 18:51:24 UTC, MattCoder wrote:
On Saturday, 3 August 2013 at 18:04:03 UTC, Walter Bright wrote:
On 8/3/2013 10:45 AM, w0rp wrote:
I can see you saving a little bit of typing with this, but
it's
not worth it.
It would be a very unconventional syntactic form, and
On Saturday, 3 August 2013 at 16:47:52 UTC, Timon Gehr wrote:
On 08/03/2013 05:59 PM, monarch_dodra wrote:
One last question: Pointers.
int get(int* p) pure
{
return *p;
}
void main()
{
int i = 0;
auto p = &i;
get(p);
}
Here, get, to me, is obviously not pure, since it depends
On Saturday, August 03, 2013 01:27:20 Timon Gehr wrote:
> Also, you may want to replace some of the manually implemented ranges
> where this makes sense.
>
> Eg, datesInYear can be expressed more to the point as:
>
>
> auto datesInYear(int year){
> return Date(year,1,1).recurrence!((a,n)=>a
On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
I can see you saving a little bit of typing with this, but it's
not worth it.
Um, it can actually save a lot of type and errors.
having two places to change is very error prone.
if
On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
If the implementation is so obviously trivial why don't you
implement a proof of concept? The compiler is open source after
all.
This seems like something that would be fairly simple to
implement using a mixin template, so you may
On 8/3/2013 12:00 PM, JS wrote:
What I really don't get it is why people think that just because they won't use
such a feature then it must be useless to everyone else.
You could provide supporting evidence by examining every use of switch in the
dmd, phobos, and druntime source code, and see
On Sat, Aug 03, 2013 at 09:07:47PM +0200, Meta wrote:
> On Saturday, 3 August 2013 at 16:47:52 UTC, Timon Gehr wrote:
> >On 08/03/2013 05:59 PM, monarch_dodra wrote:
> >>One last question: Pointers.
> >>
> >>int get(int* p) pure
> >>{
> >>return *p;
> >>}
> >>
> >>void main()
> >>{
> >>int
On Sat, Aug 03, 2013 at 12:22:53PM -0700, Walter Bright wrote:
> On 8/3/2013 12:00 PM, JS wrote:
> >What I really don't get it is why people think that just because they
> >won't use such a feature then it must be useless to everyone else.
>
> You could provide supporting evidence by examining eve
On Sat, Aug 03, 2013 at 12:24:08PM -0700, H. S. Teoh wrote:
[...]
> I think a pointer dereference is weakly pure. Consider this:
>
> int func1(int x) pure {
> int scratch = x+1;
> func2(&scratch);
> return scratch;
> }
>
> void func2(int
On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
On Saturday, 3 August 2013 at 18:56:47 UTC, JS wrote:
On Saturday, 3 August 2013 at 17:45:11 UTC, w0rp wrote:
I can see you saving a little bit of typing with this, but
it's
not worth it.
Um, it can actually save a lot of type a
On Saturday, 3 August 2013 at 19:51:33 UTC, JS wrote:
...
I am afraid creating your own language may be your only
possibility to get a language that shares your views on "proper"
design. Because with each new topic it becomes more and more
clear that D is unlikely to fit into that picture.
On Saturday, 3 August 2013 at 19:22:53 UTC, Walter Bright wrote:
On 8/3/2013 12:00 PM, JS wrote:
What I really don't get it is why people think that just
because they won't use
such a feature then it must be useless to everyone else.
You could provide supporting evidence by examining every us
On Saturday, August 03, 2013 12:35:22 H. S. Teoh wrote:
> On Sat, Aug 03, 2013 at 12:22:53PM -0700, Walter Bright wrote:
> > On 8/3/2013 12:00 PM, JS wrote:
> > >What I really don't get it is why people think that just because they
> > >won't use such a feature then it must be useless to everyone e
Regarding the feature proposed here, I think the extra complexity
added doesn't pay enough back.
Walter Bright:
You could provide supporting evidence by examining every use of
switch in the dmd, phobos, and druntime source code, and see
what percentage of those would benefit from your propos
On Saturday, 3 August 2013 at 19:07:49 UTC, Meta wrote:
On Saturday, 3 August 2013 at 16:47:52 UTC, Timon Gehr wrote:
On 08/03/2013 05:59 PM, monarch_dodra wrote:
One last question: Pointers.
int get(int* p) pure
{
return *p;
}
void main()
{
int i = 0;
auto p = &i;
get(p);
}
Here
On Sat, Aug 03, 2013 at 01:33:44PM -0700, Jonathan M Davis wrote:
> On Saturday, August 03, 2013 12:35:22 H. S. Teoh wrote:
> > On Sat, Aug 03, 2013 at 12:22:53PM -0700, Walter Bright wrote:
[...]
> > > Consider, for example, the scope guard statement in D. It is
> > > extremely useful - but it is
On Saturday, August 03, 2013 23:19:33 monarch_dodra wrote:
> Thank the 3 of you for your answers. I think I had a wrong
> preconception of what pure is. I think this cleared most of it up.
_All_ that pure does by itself is guarantee that the function doesn't access
any static or global variables
Hi, I'm playing around with PEGGED (which is awsome BTW) but I'm a bit
stucked how to use it best.
I have this grammer (stripped down to the essentials):
mixin(grammar("
Rebol3:
set_word<- word ':' {set_word_handling} & delim
word<- ~[a-z]+ {word_hand
On Saturday, August 03, 2013 14:25:24 H. S. Teoh wrote:
> On Sat, Aug 03, 2013 at 01:33:44PM -0700, Jonathan M Davis wrote:
> > The only thing that's really missing from C++ that D has that you
> > might use in place of scope is finally.
>
> Truth be told, I think scope trumps finally because it l
On Saturday, 3 August 2013 at 18:12:03 UTC, Flamaros wrote:
I am getting an internal error on page : http://www.dsource.org/
Just one note: early morning I was trying to access:
http://dlang.org/lex.html but it was too slow.
On 8/3/2013 1:06 PM, JS wrote:
On Saturday, 3 August 2013 at 19:22:53 UTC, Walter Bright wrote:
On 8/3/2013 12:00 PM, JS wrote:
What I really don't get it is why people think that just because they won't use
such a feature then it must be useless to everyone else.
You could provide supporting
On 8/3/2013 12:51 PM, JS wrote:
On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
If the implementation is so obviously trivial why don't you implement a proof
of concept?
because I have better things to do
Implying that our time is of lesser value than yours does not help sell y
On Sat, Aug 03, 2013 at 02:34:51PM -0700, Jonathan M Davis wrote:
> On Saturday, August 03, 2013 14:25:24 H. S. Teoh wrote:
> > On Sat, Aug 03, 2013 at 01:33:44PM -0700, Jonathan M Davis wrote:
[...]
> > > I definitely use scope from time to time, but I don't know how
> > > frequently I use it in c
On Saturday, 3 August 2013 at 21:19:35 UTC, monarch_dodra wrote:
Thank the 3 of you for your answers. I think I had a wrong
preconception of what pure is. I think this cleared most of it
up.
You may also find this discussion interesting, if you haven't
already seen it:
http://forum.dlang.o
On Fri, Aug 02, 2013 at 03:02:24PM -0700, H. S. Teoh wrote:
> On Thu, Aug 01, 2013 at 10:49:00PM -0700, Walter Bright wrote:
[...]
> > I think this is awesome, and this + your previous post are
> > sufficient to create a great article!
>
> OK, here's a draft of the article:
>
> http://wiki.
On Saturday, August 03, 2013 14:49:30 H. S. Teoh wrote:
> On Sat, Aug 03, 2013 at 02:34:51PM -0700, Jonathan M Davis wrote:
> > On Saturday, August 03, 2013 14:25:24 H. S. Teoh wrote:
> > > On Sat, Aug 03, 2013 at 01:33:44PM -0700, Jonathan M Davis wrote:
> [...]
>
> > > > I definitely use scope f
On Saturday, August 03, 2013 23:31:56 MattCoder wrote:
> On Saturday, 3 August 2013 at 18:12:03 UTC, Flamaros wrote:
> > I am getting an internal error on page : http://www.dsource.org/
>
> Just one note: early morning I was trying to access:
> http://dlang.org/lex.html but it was too slow.
Well,
On 08/03/2013 09:07 PM, Meta wrote:
On Saturday, 3 August 2013 at 16:47:52 UTC, Timon Gehr wrote:
On 08/03/2013 05:59 PM, monarch_dodra wrote:
One last question: Pointers.
int get(int* p) pure
{
return *p;
}
void main()
{
int i = 0;
auto p = &i;
get(p);
}
Here, get, to me, is
On Saturday, 3 August 2013 at 21:19:35 UTC, monarch_dodra wrote:
On Saturday, 3 August 2013 at 19:07:49 UTC, Meta wrote:
On Saturday, 3 August 2013 at 16:47:52 UTC, Timon Gehr wrote:
On 08/03/2013 05:59 PM, monarch_dodra wrote:
One last question: Pointers.
int get(int* p) pure
{
return *p;
recently i inadvertently created some noise in the bug reporting/tracking
system. i had run into an ICE after using '__MODULE__' in a certain way. before
reporting the bug, i did enter '__MODULE__' in the search mask of the tracking
system but got no hit. so i thought it was a new issue and rep
"Ironclad C++, A Library-Augmented Type-Safe Subset of C++" by
Christian DeLozier et al:
http://repository.upenn.edu/cis_reports/982/
It's a strict subset of C++ plus added some libraries and some
static verifiers. The purpose is to have a safer C++. It has some
similarities with D.
There ar
On 8/3/2013 4:32 PM, bearophile wrote:
The paper explains the various cases: assign from ptr into lptr, assign
from lptr into ptr, and assign from lptr into lptr.
So with a mix of run-time tests and a small amount of static analysis the code
is safe and fast enough. It seems a simple enough idea
On 08/04/2013 01:55 AM, Walter Bright wrote:
On 8/3/2013 4:32 PM, bearophile wrote:
The paper explains the various cases: assign from ptr into lptr,
assign
from lptr into ptr, and assign from lptr into lptr.
So with a mix of run-time tests and a small amount of static analysis
the code
is safe
On Saturday, 3 August 2013 at 23:04:14 UTC, Timon Gehr wrote:
It depends on whether you think a pointer dereference is pure
or not (I don't know the answer).
It is pure in D, but I guess you are not referring to that.
What's your understanding of purity in this context?
I'm thinking of when
On Saturday, 3 August 2013 at 21:42:00 UTC, Walter Bright wrote:
On 8/3/2013 12:51 PM, JS wrote:
On Saturday, 3 August 2013 at 19:10:19 UTC, Andre Artus wrote:
If the implementation is so obviously trivial why don't you
implement a proof
of concept?
because I have better things to do
Implyi
On 8/3/2013 5:49 PM, Timon Gehr wrote:
On 08/04/2013 01:55 AM, Walter Bright wrote:
On 8/3/2013 4:32 PM, bearophile wrote:
The paper explains the various cases: assign from ptr into lptr,
assign
from lptr into ptr, and assign from lptr into lptr.
So with a mix of run-time tests and a small amo
On 08/04/2013 02:50 AM, Meta wrote:
On Saturday, 3 August 2013 at 23:04:14 UTC, Timon Gehr wrote:
...
Modification and dereference within a Haskell expression:
import Data.STRef
import Control.Monad.ST
x = runST $ do
x <- newSTRef 0
writeSTRef x 1
v <- readSTRef x
return v
main = pri
On 08/04/2013 04:06 AM, Walter Bright wrote:
On 8/3/2013 5:49 PM, Timon Gehr wrote:
On 08/04/2013 01:55 AM, Walter Bright wrote:
On 8/3/2013 4:32 PM, bearophile wrote:
The paper explains the various cases: assign from ptr into lptr,
assign
from lptr into ptr, and assign from lptr into lptr.
S
On 8/3/2013 7:08 PM, Timon Gehr wrote:
On 08/04/2013 04:06 AM, Walter Bright wrote:
On 8/3/2013 5:49 PM, Timon Gehr wrote:
On 08/04/2013 01:55 AM, Walter Bright wrote:
On 8/3/2013 4:32 PM, bearophile wrote:
The paper explains the various cases: assign from ptr into lptr,
assign
from lptr into
On 08/03/2013 06:47 PM, Timon Gehr wrote:
Well, no. It is by design. All purity really means is that the part of
the existing store not reachable by following references in the
arguments will not be mutated.
s/mutated/accessed/
On 08/04/2013 04:28 AM, Walter Bright wrote:
On 8/3/2013 7:08 PM, Timon Gehr wrote:
On 08/04/2013 04:06 AM, Walter Bright wrote:
On 8/3/2013 5:49 PM, Timon Gehr wrote:
On 08/04/2013 01:55 AM, Walter Bright wrote:
On 8/3/2013 4:32 PM, bearophile wrote:
The paper explains the various cases: as
So, depending on how you define "not worth it", which I take
"I'm too lazy to implement it", you could be correct.
YaAA:
If the implementation is so obviously trivial why don't you
implement a proof of concept? The compiler is open source
after all.
JS:
because I have better things to do a
H. S. Teoh:
OK, here's a draft of the article:
http://wiki.dlang.org/User:Quickfur/Component_programming_with_ranges
Most of the code below is not tested. So my suggestions may
contain bugs or mistakes.
A bit improved chunkBy could go in Phobos.
---
For our purposes
Bearophile:
If not already present this array should go in std.datetime or
core.time:
static immutable string[] monthNames = [
"January", "February", "March", "April", "May", "June",
"July", "August", "September", "October", "November",
"December"
];
It should probab
On Sunday, 4 August 2013 at 02:05:55 UTC, Timon Gehr wrote:
no variables are being modified.
Which I didn't claim. A reference is dereferenced and the
contents of the referenced slot are replaced. Then the
reference is dereferenced again to read the modified value out.
I'm confused about wh
On 8/3/2013 7:41 PM, Timon Gehr wrote:
Yes, but as far as I understood it you can assign lptr back to ptr
implicitly by paying for a runtime check. It's what D will be doing with T* <->
ref T, right?
I thought the idea was to use the type system to avoid runtime checks.
(The general problem
On Sunday, August 04, 2013 06:20:57 Andre Artus wrote:
> > Bearophile:
> > If not already present this array should go in std.datetime or
> >
> > core.time:
> > static immutable string[] monthNames = [
> >
> > "January", "February", "March", "April", "May", "June",
> > "Ju
On Sun, Aug 04, 2013 at 01:15:24AM +0200, John Colvin wrote:
[...]
> Is there anywhere formal defining D's pure (weak vs strong etc.)? A
> page in the wiki perhaps?
>
> Imagine someone new coming to D and being confused by what our
> purity system is. It would suck to only be able to give an ad-ho
On 08/04/2013 06:37 AM, Meta wrote:
On Sunday, 4 August 2013 at 02:05:55 UTC, Timon Gehr wrote:
no variables are being modified.
Which I didn't claim. A reference is dereferenced and the contents of
the referenced slot are replaced. Then the reference is dereferenced
again to read the modified
On Sun, Aug 04, 2013 at 05:02:05AM +0200, bearophile wrote:
[...]
> A bit improved chunkBy could go in Phobos.
Yeah I'll look into that sometime. It'll definitely be a useful thing to
have, I think.
> ---
>
> >For our purposes, though, we can't just do this in a loop, because
> >it
On Saturday, 3 August 2013 at 23:30:12 UTC, captaindet wrote:
recently i inadvertently created some noise in the bug
reporting/tracking system. i had run into an ICE after using
'__MODULE__' in a certain way. before reporting the bug, i did
enter '__MODULE__' in the search mask of the tracking
90 matches
Mail list logo
