Re: Problem with escaping commands in spawProcess().
On Friday, 7 March 2014 at 09:26:27 UTC, Cooler wrote:
import std.process;
int main(string[]){
// Next line will generate error message from cmd.exe
spawnProcess(["cmd.exe", "/C", "echo"]).wait();
return 0;
}
I'm not sure, but maybe file a bug so this gets some attention:
https://issues.dlang.org/enter_bug.cgi?product=D
Re: build dustmite
On Sunday, 9 March 2014 at 12:14:43 UTC, bioifornatics wrote: Firstly build way describe at https://github.com/CyberShadow/DustMite/wiki/Building-DustMite seem to be wrong as dsplit.d was rename as splitter.d Anyone can edit the wiki. But this was fixed now. Secondly build fail take a look behind $ ldc2 -release -w -g -O3 dustmite.d splitter.d -of dustmite splitter.d(262): Error: delegate splitter.DSplitter.__lambda22 function literals cannot be class members splitter.d(284):called from here: (*_error_() From what i can tell line 284 references pull 2824, which was merged just recently. Dustmite likely requires a git-head version of the compiler. Probably an oversight. A pull was made to fix the issue: https://github.com/CyberShadow/DustMite/pull/19 In the future you should really file bugs to the dustmite bug tracker, not D.learn.
Re: ambiguous definition
On Monday, 10 March 2014 at 22:45:36 UTC, Pasqui23 wrote: Hi. I was editing std.string,but when I tried to compile it it game me this error: One of the errors in git-head is: test.d(553): Error: undefined identifier S Check your constraints, isSomeString!S should have been isSomeString!S1 or isSomeString!S2.
Re: sending a delegate through extern (C)
On Thursday, 27 March 2014 at 00:46:33 UTC, Etienne wrote:
Hi,
I'm trying to send a delegate to a modified version of
druntime's GC as follows:
struct GC {
static void onCollect(void* dg)
{
gc_onCollect(cast(void*)dg);
}
There isn't enough information here to extract what's going on in
your code.
Re: Marking a delegate as pure, nothrow, etc.
On Sunday, 13 April 2014 at 18:31:07 UTC, Joseph Rushton Wakeling
wrote:
On 13/04/14 20:28, Joseph Rushton Wakeling wrote:
On 13/04/14 20:10, Dicebot wrote:
I'd actually recommend to put all function attributes after
parameter list even
for normal function declarations. It is not widely accepted
practice but helps
avoid some confusion
It's actually my habitual practice
Incidentally, for _exactly_ the reason you describe. Early in
my D life I got quite confused over the need to write,
const(int) foo() { ... }
and not
const int foo() { ... }
and putting function attributes after is _really_ helpful in
avoiding unhelpful and incorrect comparisons to C/C++
declarations.
Yeah, but then again, putting them first helpful in noticing that
you accidentally wrote it wrong:
//I see anyting wrong here?
const int foo() @safe pure nothrow { ... }
//How about now?
@safe pure nothrow const int foo() { ... }
Personally, I like placing everything on its own line, before.
Re: Marking a delegate as pure, nothrow, etc.
On 13/04/14 20:28, Joseph Rushton Wakeling wrote:
On 13/04/14 20:10, Dicebot wrote:
I'd actually recommend to put all function attributes after parameter list even
for normal function declarations. It is not widely accepted practice but helps
avoid some confusion
It's actually my habitual practice
Incidentally, for _exactly_ the reason you describe. Early in my D life I got
quite confused over the need to write,
const(int) foo() { ... }
and not
const int foo() { ... }
and putting function attributes after is _really_ helpful in avoiding unhelpful
and incorrect comparisons to C/C++ declarations.
Re: Update to TDPL?
On Sunday, 13 April 2014 at 17:00:53 UTC, george wrote: It is nearly 4 years since this fantastic book was written by Andrei. Within this time, D language has improved and changed in many ways. Any chances of an update to this awesome text. What is really needed is two new books: "Effective D" and "D CTFE" -Eric
Re: Marking a delegate as pure, nothrow, etc.
On 13/04/14 20:10, Dicebot wrote: I'd actually recommend to put all function attributes after parameter list even for normal function declarations. It is not widely accepted practice but helps avoid some confusion It's actually my habitual practice, but for whatever reason I tried putting the delegate attributes _first_ when declaring the delegate function parameter, and got concerned by the compiler errors that resulted. It was only after writing my email above that I realized, "Hang on, I didn't try what I usually do for functions," and tried it and found it works. Though I find it a bit dodgy that the order seems to matter only for delegates as function parameters.
Re: Marking a delegate as pure, nothrow, etc.
On Sunday, 13 April 2014 at 18:10:19 UTC, Dicebot wrote:
On Sunday, 13 April 2014 at 18:02:15 UTC, Joseph Rushton
Wakeling wrote:
On 13/04/14 19:58, Joseph Rushton Wakeling wrote:
Is it possible to mark a delegate as pure, @safe, nothrow,
etc.? And if so, how?
... just answered my own question with a bit more
experimentation. The declarations need to come _after_ the
delegate:
void foo(int delegate(int) @safe nothrow pure dg)
{
...
}
I'd actually recommend to put all function attributes after
parameter list even for normal function declarations. It is not
widely accepted practice but helps avoid some confusion:
// `const` does not apply to return param here but to foo itself
const int* foo() { return null; }
// makes it obvious
int* foo() const { return null; }
I agree. The only thing I put before the function is @property
Re: Marking a delegate as pure, nothrow, etc.
On Sunday, 13 April 2014 at 18:02:15 UTC, Joseph Rushton Wakeling
wrote:
On 13/04/14 19:58, Joseph Rushton Wakeling wrote:
Is it possible to mark a delegate as pure, @safe, nothrow,
etc.? And if so, how?
... just answered my own question with a bit more
experimentation. The declarations need to come _after_ the
delegate:
void foo(int delegate(int) @safe nothrow pure dg)
{
...
}
I'd actually recommend to put all function attributes after
parameter list even for normal function declarations. It is not
widely accepted practice but helps avoid some confusion:
// `const` does not apply to return param here but to foo itself
const int* foo() { return null; }
// makes it obvious
int* foo() const { return null; }
Re: Marking a delegate as pure, nothrow, etc.
On Sunday, 13 April 2014 at 17:58:27 UTC, Joseph Rushton Wakeling
wrote:
Is it possible to mark a delegate as pure, @safe, nothrow,
etc.? And if so, how?
If it's while creating a delegate literal, it's valid to mark it
with @safe pure nothrow:
auto n = delegate int() @safe pure nothrow { return 1; };
If it's an already-existing delegate, you can use a cast:
auto m = 0;
auto del = delegate int() @system { throw new Exception("test");
return m; }
cast(int delegate() @safe pure nothrow)del //del is now @safe
pure nothrow
Re: Marking a delegate as pure, nothrow, etc.
On 13/04/14 19:58, Joseph Rushton Wakeling wrote:
Is it possible to mark a delegate as pure, @safe, nothrow, etc.? And if so,
how?
... just answered my own question with a bit more experimentation. The
declarations need to come _after_ the delegate:
void foo(int delegate(int) @safe nothrow pure dg)
{
...
}
Marking a delegate as pure, nothrow, etc.
Is it possible to mark a delegate as pure, @safe, nothrow, etc.? And if so, how?
Re: Update to TDPL?
On Sunday, 13 April 2014 at 17:00:53 UTC, george wrote: It is nearly 4 years since this fantastic book was written by Andrei. Within this time, D language has improved and changed in many ways. Any chances of an update to this awesome text. There is TDPL errata with some updates / fixes : http://erdani.com/tdpl/errata/ Making a completely new revised edition is a major effort though, not sure if Andrei can find that time currently. For most up to date awesomeness I'd put my bet on upcoming D book authored by Adam : http://forum.dlang.org/post/bkwxhqvdcbsybiscu...@forum.dlang.org
Update to TDPL?
It is nearly 4 years since this fantastic book was written by Andrei. Within this time, D language has improved and changed in many ways. Any chances of an update to this awesome text.
alias this and outer
Hello all,
Is there any reason why using,
alias this.outer this;
should not be possible in nested classes? Consider the following example:
//
import std.stdio;
class A
{
class B
{
auto bar() @property
{
return this.outer.n;
}
}
private int n;
public B foo;
this(int n)
{
this.n = n;
this.foo = new B;
}
}
void main()
{
auto a = new A(22);
writeln(a.foo.bar);
}
//
... which works fine; but if I replace the declaration of the nested class B
with,
class B
{
alias this.outer this;
auto bar() @property
{
return n;
}
}
then I get a compiler error:
aliasouter.d(7): Error: semicolon expected to close alias declaration
aliasouter.d(7): Error: found ';' when expecting '('
aliasouter.d(8): Error: function declaration without return type. (Note that
constructors are always named 'this')
aliasouter.d(9): Error: found '{' when expecting ')'
aliasouter.d(10): Error: semicolon expected following function declaration
aliasouter.d(10): Error: Declaration expected, not 'return'
aliasouter.d(23): Error: unrecognized declaration
Is there an actual reason why "alias this.outer this;" should not be allowed (in
which case, surely the error message should be more explicit), or is this a bug?
Thanks and best wishes,
-- Joe
Re: Implicit conversions through purity
Daniel Murphy: It seems reasonable. OK, added: https://issues.dlang.org/show_bug.cgi?id=12573 Bye, bearophile
Re: Implicit conversions through purity
"Jonathan M Davis" wrote in message news:mailman.112.1397351369.5999.digitalmars-d-le...@puremagic.com... Honestly, I would have considered that to be a bug. Converting the return type to a different level of mutability based on purity is one thing. Automatically casting the return value just because the function is pure is another matter entirely. Clearly, it can work, but it seems incredibly sloppy to me. It's not a bug, and it's not another matter entirely - it's the same thing as converting a call expression, just on the inside instead of the outside.
Re: Implicit conversions through purity
"bearophile" wrote in message news:hxdrbyqrhwvuochlh...@forum.dlang.org... Is it possible and a good idea to allow code like the function foo2? It seems reasonable.
Local function overloading
Thanks! I used the static struct solution. I did some quick research, and I think that the reason why the original code doesn't work is because the two functions have the same identifier, which results in Dsymboltable::insert rejecting the second function. I haven't tested this hypothesis, but I suspect this to be the case. A simple solution would be to assign unique identifiers to each function, but I haven't experimented with DMD source enough to determine what the side-effects of such a change would be. Is not being able to overload functions in local scope intended behaviour?
