Andrei Alexandrescu:
At least we copy with attribution :o).
The good thing is that programming language designs are not yet copyrighted :-)
So D can copy from many languages.
Bye,
bearophile
Time ago I have suggested here (and in the Python newsgroup) to have
automatically defined inside a function a standard name like __func__ that's an
alias of the recursive function name it's contained into, this helps avoid
stating the name of the function two or more times (as the this()
bearophile Wrote:
Time ago I have suggested here (and in the Python newsgroup) to have
automatically defined inside a function a standard name like __func__ that's
an alias of the recursive function name it's contained into, this helps avoid
stating the name of the function two or more
Clemens Wrote:
Why not this?
void foo(int x)
{
void fooImpl(int x, int depth);
{
// ...
}
fooImpl(x, 0);
}
Ah, and I guess you should make fooImpl static if you don't intend to access
foo's x parameter directly.
Andrei Alexandrescu Wrote:
The main idea is to allow creation of noncopyable types by marking
this(this) as @disable.
I must be missing something, but isn't this usually done by making the copy
constructor private?
Clemens wrote:
Andrei Alexandrescu Wrote:
The main idea is to allow creation of noncopyable types by marking
this(this) as @disable.
I must be missing something, but isn't this usually done by making the copy
constructor private?
Well one issue is that in D private has module granularity,
Clemens:
void foo(int x)
{
void fooImpl(int x, int depth);
{
// ...
}
fooImpl(x, 0);
}
OK, I'll use a static nested function then, it's not as clean as adding a
private attribute, but probably there's not enough need to add other features
to the language:
int
Andrei Alexandrescu Wrote:
Clemens wrote:
Andrei Alexandrescu Wrote:
The main idea is to allow creation of noncopyable types by marking
this(this) as @disable.
I must be missing something, but isn't this usually done by making the copy
constructor private?
Well one issue is
bearophile:
OK, I'll use a static nested function then, it's not as clean as adding a
private attribute, but probably there's not enough need to add other
features to the language:
int foo4(int x) {
int foo4inner(int x, depth=0) {
It's not as clean indeed, there's a little bug there!
bearophile Wrote:
Time ago I have suggested here (and in the Python newsgroup) to have
automatically defined inside a function a standard name like __func__ that's
an alias of the recursive function name it's contained into, this helps avoid
stating the name of the function two or more
On Fri, 15 Jan 2010 07:54:56 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
At least we copy with attribution :o).
Andrei
@lol
And yes, it was out loud.
:D
Fri, 15 Jan 2010 03:19:16 -0500, bearophile wrote:
Andrei Alexandrescu:
At least we copy with attribution :o).
The good thing is that programming language designs are not yet
copyrighted :-) So D can copy from many languages.
Language specification documents can be copyrighted even though
Fri, 15 Jan 2010 04:38:19 -0500, bearophile wrote:
Clemens:
void foo(int x)
{
void fooImpl(int x, int depth);
{
// ...
}
fooImpl(x, 0);
}
OK, I'll use a static nested function then, it's not as clean as adding
a private attribute, but probably there's not
retard:
But the private modifier is something that comes from the object oriented
approach.
Yes, I agree, adding private to recursive function attributes is a cute nice
borrowed from the OOP. It beats the other three alternatives I've shown.
Bye,
bearophile
Daniel Murphy:
private struct privateint { int i; alias i this; };
void foo(int x, privateint y = privateint(0))
{
...
}
It's ugly, but should give reasonable error messages.
It looks like giving error messages if it's located in another module. And I
agree, it's ugly. In real code
Fri, 15 Jan 2010 07:10:00 -0500, bearophile wrote:
retard:
But the private modifier is something that comes from the object
oriented approach.
Yes, I agree, adding private to recursive function attributes is a
cute nice borrowed from the OOP. It beats the other three alternatives
I've
retard:
Beats?
Yes, in my opinion it's better than the alternatives. In the end here what I
will use in normal code is the basic strategy of using just comments.
Documentation tools need to be aware of this.
D uses ddoc, as basic solution for this.
Requires compiler patch.
As any solution
Clemens, el 15 de enero a las 04:40 me escribiste:
Andrei Alexandrescu Wrote:
Clemens wrote:
Andrei Alexandrescu Wrote:
The main idea is to allow creation of noncopyable types by marking
this(this) as @disable.
I must be missing something, but isn't this usually done by
bearophile Wrote:
But it also simplifies code, makes it a bit safer, avoiding some possible
bugs both of the original problem and created by the alternative solutions.
What problems does the static inner function idiom create? It's clean, safe,
performant, works with the current language and
Clemens:
What problems does the static inner function idiom create? It's clean, safe,
performant,
Clean: requiring 3-4 extra lines of code and a second name (for the inner
function) is less clean. Generally it's better to minimize the number of names
that you need to invent in a program.
Andrei Alexandrescu wrote:
The main idea is to allow creation of noncopyable types by marking
this(this) as @disable.
Noncopyable types are pivotal for a number of idioms important in
concurrency and elsewhere.
Andrei
IMHO, we could extend existing syntax instead of invent new one.
I
bearophile wrote:
Time ago I have suggested here (and in the Python newsgroup) to have
automatically defined inside a function a standard name like __func__ that's an
alias of the recursive function name it's contained into, this helps avoid
stating the name of the function two or more times
bearophile Wrote:
int foo3(int x, private int depth=0) {
...
foo3(x+1); // OK
foo3(x, depth + 1); // OK
...
}
void main() {
int r = foo3(5); // OK
int r = foo3(5, 1); // Error
int r = foo3(5, 0); // Error
}
Now the programmer is allowed to give/specify the
john foo wrote:
Walter Bright Wrote:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html#delete
Lawrence mentions several uses for it.
So you're copying yet another C++0x feature and renaming it to
attract more positive publicity..
C++0x would have used a different name
Leandro Lucarella wrote:
It would be even more familiar to people coming from C++0x (C++1x! =P)
You may have missed that 0x is the hexadecimal prefix there. How about
C++0xb to be specific. :)
Ali
Hello bearophile,
My recursive functions sometimes need to keep a bit of state, for
example an integer that keeps the current depth of a tree structure
that I'm creating or scanning, normally in D I can define the function
like this:
/// Always use depth=0 at the first call
int foo1(int x,
Jesse Phillips jessekphillip...@gmail.com wrote in message
news:hiqfel$1i3...@digitalmars.com...
bearophile Wrote:
int foo3(int x, private int depth=0) {
...
foo3(x+1); // OK
foo3(x, depth + 1); // OK
...
}
void main() {
int r = foo3(5); // OK
int r = foo3(5, 1); // Error
Ali Çehreli, el 15 de enero a las 11:35 me escribiste:
Leandro Lucarella wrote:
It would be even more familiar to people coming from C++0x (C++1x! =P)
You may have missed that 0x is the hexadecimal prefix there. How
about C++0xb to be specific. :)
I would be even surprised if they
Even the keyword 'auto' is C's defunct 'auto' in C++0x (and I strongly
belive also in D); just because automatic variable and automatically
typed both start with auto. :)
Ali
If I'm not mistaken (surely I am), D's auto keyword is the same as C's. But D
has type inference so we just
Jesse Phillips wrote:
Even the keyword 'auto' is C's defunct 'auto' in C++0x (and I strongly
belive also in D); just because automatic variable and automatically
typed both start with auto. :)
Ali
If I'm not mistaken (surely I am), D's auto keyword is the same as C's.
C's auto is about
On Jan 16, 10 01:01, The Anh Tran wrote:
Andrei Alexandrescu wrote:
The main idea is to allow creation of noncopyable types by marking
this(this) as @disable.
Noncopyable types are pivotal for a number of idioms important in
concurrency and elsewhere.
Andrei
IMHO, we could extend existing
Ali Çehreli, el 15 de enero a las 16:01 me escribiste:
http://www.digitalmars.com/d/2.0/declaration.html#AutoDeclaration
It is news to me that the following works without 'auto':
struct S
{
int i;
this(int i)
{
this.i = i;
}
}
void main()
{
const c
KennyTM~ wrote:
On Jan 16, 10 01:01, The Anh Tran wrote:
Andrei Alexandrescu wrote:
The main idea is to allow creation of noncopyable types by marking
this(this) as @disable.
Noncopyable types are pivotal for a number of idioms important in
concurrency and elsewhere.
Andrei
IMHO, we could
On 01/14/2010 11:38 PM, Simen kjaeraas wrote:
Is there a way to get a list of overloads for a function name in D?
For member functions, there's __traits( getVirtualFunctions, ... ), but
that don't work for free functions.
I'm afraid there is no way. See also this blog:
I've been using the system() function from std.process for some time in Windows
and recently it has stopped working. But it doesn't seem to be a problem with
my source code, dmd, or Windows.
First I thought it might have been changes I made, so I used an old copy of the
source. Then I thought
I also tried an call to execv, and just now checked the return status which was
-1. So I guess that could be used to say, Sorry this program doesn't work,
but I'd like to be able to actually make these calls. I should try std.c.system
shouldn't I?
import std.process;
import std.stdio;
void
http://d.puremagic.com/issues/show_bug.cgi?id=3680
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
http://d.puremagic.com/issues/show_bug.cgi?id=3699
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
http://d.puremagic.com/issues/show_bug.cgi?id=3680
--- Comment #4 from Michel Nolard michel.nol...@gmail.com 2010-01-15 03:13:06
PST ---
Ok. I clearly see your point now, and it is both practical and logical ... and
I agree ! This would be quite an improvement for a lot of situations.
What
http://d.puremagic.com/issues/show_bug.cgi?id=3403
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=2601
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords|ice-on-invalid-code |rejects-valid
http://d.puremagic.com/issues/show_bug.cgi?id=1931
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=2278
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||bary...@smp.if.uj.edu.pl
http://d.puremagic.com/issues/show_bug.cgi?id=1847
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=2630
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Version|unspecified |2.038
http://d.puremagic.com/issues/show_bug.cgi?id=1396
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=1652
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=1117
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||mrmoc...@gmx.de
---
http://d.puremagic.com/issues/show_bug.cgi?id=1914
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
http://d.puremagic.com/issues/show_bug.cgi?id=2127
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
http://d.puremagic.com/issues/show_bug.cgi?id=3680
--- Comment #5 from ibrahim YANIKLAR yanik...@gmail.com 2010-01-15 08:43:21
PST ---
What bothers me is this :
To remove static opCall's completely is another subject...
I will explain that by opening a new issue.
A case which needs
http://d.puremagic.com/issues/show_bug.cgi?id=3680
--- Comment #6 from ibrahim YANIKLAR yanik...@gmail.com 2010-01-15 09:57:39
PST ---
Also this(int a = 0) and static ... opCall(int a = 0) should be prohibited.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
http://d.puremagic.com/issues/show_bug.cgi?id=3709
Summary: Associative array of associative arrays gets confused
Product: D
Version: unspecified
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
http://d.puremagic.com/issues/show_bug.cgi?id=3680
--- Comment #7 from Don clugd...@yahoo.com.au 2010-01-15 11:45:32 PST ---
(In reply to comment #6)
Also this(int a = 0) and static ... opCall(int a = 0) should be
prohibited.
That's bug 3438. I think the underlying issue is, that we need
http://d.puremagic.com/issues/show_bug.cgi?id=2451
David Simcha dsim...@yahoo.com changed:
What|Removed |Added
CC||dsim...@yahoo.com
---
http://d.puremagic.com/issues/show_bug.cgi?id=2451
--- Comment #3 from Andrei Alexandrescu and...@metalanguage.com 2010-01-15
13:16:14 PST ---
Perfect timing, thanks. I just ran into that but had no time to investigate.
The type Tuple!(uint, count, float, distance)[uint] does not work, but the
http://d.puremagic.com/issues/show_bug.cgi?id=3709
Leandro Lucarella llu...@gmail.com changed:
What|Removed |Added
CC||llu...@gmail.com
http://d.puremagic.com/issues/show_bug.cgi?id=856
Alexey Ivanov aifg...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=3710
Summary: Typo in allMembers description?
Product: D
Version: 2.038
Platform: All
URL: http://digitalmars.com/d/2.0/traits.html#TraitsExpress
ion
OS/Version: All
http://d.puremagic.com/issues/show_bug.cgi?id=3711
Summary: Ddoc does not generate nothing if std.stdio is
imported
Product: D
Version: 2.038
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
60 matches
Mail list logo
