On Tuesday, 27 December 2022 at 12:22:45 UTC, Johan wrote:
does semantic analysis (create AST; note that there is a ton of
calls needed to complete SeMa), and finally outputs object code.
If you want to capitalize the word use SemA. ;)
On Monday, 26 December 2022 at 19:13:01 UTC, Alexandru Ermicioi
wrote:
Hi team,
I'd like to ask a lazy question:
How easy is to use D compiler frontend without backend?
How complicated would be to write a transpiler, and from which
files should you start modifications?
I'm wondering if somet
On 27/12/2022 9:34 PM, Alexandru Ermicioi wrote:
Any idea from which file should I start at least learning about this
glue code?
You can look at dmd's... but realistically the work hasn't been done at
that level to make it easy to work with.
https://github.com/dlang/dmd/blob/master/compiler/
On Monday, 26 December 2022 at 23:08:59 UTC, Richard (Rikki)
Andrew Cattermole wrote:
...
That on the other hand... Yeah, things aren't great on that
front. The thing you want to implement is what we call glue
code and isn't really setup right now for this (nobody has
tried like this, ignorin
On 27/12/2022 8:13 AM, Alexandru Ermicioi wrote:
How easy is to use D compiler frontend without backend?
Easy.
https://github.com/dlang/dmd/blob/master/compiler/test/dub_package/frontend.d
How complicated would be to write a transpiler, and from which files
should you start modifications?
On Monday, 20 August 2018 at 19:36:15 UTC, werter wrote:
The code below doesn't work. Is it possible to make a pure
opEquals in a class?
[...]
pure bool opEquals(const A rhs) const
{
return b == rhs.b;
}
It doesn't work
On Wednesday, 6 September 2017 at 06:09:46 UTC, Psychological
Cleanup wrote:
What is the return doing there?
The return implies that the function will return the parameter
`s` after it has done whatever it needs to.
It is useful for the compiler to do escape analysis or
So memset would be s
On 7/11/17 2:12 PM, ag0aep6g wrote:
On 07/10/2017 04:57 PM, ag0aep6g wrote:
alias T = int;
T** f(const T** input) pure
{
T** output;
return output;
}
void main()
{
T i;
T* p = &i;
immutable T** r = f(&p);
}
[...]
Now change `T` to `alias T = immutable int;`.
On 07/10/2017 04:57 PM, ag0aep6g wrote:
alias T = int;
T** f(const T** input) pure
{
T** output;
return output;
}
void main()
{
T i;
T* p = &i;
immutable T** r = f(&p);
}
[...]
Now change `T` to `alias T = immutable int;`. The program gets rejected.
The erro
On 07/10/2017 05:42 PM, drug wrote:
10.07.2017 17:57, ag0aep6g пишет:
[...]
The error message is: "cannot implicitly convert expression (f(& p)) of
type immutable(int)** to immutable(int**)".
[...]
I'm not sure I understand, but
```
immutable (T)** r = f(&p);
```
compiles. So compiler complai
10.07.2017 17:57, ag0aep6g пишет:
I feel like I must be missing something here.
This works:
alias T = int;
T** f(const T** input) pure
{
T** output;
return output;
}
void main()
{
T i;
T* p = &i;
immutable T** r = f(&p);
}
`f` is `pure`, its parameter is const,
On Tuesday, September 13, 2016 20:08:22 Patrick Schluter via Digitalmars-d-
learn wrote:
> On Tuesday, 13 September 2016 at 06:59:10 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, September 13, 2016 03:33:04 Ivy Encarnacion via
> >
> > Digitalmars-d- learn wrote:
> > A pure function cannot call
On 9/13/16 4:08 PM, Patrick Schluter wrote:
On Tuesday, 13 September 2016 at 06:59:10 UTC, Jonathan M Davis wrote:
On Tuesday, September 13, 2016 03:33:04 Ivy Encarnacion via
Digitalmars-d- learn wrote:
A pure function cannot call any function that is not pure [...]
I've read that a lot but
On Tuesday, 13 September 2016 at 06:59:10 UTC, Jonathan M Davis
wrote:
On Tuesday, September 13, 2016 03:33:04 Ivy Encarnacion via
Digitalmars-d- learn wrote:
A pure function cannot call any function that is not pure [...]
I've read that a lot but it's not true. A pure function can call
imp
On Tuesday, September 13, 2016 03:33:04 Ivy Encarnacion via Digitalmars-d-
learn wrote:
> Can pure functions throw exceptions on its arguments? Also, how
> can it perform impure operations?
Yes, as long as the exception's constructor is pure, a pure function can
throw an exception. However, whethe
On Tuesday, 13 September 2016 at 03:33:04 UTC, Ivy Encarnacion
wrote:
Can pure functions throw exceptions on its arguments?
You can throw exceptions for whatever reasons from a function
marked pure:
void foo() pure
{
throw new Exception("nope");
}
void main()
{
foo();
}
Al
On 3/31/16 10:30 AM, Q. Schroll wrote:
On Thursday, 31 March 2016 at 13:51:00 UTC, Steven Schveighoffer wrote:
I think it's a bug. foreach and opApply are specially coded in the
compiler I think, so there's bound to be inconsistencies between them
and normal overload rules.
I have never filed
On Thursday, 31 March 2016 at 13:51:00 UTC, Steven Schveighoffer
wrote:
I think it's a bug. foreach and opApply are specially coded in
the compiler I think, so there's bound to be inconsistencies
between them and normal overload rules.
-Steve
I have never filed a bug report. Should this be r
On 3/31/16 6:23 AM, Q. Schroll wrote:
Simple as that, shouldn't this work?
struct X
{
int opApply(int delegate(string) dg)
{
return dg("impure");
}
int opApply(int delegate(string) pure dg) pure
{
return dg("pure");
}
}
void main()
{
X x;
Heh
immutable Foo foo2 = new Foo("bar"); // compiles
On Wednesday, 1 July 2015 at 12:34:35 UTC, Steven Schveighoffer
wrote:
immutable is probably incorrect without a cast, since immutable
cannot be applied implicitly to non-immutable data, and if the
data is all immutable already, no sense in tagging it immutable.
I really see use in allowing co
On 6/30/15 9:29 PM, Tofu Ninja wrote:
On Wednesday, 1 July 2015 at 00:13:36 UTC, Jesse Phillips wrote:
On Tuesday, 30 June 2015 at 22:23:40 UTC, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer wrote:
Have you tried placing const on the function signature? i.e.:
On Tuesday, 30 June 2015 at 22:23:40 UTC, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer
wrote:
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () const {...
That's how you'd do it (I think, didn't test) if the deleg
On Wednesday, 1 July 2015 at 00:13:36 UTC, Jesse Phillips wrote:
On Tuesday, 30 June 2015 at 22:23:40 UTC, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer
wrote:
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () cons
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer
wrote:
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () const {...
That's how you'd do it (I think, didn't test) if the delegate
context pointer was a class/struct.
-Steve
Nah, says
On 6/30/15 5:44 PM, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 21:31:05 UTC, Steven Schveighoffer wrote:
On 6/30/15 5:23 PM, Tofu Ninja wrote:
On Sunday, 28 June 2015 at 10:19:05 UTC, anonymous wrote:
[...]
Is there any way to annotate the context as const?
const x = 4 ;)
But even if y
On Tuesday, 30 June 2015 at 22:23:40 UTC, Tofu Ninja wrote:
On Tuesday, 30 June 2015 at 22:05:43 UTC, Steven Schveighoffer
wrote:
Have you tried placing const on the function signature? i.e.:
pure int delegate() const d = () const {...
That's how you'd do it (I think, didn't test) if the deleg
On Tuesday, 30 June 2015 at 21:31:05 UTC, Steven Schveighoffer
wrote:
On 6/30/15 5:23 PM, Tofu Ninja wrote:
On Sunday, 28 June 2015 at 10:19:05 UTC, anonymous wrote:
[...]
Is there any way to annotate the context as const?
const x = 4 ;)
But even if you could annotate just the *reference*
On 6/30/15 5:23 PM, Tofu Ninja wrote:
On Sunday, 28 June 2015 at 10:19:05 UTC, anonymous wrote:
[...]
Is there any way to annotate the context as const?
const x = 4 ;)
But even if you could annotate just the *reference* as const, it doesn't
stop foo from changing it as you did in the examp
On Sunday, 28 June 2015 at 10:19:05 UTC, anonymous wrote:
[...]
Is there any way to annotate the context as const?
On Sunday, 28 June 2015 at 09:19:16 UTC, Tofu Ninja wrote:
module main;
import std.stdio;
void main(string[] args)
{
auto d = foo();
writeln(d()); // prints 25
}
auto foo()
{
int x = 4;
pure int delegate() d = delegate()
{
return x*x;
On Sunday, 28 June 2015 at 09:19:16 UTC, Tofu Ninja wrote:
module main;
import std.stdio;
void main(string[] args)
{
auto d = foo();
writeln(d()); // prints 25
}
auto foo()
{
int x = 4;
pure int delegate() d = delegate()
{
return x*x;
On Tuesday, 11 February 2014 at 07:52:57 UTC, Daniel Murphy wrote:
"Jesse Phillips" wrote in message
news:vaatltklsmbmdnabo...@forum.dlang.org...
Wish it would work with @safe and nothrow too, granted writeln
should eventually be @safe/trusted anyway.
I just travelled back in time and gra
"Jesse Phillips" wrote in message
news:vaatltklsmbmdnabo...@forum.dlang.org...
Wish it would work with @safe and nothrow too, granted writeln should
eventually be @safe/trusted anyway.
I just travelled back in time and granted your wish!
int x;
int* p;
void main() pure nothrow @safe
{
On Sunday, 9 February 2014 at 00:18:28 UTC, Nick Sabalausky wrote:
On 2/8/2014 5:30 PM, Adam D. Ruppe wrote:
On Saturday, 8 February 2014 at 22:27:39 UTC, Nick Sabalausky
wrote:
Is there some way to poke enough of a hole in "pure" to get
some
writeln debugging statements in?
literally write
On Sunday, 9 February 2014 at 00:18:28 UTC, Nick Sabalausky wrote:
So I take it purity enforcement is disabled with the -debug
flag? Or is it some sort of hack with writeln?
The debug statement specifically (which is only compiled in when
you use the -debug flag).
debug foo(); will work in a
On 2/8/2014 5:30 PM, Adam D. Ruppe wrote:
On Saturday, 8 February 2014 at 22:27:39 UTC, Nick Sabalausky wrote:
Is there some way to poke enough of a hole in "pure" to get some
writeln debugging statements in?
literally write
debug writeln(..)
abnd it should work in the pure function
Nice!
On Saturday, 8 February 2014 at 22:27:39 UTC, Nick Sabalausky
wrote:
Is there some way to poke enough of a hole in "pure" to get
some writeln debugging statements in?
literally write
debug writeln(..)
abnd it should work in the pure function
On Wednesday, 8 January 2014 at 20:21:22 UTC, John Carter wrote:
> Very well written, a pleasure to read.
And very hard to translate! :)
Leaping off the immediate topic of computer language D into the
realm
of human languages English and Turkish...
With the Sapir–Whorf hypothesis in the b
On Monday, 13 January 2014 at 15:12:21 UTC, Ben Cumming wrote:
On Monday, 13 January 2014 at 14:32:03 UTC, Dicebot wrote:
I don't think 2.064 LDC has been released yet
So I see, thanks.
The "merge-2.064" branch in Git is stable enough already for most
purposes, so if you don't mind building
On Monday, 13 January 2014 at 14:32:03 UTC, Dicebot wrote:
I don't think 2.064 LDC has been released yet
So I see, thanks.
On Monday, 13 January 2014 at 14:18:49 UTC, Ben Cumming wrote:
On Monday, 13 January 2014 at 13:46:26 UTC, Dicebot wrote:
This is the answer. Current LDC is still based on 2.063.2
version of frontend. There have been several tweaks in
`std.conv` to make `to` more pure-friendly between those two
On Monday, 13 January 2014 at 13:46:26 UTC, Dicebot wrote:
This is the answer. Current LDC is still based on 2.063.2
version of frontend. There have been several tweaks in
`std.conv` to make `to` more pure-friendly between those two
releases.
Thanks! I will recompile the latest version of LDC
On Monday, 13 January 2014 at 13:37:05 UTC, Ben Cumming wrote:
Hi There,
I am playing around CTFE, and I get different compile time
behavior with the reference compiler (both 64-bit Linux):
DMD64 D Compiler v2.064
and the LLVM compiler:
LDC - the LLVM D compiler (37ee99): based on DM
On Wednesday, 8 January 2014 at 21:37:24 UTC, Ali Çehreli wrote:
On 01/08/2014 11:39 AM, "Ola Fosheim Grøstad"
> So, "saflik" is "pure" in turkish, cool! I like the sound of
it. 8-D
It is never easy, is it? :)
The reason it is "saflik" in the URL is because file names
better be in ASCII due to
On 01/08/2014 12:20 PM, John Carter wrote:
>>> Very well written, a pleasure to read.
>
>> And very hard to translate! :)
>
> Leaping off the immediate topic of computer language D into the realm
> of human languages English and Turkish...
>
> With the Sapir–Whorf hypothesis in the back of my min
On 01/08/2014 11:39 AM, "Ola Fosheim Grøstad"
" wrote:> On Wednesday, 8 January
2014 at 19:26:28 UTC, Ali Çehreli wrote:
>> And very hard to translate! :) In case a Turkish reader is interested,
>> here is the translation:
>>
>> http://ddili.org/makale/saflik.html
>
>
> So, "saflik" is "pure"
> > Very well written, a pleasure to read.
> And very hard to translate! :)
Leaping off the immediate topic of computer language D into the realm
of human languages English and Turkish...
With the Sapir–Whorf hypothesis in the back of my mind...
What makes it harder to translate?
Is there a hu
On Wednesday, 8 January 2014 at 19:26:28 UTC, Ali Çehreli wrote:
And very hard to translate! :) In case a Turkish reader is
interested, here is the translation:
http://ddili.org/makale/saflik.html
So, "saflik" is "pure" in turkish, cool! I like the sound of it.
8-D
On 01/08/2014 11:09 AM, Paolo Invernizzi wrote:
> This one is a good introduction, or at least the best one I can remember:
>
> http://klickverbot.at/blog/2012/05/purity-in-d/
>
> Very well written, a pleasure to read.
And very hard to translate! :) In case a Turkish reader is interested,
here
On Wednesday, 8 January 2014 at 19:04:24 UTC, John Colvin wrote:
On Wednesday, 8 January 2014 at 18:40:46 UTC, Ola Fosheim
Grøstad wrote:
Is pure meant to be a compiler hint so that it is up to the
programmer to enforce it? It is sometimes useful to maintain
hidden state for lazy evaluation, th
Ola Fosheim Grøstad:
Is pure meant to be a compiler hint so that it is up to the
programmer to enforce it?
Nope, it's enforced by the compiler. (But its rules are not
immediately obvious, there are three kinds of purity, strong,
weak and constant purity, etc). There are several corners cases
On Wednesday, 8 January 2014 at 18:40:46 UTC, Ola Fosheim Grøstad
wrote:
Is pure meant to be a compiler hint so that it is up to the
programmer to enforce it? It is sometimes useful to maintain
hidden state for lazy evaluation, that does not affect purity
optimizations:
e.g.
a = foo(1) // ev
On Thu, Jan 02, 2014 at 04:31:24PM -0800, David Held wrote:
[...]
> I think this is a language defect:
>
> struct Foo
> {
> int computed() pure { return x * y; }
> int wrapper() const { return computed() + 5; }
>
> int x;
> int y;
> }
>
> void main()
> {
> }
>
> src\Bug2.d(4): E
On 2/4/2012 12:45 PM, Timon Gehr wrote:
[...]
Pure does not imply const in D.
[...]
I think this is a language defect:
struct Foo
{
int computed() pure { return x * y; }
int wrapper() const { return computed() + 5; }
int x;
int y;
}
void main()
{
}
src\Bug2.d(4): Error: muta
On 2/4/2012 2:04 PM, Era Scarecrow wrote:
[...]
struct X {
int i;
pure int squaredPlus(int x) {
return x*x + i
}
alias squaredPlus sqp;
}
X st(15);
writeln(st.sqp(0)); //15
int i1 = st.sqp(10); st.i++;
int i2 = st.sqp(10); st.i++;
int i3 = st.sqp(10)
Yup.
That's the answer.
Upgraded to 2.064 and good things happened.
Diff shows flocks of diffs in std.range
Thanks.
On Mon, Dec 23, 2013 at 1:21 PM, Ali Çehreli wrote:
> On 12/22/2013 02:37 PM, John Carter wrote:
>
> > This code compiles and runs OK if I remove the keyword "pure" or if I
>
On 12/22/2013 02:37 PM, John Carter wrote:
> This code compiles and runs OK if I remove the keyword "pure" or if I
> remove the ".retro"
Third option: It compiles and runs OK if you upgrade your compiler. ;)
Works with DMD64 D Compiler v2.065-devel-41ebb59.
Ali
John Carter:
Thanks for all your help understanding the algorithm chaining
problem...
Now I have another gotcha.
This code compiles and runs OK if I remove the keyword "pure"
or if I remove the ".retro"
Some functions can't be pure. Some functions can be pure but in
Phobos are not yet pur
On Wednesday, November 20, 2013 10:20:35 Kenji Hara wrote:
> I opened a new pull request to fix the compiler issue.
>
> https://github.com/D-Programming-Language/dmd/pull/2832
Yay! Go Kenji. I don't know what we'd do without you.
- Jonathan M Davis
On Monday, 18 November 2013 at 19:52:42 UTC, Jonathan M Davis
wrote:
On Monday, November 18, 2013 19:16:11 Daniel Davidson wrote:
On Sunday, 17 November 2013 at 10:56:16 UTC, Jonathan M Davis
wrote:
> I think that the typical approach at this point is to just
> drop
> purity for the
> moment,
On Monday, November 18, 2013 19:16:11 Daniel Davidson wrote:
> On Sunday, 17 November 2013 at 10:56:16 UTC, Jonathan M Davis
>
> wrote:
> > I think that the typical approach at this point is to just drop
> > purity for the
> > moment, but if you want you really want it, you are indeed
> > going to
On Sunday, 17 November 2013 at 10:56:16 UTC, Jonathan M Davis
wrote:
I think that the typical approach at this point is to just drop
purity for the
moment, but if you want you really want it, you are indeed
going to have to
implement it yourself. But we'll get there with Phobos
eventually. Th
On Monday, 18 November 2013 at 07:37:27 UTC, Jonathan M Davis
wrote:
This is middleend optimization stuff, though.
I'm not quite sure what you mean by this. There is no
middle-end. We have the
front-end, which is shared by dmd, gdc, and ldc, and then each
compiler has
its own backend. Anythin
18-Nov-2013 11:37, Jonathan M Davis пишет:
On Monday, November 18, 2013 08:22:37 qznc wrote:
On Sunday, 17 November 2013 at 21:00:16 UTC, Jonathan M Davis
wrote:
will definitely result in multiple calls to pure_func. It's not
that it's
impossible for the compiler to do it - it's perfectly poss
On Monday, November 18, 2013 08:22:37 qznc wrote:
> On Sunday, 17 November 2013 at 21:00:16 UTC, Jonathan M Davis
>
> wrote:
> > will definitely result in multiple calls to pure_func. It's not
> > that it's
> > impossible for the compiler to do it - it's perfectly possible.
> > But doing so
> > wo
On Sunday, 17 November 2013 at 21:00:16 UTC, Jonathan M Davis
wrote:
will definitely result in multiple calls to pure_func. It's not
that it's
impossible for the compiler to do it - it's perfectly possible.
But doing so
would require at least basic code flow analysis, and dmd almost
never does
On 11/17/2013 12:59 PM, Jonathan M Davis wrote:
> On Sunday, November 17, 2013 08:46:49 Ali Çehreli wrote:
>> There is no reason why pure_func(a) cannot be executed only once, right?
>
> The reason would be that the compiler doesn't do flow analysis
Cool. I thought that you meant a technical im
On Sunday, November 17, 2013 08:46:49 Ali Çehreli wrote:
> On 11/17/2013 02:55 AM, Jonathan M Davis wrote:
> > And since additional calls to strongly pure functions are only
>
> optimized out
>
> > within a single expression (or maybe statement - I'm not sure which - but
> > certainly not acro
On 11/17/2013 02:55 AM, Jonathan M Davis wrote:
> And since additional calls to strongly pure functions are only
optimized out
> within a single expression (or maybe statement - I'm not sure which - but
> certainly not across multiple statements), it's not like calls to
strongly
> pure functi
> If you just think about pure as meaning that the function doesn't access any
> mutable global state, then you'll have a much better grasp of pure.
I'll endeavour to keep this in mind :)
> Essentially, it restricts the function to accessing what's passed to it
> directly and to global constants
On Sunday, November 17, 2013 13:53:52 Philippe Sigaud wrote:
> >> But `popFront()` changes an internal state with visible, external
> >> effects: it changes `front` return value and in the end, it will
> >> affect `empty` return value.
> >> So no, I don't consider `popFront` to be pure.
> >
> > No
>> But `popFront()` changes an internal state with visible, external
>> effects: it changes `front` return value and in the end, it will
>> affect `empty` return value.
>> So no, I don't consider `popFront` to be pure.
>
> None of that matters for pure. _All_ that matters for pure is that the
> fun
> On Sunday, November 17, 2013 11:53:57 David Nadlinger wrote:
> That's actually not a reason for them to be impure (see e.g.
> http://klickverbot.at/blog/2012/05/purity-in-d#pure_member_functions
> for my attempt on explaining that).
I'll peruse it, thanks!
On Sunday, November 17, 2013 11:53:57 David Nadlinger wrote:
> On Sunday, 17 November 2013 at 10:33:12 UTC, Philippe Sigaud
>
> wrote:
> > But `popFront()` changes an internal state with visible,
> > external
> > effects: it changes `front` return value and in the end, it will
> > affect `empty` r
On Sunday, November 17, 2013 11:25:33 Philippe Sigaud wrote:
> On Sun, Nov 17, 2013 at 11:17 AM, Jonathan M Davis
wrote:
> >> DMD tells me `foo` cannot use the impure `joiner`, due to
> >> `joiner`'s internal struct (Result) not having pure methods
> >> (`empty`/`front`/`popFront`).
> >>
> >> No
On Sunday, 17 November 2013 at 10:33:12 UTC, Philippe Sigaud
wrote:
But `popFront()` changes an internal state with visible,
external
effects: it changes `front` return value and in the end, it will
affect `empty` return value.
So no, I don't consider `popFront` to be pure.
That's actually not
On Sun, Nov 17, 2013 at 11:17 AM, Jonathan M Davis wrote:
>> DMD tells me `foo` cannot use the impure `joiner`, due to
>> `joiner`'s internal struct (Result) not having pure methods
>> (`empty`/`front`/`popFront`).
>>
>> Now, it seems obvious why these range methods are not pure
>> (`popFront`, a
On Sunday, November 17, 2013 10:05:30 Philippe Sigaud wrote:
> I'm trying to put a bit of `pure` and `const`/`immutable` in my
> code, and I'm getting strange error messages.
>
> Namely, I've a pure function, says `foo` that returns
> `std.algorithm.joiner(someValue)`:
>
> import std.algorithm: j
On Sunday, June 02, 2013 10:52:14 Michael wrote:
> Why pure is keyword, but @safe is attribute?
They're both function attributes. But pure is a keyword and safe got @ tacked
onto the front of it in order to avoid having to create a new keyword. Now, we
have User Defined Attributes which also use
On 23/05/12 11:41, bearophile wrote:
Simen Kjaeraas:
Should this be filed as a bug, or is the plan that only pure functions be
ctfe-able? (or has someone already filed it, perhaps)
It's already in Bugzilla, see issue 7994 and 6169.
It's just happening because the purity checking is currentl
Simen Kjaeraas:
Should this be filed as a bug, or is the plan that only pure
functions be
ctfe-able? (or has someone already filed it, perhaps)
It's already in Bugzilla, see issue 7994 and 6169.
But I think there is a semantic hole in some of the discussions
about this problem. Is a future
Namespace:
So only GDC optimized "pure" functions at all?
I've seen DMD performs some optimizations with "strongly pure"
functions that return integral values.
If you have code like:
int sqr(in int x) pure nothrow { return x * x; }
int y = ...
auto r = sqr(y) + sqr(y);
I think DMD replac
On Friday, 20 April 2012 at 09:55:28 UTC, Timon Gehr wrote:
On 04/20/2012 10:06 AM, Namespace wrote:
The sense of pure functions isn't clear to me.
What is the advantage of pure functions / methods?
1. It enables stateless reasoning about program parts.
2. It enables certain compiler optimizat
On 04/20/2012 10:06 AM, Namespace wrote:
The sense of pure functions isn't clear to me.
What is the advantage of pure functions / methods?
1. It enables stateless reasoning about program parts.
2. It enables certain compiler optimizations.
I inform the compiler with "const" that this method d
On 4/20/2012 3:06 AM, Namespace wrote:
The sense of pure functions isn't clear to me.
What is the advantage of pure functions / methods?
I inform the compiler with "const" that this method does not change the
current object, and therefore he can optimize (at least in C++) this
method. How and wha
On 4/20/12 4:06 PM, Namespace wrote:
The sense of pure functions isn't clear to me.
What is the advantage of pure functions / methods?
I inform the compiler with "const" that this method does not change the
current object, and therefore he can optimize (at least in C++) this
method. How and what
Actually, looks like you have done it already 2 years ago :)
http://d.puremagic.com/issues/show_bug.cgi?id=4505
mist:
> Are there any reasons for this inconsistency?
I don't know. Maybe it's just a parser bug. There are some of those in Bugzilla.
If you don't like it, then I suggest you to add it to D Bugzilla.
Bye,
bearophile
Ok, finally understood.
I was trying to declare hof like this: void f2( pure int
function() param ) , similar to the way I declare usual pure
functions. Looks like it is syntax error and only void f2( int
function() pure param ) is allowed. That led me to false
conclusion, that such signature
On Thursday, February 23, 2012 21:17:46 mist wrote:
> But is there any way to actually say D compiler that I want this
> function to accept only pure delegates?
Mark the delegate type that it accepts as pure.
- Jonathan M Davis
But is there any way to actually say D compiler that I want this
function to accept only pure delegates?
Le 23/02/2012 21:00, mist a écrit :
Hello!
I have been asked few question recently from a Haskell programmer about
D2 and, after experimenting a bit, have found that I really can't
provide a good answe myself, as I am not getting a design limititations
(if any).
Here is the snippet, it is prett
On 02/05/2012 01:20 AM, Era Scarecrow wrote:
the signature I meant looks like
pure int squaredPlus(int)immutable;
Which then the only way you could call it, was if the object itself was
immutable, which is definitely safe (I think). Hmmm...
Alternatively you can use pure int squaredPlus(int
the signature I meant looks like
pure int squaredPlus(int)immutable;
Which then the only way you could call it, was if the object
itself was immutable, which is definitely safe (I think). Hmmm...
On 02/05/2012 12:15 AM, Era Scarecrow wrote:
Probably the restriction was lifted after TDPL was out.
Yes. The compiler will only reorder/run in parallel/optimize if it is
safe (not changing execution semantics). Pure can be used to prove
that certain optimizations are safe. If a pure function
Probably the restriction was lifted after TDPL was out.
Yes. The compiler will only reorder/run in parallel/optimize if
it is safe (not changing execution semantics). Pure can be used
to prove that certain optimizations are safe. If a pure
function only takes const or immutable arguments, th
On 02/04/2012 11:04 PM, Era Scarecrow wrote:
Pure does not imply const in D. If you want stronger guarantees, just
turn 'test' into a const (or immutable) member function. In D, a
function can change anything that is mutable and reachable through its
parameters, this includes the implicit 'this'
Pure does not imply const in D. If you want stronger
guarantees, just turn 'test' into a const (or immutable) member
function. In D, a function can change anything that is mutable
and reachable through its parameters, this includes the
implicit 'this' pointer. The reason for this design is simp
If I'm reading how pure works, my original example was likely
broken as it was part of a struct that returned a state value
(although the contract constraints meaning was still valid).
So is pure fully usable or is it not yet ready? Makes me think
that pure should have further constraints/limi
1 - 100 of 127 matches
Mail list logo
