On Wednesday, 8 August 2018 at 13:10:58 UTC, learnfirst1 wrote:
https://run.dlang.io/is/blpkb6
There is no reason the code just work without template, but try
put the it into template the variable become into not readable ?
Please don't post your issues in multiple forums. This is exactly
wh
https://run.dlang.io/is/blpkb6
There is no reason the code just work without template, but try
put the it into template the variable become into not readable ?
On 6/12/18 4:19 PM, bauss wrote:
On Tuesday, 12 June 2018 at 17:24:31 UTC, Basile B. wrote:
I don't know if more doc is necessary. The warning is at its right
place IMO.
If they're reserved the compiler should honestly throw a warning at the
very least.
People should have to read through th
On Tuesday, 12 June 2018 at 17:24:31 UTC, Basile B. wrote:
On Tuesday, 12 June 2018 at 15:42:50 UTC, Bauss wrote:
On Tuesday, 12 June 2018 at 14:37:19 UTC, ag0aep6g wrote:
On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:
See the following: https://run.dlang.io/is/uQ21PH
(I have tried wi
On Tuesday, 12 June 2018 at 15:42:50 UTC, Bauss wrote:
On Tuesday, 12 June 2018 at 14:37:19 UTC, ag0aep6g wrote:
On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:
See the following: https://run.dlang.io/is/uQ21PH
(I have tried with allMembers too.)
It's like it won't pick up the member t
On Tuesday, 12 June 2018 at 14:37:19 UTC, ag0aep6g wrote:
On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:
See the following: https://run.dlang.io/is/uQ21PH
(I have tried with allMembers too.)
It's like it won't pick up the member that is added using a
mixin at line 22.
```
mixin("uby
On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:
See the following: https://run.dlang.io/is/uQ21PH
(I have tried with allMembers too.)
It's like it won't pick up the member that is added using a
mixin at line 22.
```
mixin("ubyte[" ~ to!string(__PADDING_SIZE__) ~ "] __PADDING__"
~ mem
On Tuesday, 12 June 2018 at 13:40:45 UTC, bauss wrote:
See the following: https://run.dlang.io/is/uQ21PH
Note: Look at the comments in the code.
See the following: https://run.dlang.io/is/uQ21PH
(I have tried with allMembers too.)
It's like it won't pick up the member that is added using a mixin
at line 22.
```
mixin("ubyte[" ~ to!string(__PADDING_SIZE__) ~ "] __PADDING__" ~
member ~ ";");
```
As you can see if you take sizeof fro
On Monday, 12 December 2016 at 06:43:52 UTC, Shachar Shemesh
wrote:
The following compiles fine:
immutable char[5] array = x"01 02 03 04 05";
[...]
This doesn't seem like a bug:
immutable ubyte[5] array = x"01 02 03 04 05";
This however does:
immutable ubyte[5] array = cast(immutable ubyte
The following compiles fine:
immutable char[5] array = x"01 02 03 04 05";
The following doesn't:
immutable ubyte[5] array = x"01 02 03 04 05";
which makes sense, but neither does:
immutable ubyte[5] array = cast(immutable ubyte []) x"01 02 03 04 05";
playground.d(1): Error: cannot implicitly co
On Saturday, 10 December 2016 at 08:25:49 UTC, Timon Gehr wrote:
On 10.12.2016 09:09, Is it possible to store different generic
This is intended (but surprising, and IMHO bad) behaviour, as D
follows C integral promotion rules. (C# does not.) Mixed
signed/unsigned operations first convert both
On 10.12.2016 09:24, Is it possible to store different generic types? wrote:
On Saturday, 10 December 2016 at 08:21:17 UTC, Stefan Koch wrote:
On Saturday, 10 December 2016 at 08:16:48 UTC, Is it possible to store
different generic types? wrote:
On Saturday, 10 December 2016 at 08:09:00 UTC, Is
On Saturday, 10 December 2016 at 08:23:06 UTC, Ali Çehreli wrote:
On 12/10/2016 12:16 AM, Is it possible to store different
generic types? wrote:
> Okay the issue seem to be that D casts the left-hand argument
to the
> same type as the right-hand argument.
Seems to be but not true. It's more l
On 10.12.2016 09:09, Is it possible to store different generic types? wrote:
I'm pretty sure the following code should work, but it doesn't.
```
bool intersect(ptrdiff_t targetX, ptrdiff_t targetY, size_t targetWidth,
size_t targetHeight, ptrdiff_t x, ptrdiff_t y, size_t width, size_t height)
{
On Saturday, 10 December 2016 at 08:21:17 UTC, Stefan Koch wrote:
On Saturday, 10 December 2016 at 08:16:48 UTC, Is it possible
to store different generic types? wrote:
On Saturday, 10 December 2016 at 08:09:00 UTC, Is it possible
to store different generic types? wrote:
[...]
Okay the issue se
On 12/10/2016 12:16 AM, Is it possible to store different generic types?
wrote:
> Okay the issue seem to be that D casts the left-hand argument to the
> same type as the right-hand argument.
Seems to be but not true. It's more like "anything that touches an
unsigned type turns unsigned". :)
On Saturday, 10 December 2016 at 08:16:48 UTC, Is it possible to
store different generic types? wrote:
On Saturday, 10 December 2016 at 08:09:00 UTC, Is it possible
to store different generic types? wrote:
[...]
Okay the issue seem to be that D casts the left-hand argument
to the same type as t
On Saturday, 10 December 2016 at 08:09:00 UTC, Is it possible to
store different generic types? wrote:
I'm pretty sure the following code should work, but it doesn't.
```
bool intersect(ptrdiff_t targetX, ptrdiff_t targetY, size_t
targetWidth, size_t targetHeight, ptrdiff_t x, ptrdiff_t y,
siz
I'm pretty sure the following code should work, but it doesn't.
```
bool intersect(ptrdiff_t targetX, ptrdiff_t targetY, size_t
targetWidth, size_t targetHeight, ptrdiff_t x, ptrdiff_t y,
size_t width, size_t height)
{
return targetX < x + width &&
x < targetX + targetWidth &&
t
On Wednesday, 13 May 2015 at 20:09:44 UTC, wobbles wrote:
On windows,
core.thread.Sleep (big 'S')
On linux
core.thread.sleep (little 'S')
I'm trying to import as little symbols as possible, so was
importing specific items like
import core.thread : Sleep;
but it fails when I compile on lin
On Wednesday, 13 May 2015 at 20:16:34 UTC, John Chapman wrote:
On Wednesday, 13 May 2015 at 20:09:44 UTC, wobbles wrote:
On windows,
core.thread.Sleep (big 'S')
On linux
core.thread.sleep (little 'S')
I'm trying to import as little symbols as possible, so was
importing specific items like
On Wednesday, 13 May 2015 at 20:09:44 UTC, wobbles wrote:
On windows,
core.thread.Sleep (big 'S')
On linux
core.thread.sleep (little 'S')
I'm trying to import as little symbols as possible, so was
importing specific items like
import core.thread : Sleep;
but it fails when I compile on lin
On windows,
core.thread.Sleep (big 'S')
On linux
core.thread.sleep (little 'S')
I'm trying to import as little symbols as possible, so was
importing specific items like
import core.thread : Sleep;
but it fails when I compile on linux, so I need to do a
version(Windows) import core.thread :
On Sunday, 26 April 2015 at 20:21:32 UTC, Ali Çehreli wrote:
Yes, a bug for floating types only. It seems that not the
common type but the first type is used among floating point
types. I wrote a short program to prove it to myself:
import std.traits;
import std.typetuple;
import std.format;
o real without precision loss, but the
opposite is not true. Is this a bug?
Yes, a bug for floating types only. It seems that not the common type
but the first type is used among floating point types. I wrote a short
program to prove it to myself:
import std.traits;
import std.typetuple;
im
res = test(n);
//Prints "float"
pragma(msg, typeof(res));
}
I expected the result to be real. Why is the return type of test
inferred as float instead? I would expect it to choose real, as
both int and float can be converted to real without precision
loss, but the opposite is not true. Is this a bug?
On Tuesday, 4 November 2014 at 21:20:59 UTC, Tofu Ninja wrote:
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote:
typeof(T)
What is the type of a type?
A kind, of course. =)
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote:
typeof(T)
What is the type of a type?
On Tuesday, 4 November 2014 at 09:54:44 UTC, John Colvin wrote:
On Tuesday, 4 November 2014 at 09:07:10 UTC, deadalnix wrote:
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote:
struct Test(T)
{
static if (is(typeof(T) == int))
{
pragma(msg, "test");
On Tuesday, 4 November 2014 at 09:07:10 UTC, deadalnix wrote:
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote:
struct Test(T)
{
static if (is(typeof(T) == int))
{
pragma(msg, "test");
this(T t)
{
On Tuesday, 4 November 2014 at 09:00:12 UTC, Meta wrote:
struct Test(T)
{
static if (is(typeof(T) == int))
{
pragma(msg, "test");
this(T t)
{
this.t = t;
}
}
}
void ma
On Tuesday, 4 November 2014 at 09:07:10 UTC, deadalnix wrote:
It is not static if, it is is. Is is defined as false for
invalid types.
Ah, right. That's annoyingly hard to spot, but it is not a bug I
suppose.
struct Test(T)
{
static if (is(typeof(T) == int))
{
pragma(msg, "test");
this(T t)
{
this.t = t;
}
}
}
void main()
{
//Nothing is printed
Test!int t;
}
On Thursday, 26 June 2014 at 12:52:54 UTC, hane wrote:
DMD 2.066(git head) compiled both without error.
Thanks for checking!
On Thursday, 26 June 2014 at 13:25:00 UTC, Meta wrote:
Yes, this is a bug. This code should work. If it doesn't
compile with Git HEAD, you should file a bug report.
Apparently it does. I'm not set up to build DMD myself so I'm
always just using the latest release.
On Thursday, 26 June 2014 at 12:38:40 UTC, John Colvin wrote:
On Thursday, 26 June 2014 at 10:09:53 UTC, Rene Zwanenburg
wrote:
I /think/ this is a bug, but I'm not 100% sure. The following
compiles without any problems, as it should:
import std.typecons;
alias Handle(T) = RefCounted!(T, RefC
On Thursday, 26 June 2014 at 10:09:53 UTC, Rene Zwanenburg wrote:
I /think/ this is a bug, but I'm not 100% sure. The following
compiles without any problems, as it should:
import std.typecons;
alias Handle(T) = RefCounted!(T, RefCountedAutoInitialize.no);
auto initialized(T)() if(is(T == Ref
On Thursday, 26 June 2014 at 10:09:53 UTC, Rene Zwanenburg wrote:
I /think/ this is a bug, but I'm not 100% sure. The following
compiles without any problems, as it should:
import std.typecons;
alias Handle(T) = RefCounted!(T, RefCountedAutoInitialize.no);
auto initialized(T)() if(is(T == Ref
On Thursday, 26 June 2014 at 10:09:53 UTC, Rene Zwanenburg wrote:
I /think/ this is a bug, but I'm not 100% sure. The following
compiles without any problems, as it should:
import std.typecons;
alias Handle(T) = RefCounted!(T, RefCountedAutoInitialize.no);
auto initialized(T)() if(is(T == Ref
I /think/ this is a bug, but I'm not 100% sure. The following
compiles without any problems, as it should:
import std.typecons;
alias Handle(T) = RefCounted!(T, RefCountedAutoInitialize.no);
auto initialized(T)() if(is(T == RefCounted!S, S...))
{
T refCounted;
refCounted.refCou
I think I have found the issue.
The problem was a circlular reference in some class that managed
the creation and destruction of PartyAnimals. Now I still don't
know how that triggered the behaviour that I saw, but I do have a
theory. When a certain size of memory is allocated, the GC may
hav
"Nicolas F." wrote in message news:fnamiajuljitahfgv...@forum.dlang.org...
So I've been chasing after this issue for the better part of an hour, and
as I dug deeper, it just got weirder and weirder.
I suggest downloading the latest beta and seeing if that solves your
problem - the bug may h
So I've been chasing after this issue for the better part of an
hour, and as I dug deeper, it just got weirder and weirder.
I have an Interface, let's call it PartyAnimal, and three
classes, one of which is exclusive to unittest.
class Equine is an abstract class that implements some of
PartyA
"H. S. Teoh" writes:
> On Thu, Nov 28, 2013 at 05:11:25PM +0900, Kenji Hara wrote:
>> Might be related?
>> https://d.puremagic.com/issues/show_bug.cgi?id=11406
> [...]
>
> Based on my investigation, I'm pretty sure it's the same bug.
I concur. Compiling with head gives me a working binary for t
On Thu, Nov 28, 2013 at 05:11:25PM +0900, Kenji Hara wrote:
> Might be related?
> https://d.puremagic.com/issues/show_bug.cgi?id=11406
[...]
Based on my investigation, I'm pretty sure it's the same bug.
T
--
Winners never quit, quitters never win. But those who never quit AND never win
are id
Adam D. Ruppe:
It is perfectly valid to pass a string to the write function.
He simply called the wrong function.
Sorry.
Bye,
bearophile
On Friday, 29 November 2013 at 01:37:15 UTC, Adam D. Ruppe wrote:
On Friday, 29 November 2013 at 01:35:31 UTC, bearophile wrote:
A statically typed language should give a compile-time error
for such mistake.
It is perfectly valid to pass a string to the write function.
He simply called the wr
On Friday, 29 November 2013 at 01:35:31 UTC, bearophile wrote:
A statically typed language should give a compile-time error
for such mistake.
It is perfectly valid to pass a string to the write function. He
simply called the wrong function.
On Friday, 29 November 2013 at 01:17:36 UTC, Binarydepth wrote:
So weird I get seg fault. which OS are you using ?
linux
Adam D. Ruppe:
write(" %d: %d\n", bd, an);
This should be writef instead of write. writef uses the format
string, plain write just literally outputs its arguments.
A statically typed language should give a compile-time error for
such mistake. It's a leftover from the weakly typed C mindset
On Friday, 29 November 2013 at 00:40:29 UTC, Adam D. Ruppe wrote:
On Friday, 29 November 2013 at 00:35:30 UTC, Binarydepth wrote:
It compiles but in run time terminal shows a segmentation
fault.
works for me without segfaulting. What data did you input?
write(" %d: %d\n", bd, an);
This sh
On Friday, 29 November 2013 at 00:35:30 UTC, Binarydepth wrote:
It compiles but in run time terminal shows a segmentation fault.
works for me without segfaulting. What data did you input?
write(" %d: %d\n", bd, an);
This should be writef instead of write. writef uses the format
string, pl
Here is my code : It compiles but in run time terminal shows a
segmentation fault. Am I doing something wrong ? Or do I have to
file a Bug ?
import std.stdio : write, readf;
void funcion(int a, int t)
{
int temp, bd, an;
temp=t
Might be related?
https://d.puremagic.com/issues/show_bug.cgi?id=11406
Kenji Hara
2013/11/27 Jerry
> Philippe Sigaud writes:
>
> > No crash on Linux (Kubuntu) 32bits, DMD 2.064.2.
> >
> > Works with 5 or 6 case's also.
>
> This is actually Ubuntu 12.10 64 bit. The last mysterious crash I had
[Taking this back to the forum, if you don't mind, since it seems to be
relevant.]
On Wed, Nov 27, 2013 at 03:36:17PM -0500, Jerry wrote:
> "H. S. Teoh" writes:
>
> > I'm interested in the disassembly of the faulty executable. Maybe
> > you could run `objdump -D $program_name` and send me the ou
On Wed, Nov 27, 2013 at 01:42:04PM -0500, Jerry wrote:
> "deadalnix" writes:
>
> > On Wednesday, 27 November 2013 at 07:09:17 UTC, Jerry wrote:
> >> Philippe Sigaud writes:
> >>
> >>> No crash on Linux (Kubuntu) 32bits, DMD 2.064.2.
> >>>
> >>> Works with 5 or 6 case's also.
> >>
> >> This is ac
"deadalnix" writes:
> On Wednesday, 27 November 2013 at 07:09:17 UTC, Jerry wrote:
>> Philippe Sigaud writes:
>>
>>> No crash on Linux (Kubuntu) 32bits, DMD 2.064.2.
>>>
>>> Works with 5 or 6 case's also.
>>
>> This is actually Ubuntu 12.10 64 bit. The last mysterious crash I had
>> was due to
On Wed, Nov 27, 2013 at 02:06:33AM -0500, Jerry wrote:
> Jerry writes:
>
> > "H. S. Teoh" writes:
> >
> >> On Tue, Nov 26, 2013 at 06:33:28PM -0500, Jerry wrote:
> >>> If I read correctly, the following is legal code. If you comment out
> >>> one of the case statements, it does the expected thi
No crash on Ubuntu 13.10 x86_64 using the dmd 2.064.2 package
downloaded from dlang.org.
No crash on ArchLinux 3.12.0-1-ARCH x86_64 GNU/Linux
On Wednesday, 27 November 2013 at 07:09:17 UTC, Jerry wrote:
Philippe Sigaud writes:
No crash on Linux (Kubuntu) 32bits, DMD 2.064.2.
Works with 5 or 6 case's also.
This is actually Ubuntu 12.10 64 bit. The last mysterious
crash I had
was due to the use of gold vs ld. It seems Debian and
Philippe Sigaud writes:
> No crash on Linux (Kubuntu) 32bits, DMD 2.064.2.
>
> Works with 5 or 6 case's also.
This is actually Ubuntu 12.10 64 bit. The last mysterious crash I had
was due to the use of gold vs ld. It seems Debian and Ubuntu are the
only ones using gold at the moment.
I'm wond
Jerry writes:
> "H. S. Teoh" writes:
>
>> On Tue, Nov 26, 2013 at 06:33:28PM -0500, Jerry wrote:
>>> If I read correctly, the following is legal code. If you comment out
>>> one of the case statements, it does the expected thing. With 4 or more,
>>> it crashes. This is with dmd 2.064.2 on Deb
"H. S. Teoh" writes:
> On Tue, Nov 26, 2013 at 06:33:28PM -0500, Jerry wrote:
>> If I read correctly, the following is legal code. If you comment out
>> one of the case statements, it does the expected thing. With 4 or more,
>> it crashes. This is with dmd 2.064.2 on Debian.
>>
>> If it's a b
No crash on Linux (Kubuntu) 32bits, DMD 2.064.2.
Works with 5 or 6 case's also.
On Tuesday, 26 November 2013 at 23:33:30 UTC, Jerry wrote:
This is with dmd 2.064.2 on Debian.
windows 64 bit no crash.
On Tue, Nov 26, 2013 at 06:33:28PM -0500, Jerry wrote:
> If I read correctly, the following is legal code. If you comment out
> one of the case statements, it does the expected thing. With 4 or more,
> it crashes. This is with dmd 2.064.2 on Debian.
>
> If it's a bug, I'll file a report. Thank
On Wednesday, 27 November 2013 at 00:55:21 UTC, bearophile wrote:
Jerry:
This is with dmd 2.064.2 on Debian.
If it's a bug, I'll file a report. Thanks!
I see no crash on Windows 32 bit.
Bye,
bearophile
No crash on Fedora 19 x86_64
Cheers G.
Jerry:
This is with dmd 2.064.2 on Debian.
If it's a bug, I'll file a report. Thanks!
I see no crash on Windows 32 bit.
Bye,
bearophile
If I read correctly, the following is legal code. If you comment out
one of the case statements, it does the expected thing. With 4 or more,
it crashes. This is with dmd 2.064.2 on Debian.
If it's a bug, I'll file a report. Thanks!
class BB {}
class DD : CC {}
class CC : BB {
static CC crea
Joseph Rushton Wakeling writes:
> On 06/19/2013 04:49 AM, finalpatch wrote:
>> I was testing with DMD 2.063
>
> Try the very latest, 2.063.2 ... ? 2.063 was released on 28 May, my fix got
> committed on 7 June.
>
2.063.2 has the same bug. But good to know it's fixed in git master.
--
finalpat
On Wednesday, June 19, 2013 05:48:13 finalpatch wrote:
> So you are saying this is a bug in std.random?
Yes.
- Jonathan M Davis
On 06/19/2013 03:32 AM, Jonathan M Davis wrote:
> Any function which uses save requires at least a forward range, and if its
> template constraint requires only an input range, then its template
> constraint
> is wrong. _Any_ function whose template constraint does not actually
> guarantee
> t
On 06/19/2013 04:49 AM, finalpatch wrote:
> I was testing with DMD 2.063
Try the very latest, 2.063.2 ... ? 2.063 was released on 28 May, my fix got
committed on 7 June.
On Wednesday, 19 June 2013 at 03:46:11 UTC, Joseph Rushton
Wakeling wrote:
On 06/19/2013 02:56 AM, finalpatch wrote:
in the declaration of RandomSample it only checks for
isInputRange, but in the
implementation it calls the .save() method which is only
available in forward
ranges.
What compi
result this code does not compile:
void main()
{
auto a = File("test.d", "r").byLine();
auto s = randomSample(a,1,5);
writeln(s);
}
Is this a bug or I missed something?
Any function which uses save requires at least a forward range,
and if its
template constraint requires
On 06/19/2013 02:56 AM, finalpatch wrote:
> in the declaration of RandomSample it only checks for isInputRange, but in the
> implementation it calls the .save() method which is only available in forward
> ranges.
What compiler and version are you using? This was reported here:
http://d.puremagic.
oid main()
> {
> auto a = File("test.d", "r").byLine();
> auto s = randomSample(a,1,5);
> writeln(s);
> }
>
> Is this a bug or I missed something?
Any function which uses save requires at least a forward range, and if its
template constraint requires only
ne();
auto s = randomSample(a,1,5);
writeln(s);
}
Is this a bug or I missed something?
On 11 November 2012 19:03, Russel Winder wrote:
> On Sun, 2012-11-11 at 11:17 +, Iain Buclaw wrote:
> […]
>> I'd say feature. If libgphobos was a shared object, I don't believe
>> you would get this.
>
> So the upshot is that we need to indent for libgphobos2.so in order for
> D to be useful
On Sun, 2012-11-11 at 11:17 +, Iain Buclaw wrote:
[…]
> I'd say feature. If libgphobos was a shared object, I don't believe
> you would get this.
So the upshot is that we need to indent for libgphobos2.so in order for
D to be useful in association with Python and ctypes.
I guess the question
On Sunday, 11 November 2012 at 10:39:41 UTC, Russel Winder wrote:
|> gdc -o lib_helloWorld.so -shared helloWorld.os
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a(object_.o):
relocation R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can
not be used when making a shared object; r
On 11 November 2012 10:39, Russel Winder wrote:
>
> |> gdc -o lib_helloWorld.so -shared helloWorld.os
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a(object_.o):
> relocation R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used
> when making a shared object; recompile wi
|> gdc -o lib_helloWorld.so -shared helloWorld.os
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a(object_.o):
relocation R_X86_64_32S against `_D11TypeInfo_Pv6__initZ' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.6/libgphobos2.a:
On Fri, 20 Apr 2012 15:21:12 -0400, Robert Clipsham
wrote:
I've been staring blankly at this for a while now and want some input
from others:
void foo(T, U...)(bool arg)
{
if (arg)
{
assert(T.tupleof.length == U.length);
assert(arg); /* Line 6 */
/
I've been staring blankly at this for a while now and want some input
from others:
void foo(T, U...)(bool arg)
{
if (arg)
{
assert(T.tupleof.length == U.length);
assert(arg); /* Line 6 */
// Or some other code here
}
}
struct A {}
void main()
{
foo!(A
On Wednesday, October 26, 2011 21:05:10 Timon Gehr wrote:
> map!q{ a }(a); fails purity validation too.
> That is possibly a compiler bug.
Quite possibly. I'd have to look at it. There are certainly cases where things
should be pure or should able to be pure but aren't or can't right now, but
th
On 10/26/2011 07:01 PM, Jonathan M Davis wrote:
On Wednesday, October 26, 2011 03:04 bearophile wrote:
Jonathan M Davis:
On Wednesday, October 26, 2011 11:15:20 Gor Gyolchanyan wrote:
I see. But is there any practical advantage of a function being pure?
I mean, besides an optimization hint for
On Wednesday, October 26, 2011 03:04 bearophile wrote:
> Jonathan M Davis:
> > On Wednesday, October 26, 2011 11:15:20 Gor Gyolchanyan wrote:
> > > I see. But is there any practical advantage of a function being pure?
> > > I mean, besides an optimization hint for the compiler, of course.
> >
> >
Jonathan M Davis:
> On Wednesday, October 26, 2011 11:15:20 Gor Gyolchanyan wrote:
> > I see. But is there any practical advantage of a function being pure?
> > I mean, besides an optimization hint for the compiler, of course.
>
> 1. You know that it doesn't access global variables, which is at m
On 10/26/2011 09:15 AM, Gor Gyolchanyan wrote:
I see. But is there any practical advantage of a function being pure?
I mean, besides an optimization hint for the compiler, of course.
It is very useful for reasoning about code, because a pure function will
always behave the same when called wi
On Wednesday, October 26, 2011 11:15:20 Gor Gyolchanyan wrote:
> I see. But is there any practical advantage of a function being pure?
> I mean, besides an optimization hint for the compiler, of course.
1. You know that it doesn't access global variables, which is at minimum an
advantage as far a
I see. But is there any practical advantage of a function being pure?
I mean, besides an optimization hint for the compiler, of course.
On Tue, Oct 25, 2011 at 10:41 PM, Jonathan M Davis wrote:
> On Tuesday, October 25, 2011 10:34 Gor Gyolchanyan wrote:
>> I thought pure functions can't modify th
On Tuesday, October 25, 2011 10:34 Gor Gyolchanyan wrote:
> I thought pure functions can't modify their parameters (along with any
> other non-local variables).
> if the pure function can't modify anything non-local, why should it
> care whether it's getting called from a shared context or not?
No
On 10/25/11 7:34 PM, Gor Gyolchanyan wrote:
I thought pure functions can't modify their parameters (along with any
other non-local variables).
No, pure functions has no effect on how functions can access their
parameters.
David
I thought pure functions can't modify their parameters (along with any
other non-local variables).
if the pure function can't modify anything non-local, why should it
care whether it's getting called from a shared context or not?
On Tue, Oct 25, 2011 at 9:31 PM, Jonathan M Davis wrote:
> On Tuesd
On Tuesday, October 25, 2011 03:13 Gor Gyolchanyan wrote:
> Pure functions don't need synchronization. Pure functions should not
> be a subject to shared-ness.
Why? All it means when a function is pure is that it can't access any static
or module-level variables which can ever be mutated over the
Pure functions don't need synchronization. Pure functions should not
be a subject to shared-ness.
On Tue, Oct 25, 2011 at 2:11 PM, Jonathan M Davis wrote:
> On Tuesday, October 25, 2011 14:08:53 Gor Gyolchanyan wrote:
>> I agree, there's no point in requiring pureness, but this problem must
>> be
On Tuesday, October 25, 2011 14:08:53 Gor Gyolchanyan wrote:
> I agree, there's no point in requiring pureness, but this problem must
> be dealt with anyway. The user must never receive errors regarding
> invalid call of invariants.
Sure, but this issue has nothing to do with purity. It has to do
1 - 100 of 141 matches
Mail list logo
