Le 03/04/2012 07:38, Nick Sabalausky a écrit :
Regarding this:
http://d.puremagic.com/issues/show_bug.cgi?id=790
I submit that nested functions should be exempt from the usual sequential
visibility rules. (Therefore, mutually recursive nested functions would
become possible.)
Or at the very *l
On 03/04/12 07:38, Nick Sabalausky wrote:
Regarding this:
http://d.puremagic.com/issues/show_bug.cgi?id=790
I submit that nested functions should be exempt from the usual sequential
visibility rules. (Therefore, mutually recursive nested functions would
become possible.)
Or at the very *least*
"James Miller" wrote in message
news:mailman.1324.1333434077.4860.digitalmar...@puremagic.com...
>
> [...]the issue
> is with closures, what values should be visible to the closures?
Personally, I don't much care ATM. Either way has it's pros and cons:
A. Same as right now: The nested function
"Don Clugston" wrote in message
news:jlecab$9gh$1...@digitalmars.com...
>
> If you have type inference of function returns, things can get nasty:
>
> void foo()
> {
> auto b() { return a(); }
> X x = whatever;
> auto a() { return x; }
> }
> Now b actually depends on the declaration
On 03/04/12 11:24, Nick Sabalausky wrote:
"Don Clugston" wrote in message
news:jlecab$9gh$1...@digitalmars.com...
If you have type inference of function returns, things can get nasty:
void foo()
{
auto b() { return a(); }
X x = whatever;
auto a() { return x; }
}
Now b actual
On 2012-04-03 00:08, H. S. Teoh wrote:
Code:
// S.d
struct S {
int x;
this(int _x) { x = _x; }
}
// test.d
class T {
S s;
this(S _s) { s = _s; }
}
void main() {
On 04/03/2012 07:38 AM, Nick Sabalausky wrote:
Regarding this:
http://d.puremagic.com/issues/show_bug.cgi?id=790
I submit that nested functions should be exempt from the usual sequential
visibility rules. (Therefore, mutually recursive nested functions would
become possible.)
Or at the very *l
On 04/03/2012 10:27 AM, Don Clugston wrote:
On 03/04/12 07:38, Nick Sabalausky wrote:
Regarding this:
http://d.puremagic.com/issues/show_bug.cgi?id=790
I submit that nested functions should be exempt from the usual sequential
visibility rules. (Therefore, mutually recursive nested functions wo
On 04/03/2012 08:27 AM, deadalnix wrote:
Le 03/04/2012 00:00, Timon Gehr a écrit :
Making private symbols invisible to other modules or at least excluding
them from symbol clashes is necessary. The current behaviour is not
useful or desirable in any way.
This smells like religious coding to
On 03/04/12 12:32, Timon Gehr wrote:
On 04/03/2012 10:27 AM, Don Clugston wrote:
On 03/04/12 07:38, Nick Sabalausky wrote:
Regarding this:
http://d.puremagic.com/issues/show_bug.cgi?id=790
I submit that nested functions should be exempt from the usual
sequential
visibility rules. (Therefore,
On 3 April 2012 02:37, Caligo wrote:
> I've read **Proposed Changes and Additions**, and I would like to
> comment and ask a few questions if that's okay. BTW, I've used Eigen
> a lot and I see some similarities here, but a direct rewrite may not
> be the best thing because D > C++.
>
> 2. Chan
On 2012-04-03 11:08:38 +, Don Clugston said:
On 03/04/12 12:32, Timon Gehr wrote:
On 04/03/2012 10:27 AM, Don Clugston wrote:
This is asking for a complicated special case. In global scope, order of
declarations doesn't matter. In function scope, order of declarations
always matters.
If y
On 04/03/2012 01:08 PM, Don Clugston wrote:
Y b() { ... }
Y y = b();
X x = ...
Prove that y doesn't depend on x.
Since only function declarations are immune to ordering rules, b cannot
forward reference x.
On Saturday, 10 March 2012 at 08:53:23 UTC, Alex Rønne Petersen
wrote:
In all fairness, a stop-the-world GC in a kernel probably *is*
a horrible idea.
Doesn't kernel always work in a stop-the-world mode?
"Don Clugston" wrote in message
news:jlelnn$tm4$1...@digitalmars.com...
>
> I don't see a way to just declare it as "illegal". How would you detect
> that situation in the general case?
> It's not easy.
>
> Y b() { ... }
> Y y = b();
> X x = ...
>
> Prove that y doesn't depend on x.
We don't *h
I used this link: http://h3.gd/dmedia/?n=Tutorials.SdlGlTutorial1,
but when i execute the build command i'm receiving the following
errors:
c:\d\dmd2\src\ext\derelict\opengl\gl.d(114): use of typedef is
deprecated; use a
lias instead
c:\d\dmd2\src\ext\derelict\opengl\gl.d(114): use of typedef
On 04/03/2012 01:55 PM, Don Clugston wrote:
On 03/04/12 13:35, Timon Gehr wrote:
On 04/03/2012 01:08 PM, Don Clugston wrote:
Y b() { ... }
Y y = b();
X x = ...
Prove that y doesn't depend on x.
Since only function declarations are immune to ordering rules, b cannot
forward reference x.
Bu
"Timon Gehr" wrote in message
news:jlej27$mvi$1...@digitalmars.com...
>
> This is the right way to work around this issue. It works now and does not
> imply any kind of overhead at runtime:
>
> void foo(){
> void a()(){ ... }
> void b() { ... }
> }
>
That's a very simple workaround (al
On 03/04/12 13:35, Timon Gehr wrote:
On 04/03/2012 01:08 PM, Don Clugston wrote:
Y b() { ... }
Y y = b();
X x = ...
Prove that y doesn't depend on x.
Since only function declarations are immune to ordering rules, b cannot
forward reference x.
But there could be another function a() which i
On 03/04/12 13:58, Timon Gehr wrote:
On 04/03/2012 01:55 PM, Don Clugston wrote:
On 03/04/12 13:35, Timon Gehr wrote:
On 04/03/2012 01:08 PM, Don Clugston wrote:
Y b() { ... }
Y y = b();
X x = ...
Prove that y doesn't depend on x.
Since only function declarations are immune to ordering rul
On 03/04/12 13:51, Nick Sabalausky wrote:
"Don Clugston" wrote in message
news:jlelnn$tm4$1...@digitalmars.com...
I don't see a way to just declare it as "illegal". How would you detect
that situation in the general case?
It's not easy.
Y b() { ... }
Y y = b();
X x = ...
Prove that y doesn't
On 04/03/2012 02:00 PM, Nick Sabalausky wrote:
"Timon Gehr" wrote in message
news:jlej27$mvi$1...@digitalmars.com...
This is the right way to work around this issue. It works now and does not
imply any kind of overhead at runtime:
void foo(){
void a()(){ ... }
void b() { ... }
}
Am 03.04.2012 13:52, schrieb DFGH:
I used this link: http://h3.gd/dmedia/?n=Tutorials.SdlGlTutorial1,
but when i execute the build command i'm receiving the following errors:
c:\d\dmd2\src\ext\derelict\opengl\gl.d(114): use of typedef is
deprecated; use a
lias instead
c:\d\dmd2\src\ext\derelict\
On Mon, 02 Apr 2012 08:05:09 -0500, Dmitry Olshansky
wrote:
On 02.04.2012 16:04, Adam D. Ruppe wrote:
On Monday, 2 April 2012 at 09:26:07 UTC, Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say
private protection is that user is never ever able to see(!)
On Tuesday, 3 April 2012 at 13:14:00 UTC, Robert Jacques wrote:
As someone who has implemented a runtime reflection library in
D, it is entirely possible to detect whether a function is
marked private/protected or not using __traits today.
How did you do it? __traits(compiles) is the best I co
Nick Sabalausky:
I submit that nested functions should be exempt from the usual
sequential
visibility rules. (Therefore, mutually recursive nested
functions would
become possible.)
What about static nested functions? This seems a simpler
enhancement request:
import std.stdio;
void main() {
You should at least grab Derelict2 or Derelict3
(https://github.com/aldacron/Derelict3) - both work with dmd2.
Exactly. And then just build your app with rdmd.
On Tuesday, 3 April 2012 at 06:05:04 UTC, Nick Sabalausky wrote:
Whoa, that's fucking awesome! I've always shied away from COM
for anything
other than the boilerplate to init DirectX, but that's
just...wow!
That should be in Phobos!
Most of his code isn't available as it was kind of under
M
On 4/3/12, Adam D. Ruppe wrote:
> is kinda fragile in general since it will swallow unrelated
> errors too.
That's an issue I've noticed recently. msgpack-d allows me to define a
custom serialization routine in my structs/classes, but it has to be a
template. Then msgpack tries to instantiate it
When I try to use a delegate as template parameter and type inference
DMD asserts with this message:
Assertion failed: (!vthis->csym), function toObjFile, file glue.c, line 686.
https://github.com/D-Programming-Language/dmd/blob/master/src/glue.c#L686
I haven't been able to find a reduced test
On Fri, 30 Mar 2012 16:46:19 +0200, Andrei Alexandrescu
wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval means
that he would approve a pull request implementing
On 04/03/2012 02:08 PM, Don Clugston wrote:
On 03/04/12 13:58, Timon Gehr wrote:
On 04/03/2012 01:55 PM, Don Clugston wrote:
On 03/04/12 13:35, Timon Gehr wrote:
On 04/03/2012 01:08 PM, Don Clugston wrote:
Y b() { ... }
Y y = b();
X x = ...
Prove that y doesn't depend on x.
Since only fun
void foo(){
void a()(){ ... }
void b() { ... }
}
That's a very simple workaround (albiet unintuitive - unless I'm just
too
tired right now). It leads me to two questions:
1. How the heck does that work?
Symbol lookup is done upon the first instantiation of the local template.
On Tue, 03 Apr 2012 08:30:25 -0500, Adam D. Ruppe
wrote:
On Tuesday, 3 April 2012 at 13:14:00 UTC, Robert Jacques wrote:
As someone who has implemented a runtime reflection library in
D, it is entirely possible to detect whether a function is
marked private/protected or not using __traits tod
On Tuesday, April 03, 2012 08:23:49 deadalnix wrote:
> Le 02/04/2012 22:59, Simen Kjærås a écrit :
> > On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix wrote:
> >>> Now, there are a number of people very unhappy about this state of
> >>> affairs and
> >>> want private to hide symbols as well (persona
Nothing important, just something I'm curious about:
At least a couple times recently I've come across a certain pattern for
dealing with directed graphs (ones that may have cycles). It seems general
enough that I'm surprised I don't seem to recognize it (but then again, it
has been years since
Hi all,
I just submitted a pull request that makes ddoc generate
cross-references... even for templates!
https://github.com/D-Programming-Language/dmd/pull/865
It would be awesome if you can try it with your projects, see if it's
working properly and doesn't choke. I tried it with phobos and
37 matches
Mail list logo
