On 2/6/10 01:25, retard wrote:
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these
{public|protected|package|
private} - I have no effing clue what this does
Jacob Carlborg wrote:
Is there any use to make the base class non public in D? I mean you will
also make the Object part inaccessible. Another thing to remove in D2?
It's possible it's a useless feature. Apparently, nobody has found a use
for it yet in D.
Fri, 05 Feb 2010 02:42:53 +, Stewart Gordon wrote:
Trass3r wrote:
I wonder if an array operation could be reasonably included. It's a
quite common case and there are direct SSE instructions for it since
SSE 4.1.
This would be achieved by adding array aggregate properties, an idea
that
Fri, 05 Feb 2010 03:20:35 -0800, Walter Bright wrote:
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
OK
Some time ago I really
wanted to write a wikibook about D. I also wanted to write a new
compiler. It's just that D is a
What about the simper:
x.dot(y)
x.dot(y) and dot(x,y) are already implementable without language
change.
As is std.numeric.dotProduct(x, y) without language _or_ library change
:o).
That's why I wondered if it could be reasonably included (without
introducing a ton of new stuff to
retard wrote:
The funny thing about D is that if you start writing a book about it,
there's a high desire to change the core features and add more of
them in
the community.
I have started writing a D book in June and have not desired to change
much about the language. I did find the
On 2010-02-05 14:35:20 -0500, Ali Çehreli acehr...@yahoo.com said:
D2 obviously must stabilize before being useful; but it is great that
it moves fast before that happens.
D2 is already useful for small scale projects. I wrote the system to
manage license codes for my Mac shareware (Magic
Walter Bright wrote:
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
You know, the problem with Bugzilla is, that most entries simply remain
unreplied. Especially when they inquire about strange language features
or dark corner
grauzone wrote:
Walter Bright wrote:
retard wrote:
I can easily come up with 100 other such features.
Please do so, and submit them to bugzilla.
You know, the problem with Bugzilla is, that most entries simply remain
unreplied. Especially when they inquire about strange language features
Michel Fortin wrote:
My only wish in relation to that is that SafeD be more
usable.
I know safe D isn't fully implemented, but can you say which missing
part of it you need?
Fri, 05 Feb 2010 11:35:20 -0800, Ali Çehreli wrote:
I did need to change my text only a few times, e.g. when constant-sized
arrays became value types.
You can easily check from the changelogs what happened between dmd 1.00
and 1.056. Quite a lot changed. You could even write a 200 page book
retard wrote:
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing as it does in C++ (with the addition of
package).
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing as it does in C++ (with the addition of
package).
I see. I only
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing as it does in C++ (with the addition of
package).
I see.
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these
{public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing
Walter Bright Wrote:
retard wrote:
{protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing as it does in C++ (with the addition of
package).
I didn't know I could protect a superclass like
retard wrote:
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these
{public|protected|package|
private} - I have no effing clue what this does
It actually does
Walter Bright wrote:
retard wrote:
module m1;
class Foo {
public void bar() {}
}
class Bar : private foo {
}
module m2;
import m1;
void main() {
Foo a = new Bar();
a.bar();
}
// compiles and runs just fine
That's a bug in dmd. It should behave like the C++ does.
It
Ali Çehreli wrote:
It would be different from C++ if everything were in the same module,
right?
Right.
If I understand it correctly, private is not honored for the code in the
same module. Is that for all uses of private?
Yes.
retard wrote:
// compiles and runs just fine
http://d.puremagic.com/issues/show_bug.cgi?id=3774
Chad J:
This reminds me of a discussion we had a year or more ago about offering
abstract operators purely for the purpose of overloading. We can use
things like (+), (*), (-), (), and so on. It'd probably be fine to use
one for dot product.
This looks acceptable as dot product:
x (*) y
but
Before we solve the difficult problem of naming the thing could we first
go through the trivial part of optimizing it under its current name.
http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct
it's not like it couldn't be done in parallel :)
Wed, 03 Feb 2010 20:55:46 +0100, Don wrote:
Trass3r wrote:
I wonder if an array operation could be reasonably included. It's a
quite common case and there are direct SSE instructions for it since
SSE 4.1.
Indeed. The difficult question is, what would the syntax be?
a · b
Trass3r wrote:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
This would be achieved by adding array aggregate properties, an idea
that has cropped up a few times, though I can't seem to find
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Trass3r wrote:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Indeed. The difficult question is, what would the syntax be?
Hello Don,
Trass3r wrote:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Indeed. The difficult question is, what would the syntax be?
Make it an intrinsic?
--
IXOYE
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
--
Michiel Helvensteijn
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
m.helvensteijn.rem...@gmail.com wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better:
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
m.helvensteijn.rem...@gmail.com wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations
Hello bearophile,
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
How about: x.y;
It reads correctly.
OK, bad idea. :)
--
IXOYE
Hello Ellery,
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
m.helvensteijn.rem...@gmail.com wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like
BCS wrote:
Hello Ellery,
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
m.helvensteijn.rem...@gmail.com wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't
Unicode operators are good for Fortress, but not for D.
x.dot(y) is good because it's short and easy to readunderstand.
Another silly possibility:
x ^^^ y
:-)
Bye,
bearophile
Andrei Alexandrescu:
Before we solve the difficult problem of naming the thing could we first
go through the trivial part of optimizing it under its current name.
In this case finding a good syntax before D2 is out of alpha stage is more
important than implementing that efficiently.
The user
Ellery Newcomer wrote:
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
m.helvensteijn.rem...@gmail.com wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't
Michiel Helvensteijn wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
bearophile wrote:
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
x.dot(y) and dot(x,y) are already implementable without language change.
Don wrote:
bearophile wrote:
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
x.dot(y) and dot(x,y) are already implementable without language change.
As is std.numeric.dotProduct(x, y) without language _or_ library change
40 matches
Mail list logo
