/!\ Shameless autopromotion incoming /!\
I have recently put some effort into exploring alternatives to visitor
pattern and see what can be done in D. I ended up with a solution which
is a real improvement compared to plein old visitor pattern and wanted
to share this here.
I think this is
On Monday, 27 August 2012 at 15:00:11 UTC, deadalnix wrote:
the fastCast could probably be faster this way (I didn't
checked / compiled)
private U fastCast (U) (object t) {
return cast(U)(cast(void*)t);
}
one less de/reference.
btw, in your implementation should be (is(T == class) ||
On Monday, 27 August 2012 at 15:00:11 UTC, deadalnix wrote:
/!\ Shameless autopromotion incoming /!\
I have recently put some effort into exploring alternatives to
visitor pattern and see what can be done in D. I ended up with
a solution which is a real improvement compared to plein old
Le 27/08/2012 18:02, Michal Minich a écrit :
On Monday, 27 August 2012 at 15:00:11 UTC, deadalnix wrote:
/!\ Shameless autopromotion incoming /!\
I have recently put some effort into exploring alternatives to visitor
pattern and see what can be done in D. I ended up with a solution
which is a
I missed this post earlier. Congrats, Alex. Truly great work,
I've definitely noticed a big speed improvement in the code
completion of Mono-D over the summer.
On Monday, 27 August 2012 at 16:28:24 UTC, deadalnix wrote:
Le 27/08/2012 18:02, Michal Minich a écrit :
On Monday, 27 August 2012 at 15:00:11 UTC, deadalnix wrote:
/!\ Shameless autopromotion incoming /!\
I have recently put some effort into exploring alternatives
to visitor
pattern and see
Am 27.08.2012 17:00, schrieb deadalnix:
I have recently put some effort into exploring alternatives to visitor
pattern and see what can be done in D. I ended up with a solution which
is a real improvement compared to plein old visitor pattern and wanted
to share this here.
Thanks 4 sharing,
Jan Knepper is going to be upgrading the digitalmars server to new hardware over
the next couple days. This will result in some downtime.
2012/8/27 Walter Bright newshou...@digitalmars.com:
On 8/26/2012 9:25 PM, Chris Cain wrote:
On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright wrote:
What happens with the name mangling? What about overloading? template
type
deduction? type specialization? type equivalence? type
Jonathan M Davis wrote:
On Sunday, August 26, 2012 14:47:38 Jens Mueller wrote:
What is the ref situation?
I thought ref is used as an optimization that allows passing lvalues
more efficiently whereas without ref is needed for rvalues.
ref doesn't necessarily have anything to do with
On 27 August 2012 07:52, Walter Bright newshou...@digitalmars.com wrote:
On 8/26/2012 9:25 PM, Chris Cain wrote:
On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright wrote:
What happens with the name mangling? What about overloading? template
type
deduction? type specialization? type
On Monday, 27 August 2012 at 07:54:12 UTC, Manu wrote:
On 27 August 2012 07:52, Walter Bright
newshou...@digitalmars.com wrote:
On 8/26/2012 9:25 PM, Chris Cain wrote:
On Monday, 27 August 2012 at 04:01:10 UTC, Walter Bright
wrote:
What happens with the name mangling? What about
On 27 August 2012 03:51, Walter Bright newshou...@digitalmars.com wrote:
On 8/26/2012 5:06 PM, Manu wrote:
type that is technically equivalent, but foo's type would have the bonus
default
arg in its type record, just as a function pointer that were declared
explicitly.
That's the way it
On 27 August 2012 11:01, Paulo Pinto pj...@progtools.org wrote:
On Monday, 27 August 2012 at 07:54:12 UTC, Manu wrote:
This sounds like an implementation detail/dmd quirk is defining the
language spec...
For it sounds like constraining the language while keeping the C/C++
linker
On 8/27/2012 1:01 AM, Paulo Pinto wrote:
For it sounds like constraining the language while keeping the C/C++ linker
semantics, instead of using a D aware linker.
That's just one of the problems. And no, we can't go write our own linker on all
platforms.
On 8/27/2012 1:10 AM, Manu wrote:
I don't see how the linker enters into it. Default args are irrelevant to the
linker.
Consider name mangling and what it's for. Now consider two *different* types
mangling to the same name.
D fundamentally depends on a 1:1 correspondence between types and
On 8/26/2012 11:14 PM, Piotr Duda wrote:
Default args should be part of types (for passing them as template
args etc, implicity convertable if they differs only on defaults) but
not mangled in (since mangling is revelant only for linking, where
defaults doesn't matter).
And then there's a list
On Monday, August 27, 2012 08:14:41 Piotr Duda wrote:
Default args should be part of types (for passing them as template
args etc, implicity convertable if they differs only on defaults) but
not mangled in (since mangling is revelant only for linking, where
defaults doesn't matter).
Default
On 8/27/2012 1:08 AM, Manu wrote:
Does the bug report actually demonstrate how it was causing anybody any
problems? It seemed a rather contrived scenario that just illustrated that there
was a bug.
It was probably reduced from a larger scenario. Reduced bugs usually look pretty
twisted.
The mangled names have a 1:1 correspondence with types. A
mangled name can, for example, be reversed into a type.
If default args form part of the type, then they'll have to be
mangled in, too. This causes a rather long list of substantial
problems.
The following has other pervasive
On 27 August 2012 11:12, Jonathan M Davis jmdavisp...@gmx.com wrote:
and it makes no sense to use them with function pointers or function
literals.
If that were true, we wouldn't be having this discussion.
On Monday, August 27, 2012 09:42:34 Jens Mueller wrote:
Aha. I see.
Then we get down from four declarations to two by writing
bool opEquals(const auto ref S rhs) const {...}
and
bool opEquals(auto ref S rhs) {...}
And with inout probably even further:
bool opEquals(inout auto ref S rhs)
2012/8/27 Walter Bright newshou...@digitalmars.com:
On 8/26/2012 11:14 PM, Piotr Duda wrote:
Default args should be part of types (for passing them as template
args etc, implicity convertable if they differs only on defaults) but
not mangled in (since mangling is revelant only for linking,
On 08/27/2012 05:05 AM, Walter Bright wrote:
On 8/26/2012 6:55 PM, Timon Gehr wrote:
On 08/27/2012 02:44 AM, Walter Bright wrote:
On 8/26/2012 4:50 PM, Timon Gehr wrote:
On 08/27/2012 12:41 AM, Walter Bright wrote:
The trouble for function pointers, is that any default args would need
to be
Suppose a function pointer can be called with fewer actual
arguments than the number of parameters in its declaration.
Suppose that when such a call is made, the missing arguments
will always be assigned the default initialization for their
types (default default-arguments!). Now suppose that
On Monday, 27 August 2012 at 08:26:15 UTC, Jonathan M Davis wrote:
On Monday, August 27, 2012 08:14:41 Piotr Duda wrote:
Default args should be part of types (for passing them as
template
args etc, implicity convertable if they differs only on
defaults) but
not mangled in (since mangling is
On Mon, 27 Aug 2012 11:57:45 +0200, Carl Sturtivant sturtiv...@gmail.com
wrote:
Suppose a function pointer can be called with fewer actual arguments
than the number of parameters in its declaration. Suppose that when
such a call is made, the missing arguments will always be assigned the
That's a great idea Carl! You mean something like this:
int sum(int a, int b) {
if( argc == 1 ) b = 1; //default for b if not supplied
return a + b;
}
//...
auto f = sum;
//...
auto x = sum(y); //function pointer call, so fewer args
permitted
oops! last line was supposed to be:
On Monday, 27 August 2012 at 10:12:28 UTC, Simen Kjaeraas wrote:
On Mon, 27 Aug 2012 11:57:45 +0200, Carl Sturtivant
sturtiv...@gmail.com wrote:
Suppose a function pointer can be called with fewer actual
arguments than the number of parameters in its declaration.
Suppose that when such a
On 27 August 2012 11:28, Walter Bright newshou...@digitalmars.com wrote:
On 8/27/2012 1:08 AM, Manu wrote:
Also, I think it could be fixed so the scenario in the bug report worked
as
expected (I still don't understand why it did't work in the first place).
Because the two types were
On 08/27/12 10:24, Walter Bright wrote:
On 8/27/2012 1:10 AM, Manu wrote:
I don't see how the linker enters into it. Default args are irrelevant to the
linker.
Consider name mangling and what it's for. Now consider two *different* types
mangling to the same name.
D fundamentally depends
On Monday, 27 August 2012 at 08:39:01 UTC, Manu wrote:
On 27 August 2012 11:12, Jonathan M Davis jmdavisp...@gmx.com
wrote:
and it makes no sense to use them with function pointers or
function
literals.
If that were true, we wouldn't be having this discussion.
I think that we (at a
On 08/27/2012 10:48 AM, Piotr Duda wrote:
2012/8/27 Walter Bright newshou...@digitalmars.com:
On 8/26/2012 11:14 PM, Piotr Duda wrote:
Default args should be part of types (for passing them as template
args etc, implicity convertable if they differs only on defaults) but
not mangled in (since
extern(C) void function( ref const(Vector2) v0, ref
const(Vector2) v1, ref const(Vector2) v2, ref const(Color)
color = Color.white, BlendMode blendMode = BlendMode.Disabled )
fillTriangle2D;
If function pointers could be called with fewer than the
prototypical number of arguments, and the
Am Fri, 24 Aug 2012 17:49:00 +0200
schrieb d_follower d_follo...@fakemail.com:
But I'd like to see at least one algorithm being implemented
(e.g. CRC32 which currently works with CTFE) as a proof of
concept (and a unit-test).
Proof of concept:
http://dpaste.dzfl.pl/b14e8aad
As you can
On 08/27/12 12:54, Timon Gehr wrote:
On 08/27/2012 10:48 AM, Piotr Duda wrote:
2012/8/27 Walter Bright newshou...@digitalmars.com:
On 8/26/2012 11:14 PM, Piotr Duda wrote:
Default args should be part of types (for passing them as template
args etc, implicity convertable if they differs only
Before we go proposing something like replacing 'new Foo( val )'
with 'Foo.new( val )' ... which is just so Ruby-esque, but that's
okay with me ... we need to consider that 'new' is not used only
for classes. Okay, so presumably structs would work the same
way, but what of, say, arrays? What
On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright wrote:
On 8/26/2012 4:50 PM, Timon Gehr wrote:
On 08/27/2012 12:41 AM, Walter Bright wrote:
The trouble for function pointers, is that any default args
would need
to be part of the type, not the declaration.
They could be made part
Am Mon, 27 Aug 2012 01:49:12 +0300
schrieb Manu turkey...@gmail.com:
Though that said, looking at the API doc for finish(), it appears to
return a dynamic array, not a static array as you say... so ubyte[]
could be used everywhere, and that would be nice and clear?
That's the Digest / OOP
Am Sun, 26 Aug 2012 23:57:24 +0400
schrieb Dmitry Olshansky dmitry.o...@gmail.com:
On 26-Aug-12 19:11, Andrei Alexandrescu wrote: On 8/22/12 8:36 AM,
Dmitry Olshansky wrote:
The discussion around new unified API for digest hash functions
has subdued, just in time as the review period has
On 08/27/2012 01:16 PM, Artur Skawina wrote:
On 08/27/12 12:54, Timon Gehr wrote:
On 08/27/2012 10:48 AM, Piotr Duda wrote:
2012/8/27 Walter Bright newshou...@digitalmars.com:
On 8/26/2012 11:14 PM, Piotr Duda wrote:
Default args should be part of types (for passing them as template
args
On 27 August 2012 14:08, Carl Sturtivant sturtiv...@gmail.com wrote:
extern(C) void function( ref const(Vector2) v0, ref const(Vector2) v1,
ref const(Vector2) v2, ref const(Color) color = Color.white, BlendMode
blendMode = BlendMode.Disabled ) fillTriangle2D;
If function pointers could be
On Monday, August 27, 2012 11:38:52 Manu wrote:
On 27 August 2012 11:12, Jonathan M Davis jmdavisp...@gmx.com wrote:
and it makes no sense to use them with function pointers or function
literals.
If that were true, we wouldn't be having this discussion.
You can't possibly really be using
On Monday, 27 August 2012 at 10:32:28 UTC, Manu wrote:
Because the two types were considered to be the same, only
different.
And how was that a problem? They never interacted in the
example, the
assignments were totally separate, they shouldn't have been
confused.
Just speculating, but it
On Monday, 27 August 2012 at 11:15:36 UTC, Chris Nicholson-Sauls
wrote:
Before we go proposing something like replacing 'new Foo( val
)' with 'Foo.new( val )' ... which is just so Ruby-esque, but
that's okay with me ... we need to consider that 'new' is not
used only for classes. Okay, so
On 08/27/2012 12:32 PM, Manu wrote:
On 27 August 2012 11:28, Walter Bright newshou...@digitalmars.com
mailto:newshou...@digitalmars.com wrote:
On 8/27/2012 1:08 AM, Manu wrote:
Also, I think it could be fixed so the scenario in the bug
report worked as
expected (I
On Monday, 27 August 2012 at 12:14:30 UTC, Manu wrote:
On 27 August 2012 14:08, Carl Sturtivant sturtiv...@gmail.com
wrote:
extern(C) void function( ref const(Vector2) v0, ref
const(Vector2) v1,
ref const(Vector2) v2, ref const(Color) color = Color.white,
BlendMode
blendMode =
On 08/27/2012 02:48 PM, Robert Clipsham wrote:
On Monday, 27 August 2012 at 10:32:28 UTC, Manu wrote:
Because the two types were considered to be the same, only different.
And how was that a problem? They never interacted in the example, the
assignments were totally separate, they shouldn't
I think that the function type and its mangled name must not contain
the default args, then I can agree with Walter at the point.
But, I think the variables of function pointers and delegates still
can have default args as a part of their declarations.
(It will be a part of VarDeclaration, not a
On Fri, 24 Aug 2012 22:01:51 -0400, Chris Nicholson-Sauls
ibisbase...@gmail.com wrote:
On Friday, 24 August 2012 at 14:15:28 UTC, Steven Schveighoffer wrote:
On Fri, 27 Jul 2012 12:48:59 -0400, David Nadlinger s...@klickverbot.at
wrote:
On Friday, 27 July 2012 at 14:56:18 UTC, Gor
On Fri, 24 Aug 2012 13:35:57 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
foreach(bool doRemove, item; container)
{
doRemove = predicate(item);
}
Whoops, should be
foreach(ref bool doRemove, item; container)
-Steve
On 27 August 2012 15:48, Robert Clipsham rob...@octarineparrot.com wrote:
I seem to recall I looked at this issue myself at one point. It goes
something like:
auto foo = (int a = 1) { return a; };
auto bar = (int a) { return a; };
int function(int) is mangled exactly the same as
On Monday, 27 August 2012 at 12:51:48 UTC, F i L wrote:
auto a = Point(int)[].new(5).new(1, 2);
but then, I can see why someone would want the distinction so
it's easier to understand what constructor belongs to the Array.
Either way, I don't see any conflicts with the syntax I
F i L wrote:
auto a = Point(int)[].new(5).new(1, 2);
On second thought, the shorthand might need to require the '[]'
syntax:
auto a = Point(int)[].new(5)
a[].new(1, 2)
// shorthand:
auto a = Point(int)[].new(5)[].new(1, 2);
On 27 August 2012 16:23, kenji hara k.hara...@gmail.com wrote:
I think that the function type and its mangled name must not contain
the default args, then I can agree with Walter at the point.
But, I think the variables of function pointers and delegates still
can have default args as a part
On Monday, 27 August 2012 at 13:44:43 UTC, Manu wrote:
On 27 August 2012 15:48, Robert Clipsham
rob...@octarineparrot.com wrote:
I seem to recall I looked at this issue myself at one point.
It goes
something like:
auto foo = (int a = 1) { return a; };
auto bar = (int a) { return a; };
On Sun, 26 Aug 2012 18:26:40 -0400, Manu turkey...@gmail.com wrote:
I just updated to 2.60 and found errors throughout my code where function
pointers default args no longer work.
*Every single project* I've written in D, 5 projects, don't work anymore,
including my projects at work.
OK, I've
On 27 August 2012 17:03, foobar f...@bar.com wrote:
This discussion is all sorts of wrong. Whoever said that defargs are
metadata (Manu?) was right. Therefore it would make sense to implement a
general metadata facility for D and use *that* for defargs. C++11 has
annotations, so that's the
On 8/27/12 7:34 AM, Manu wrote:
On 27 August 2012 17:03, foobar f...@bar.com mailto:f...@bar.com wrote:
This discussion is all sorts of wrong. Whoever said that defargs are
metadata (Manu?) was right. Therefore it would make sense to
implement a general metadata facility for D and
On 8/27/12 7:03 AM, Manu wrote:
If we can take agreements each other about them, it may be supported.
+1 for Kenji :)
I think the matter here is that we're looking at adding very significant
complexity to the language for a feature with at best minor, marginal
benefits.
Default
On Monday, 27 August 2012 at 13:59:53 UTC, F i L wrote:
F i L wrote:
auto a = Point(int)[].new(5).new(1, 2);
On second thought, the shorthand might need to require the '[]'
syntax:
auto a = Point(int)[].new(5)
a[].new(1, 2)
// shorthand:
auto a =
Era Scarecrow wrote:
Except being somewhat unfamiliar with it, I can only look it
over and go 'huh? what's going on?'.
new being a keyword from C++ for allocate on the heap
immediately makes this whole thing confusing. I would wonder
myself: Is this on the stack or in the heap for the
On 08/27/2012 04:53 PM, Andrei Alexandrescu wrote:
On 8/27/12 7:34 AM, Manu wrote:
On 27 August 2012 17:03, foobar f...@bar.com mailto:f...@bar.com wrote:
This discussion is all sorts of wrong. Whoever said that defargs are
metadata (Manu?) was right. Therefore it would make sense to
On 08/27/2012 03:23 PM, kenji hara wrote:
I think that the function type and its mangled name must not contain
the default args, then I can agree with Walter at the point.
But, I think the variables of function pointers and delegates still
can have default args as a part of their declarations.
On Mon, 27 Aug 2012 09:23:54 -0400, kenji hara k.hara...@gmail.com wrote:
I think that the function type and its mangled name must not contain
the default args, then I can agree with Walter at the point.
But, I think the variables of function pointers and delegates still
can have default args
On 24/08/12 15:57, bearophile wrote:
It's just syntax sugar for a very obscure operation,
It's an operation included in Cilk Plus, I think Intel devs know
enough what they are doing.
And I think code like this is a common need:
if (a[] 0) {
// ...
}
and it's somewhat ambiguous -- is
On 08/27/2012 07:12 AM, Philippe Sigaud wrote:
On Mon, Aug 27, 2012 at 1:00 AM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
test.d(17): Error: tuple index 4 exceeds 1
I just noticed something though, if the order is swapped there's no error:
void main()
{
alias TypeTuple!(int) x;
On 8/27/12, Philippe Sigaud philippe.sig...@gmail.com wrote:
Certainly.
http://d.puremagic.com/issues/show_bug.cgi?id=8593
foobar wrote:
I'd expect something like:
[ ... ]
Ya, you could always have the Array constructor pass on
construction Parameters as well, and I think your examples make
sense.
P.S
I saw in a different language (Nimrod?) the syntax for array!T
is [T] which I like a bit more than D's T[]
On 8/26/12 7:14 AM, Andrei Alexandrescu wrote:
How about this - use auto for code samples, but not for documenting
function return types (except Voldemort)?
Pie-in-the-sky dream: DDOC would advance enough to show a hover hint
over the auto keyword with the computed type.
On 27 August 2012 17:51, Andrei Alexandrescu
seewebsiteforem...@erdani.orgwrote:
On 8/27/12 7:03 AM, Manu wrote:
If we can take agreements each other about them, it may be supported.
+1 for Kenji :)
I think the matter here is that we're looking at adding very significant
complexity
F i L wrote:
foobar wrote:
I'd expect something like:
[ ... ]
Ya, you could always have the Array constructor pass on
construction Parameters as well, and I think your examples make
sense.
On a side note, you could always invoke Arrays, Dynamic Arrays
(Lists), and Associative Arrays
F i L wrote:
On a side note, you could always invoke Arrays, Dynamic Arrays
(Lists), and Associative Arrays (Maps) by name (like every
other object), and use the '[...]' syntax for initializing the
size:
[ ... ]
meh. On second thought, that would be really annoying in some
places. It
On 8/27/12 8:06 AM, Don Clugston wrote:
vote -= int.max;
Beware of wraparound :o).
Andrei
On 08/27/2012 06:27 AM, Steven Schveighoffer wrote:
On Fri, 24 Aug 2012 13:35:57 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
foreach(bool doRemove, item; container)
{
doRemove = predicate(item);
}
Whoops, should be
foreach(ref bool doRemove, item; container)
-Steve
Right,
On 8/27/12 8:46 AM, Manu wrote:
We're not talking about /adding/ anything, we're talking about a bug.
The scenario given in the bug report isn't even theoretically flawed, it
should work fine under the existing design (hence the bug report), but
it seems some design changes may a) make more
On 2012-08-27 17:46, Manu wrote:
Does the dmd implementation define the D language?
No one really knows. It's probably a mix of dmd, dlang.org and TDPL.
--
/Jacob Carlborg
On Monday, 27 August 2012 at 14:53:24 UTC, Andrei Alexandrescu
wrote:
On 8/27/12 7:34 AM, Manu wrote:
On 27 August 2012 17:03, foobar f...@bar.com
mailto:f...@bar.com wrote:
This discussion is all sorts of wrong. Whoever said that
defargs are
metadata (Manu?) was right. Therefore it
On Mon, 27 Aug 2012 13:19:11 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 8/27/12 8:46 AM, Manu wrote:
The feature was obviously intended, someone took the time to put it
there in the first place, and people use it.
It's implementation is apparently not perfect, and
On 8/27/12 11:08 AM, Steven Schveighoffer wrote:
It does. Also, Kenji found a variety of issues that have no clear
solution. I think there's no need for me to argue that features that
almost work are not a good way to go, even though they are useful
when they work.
That's not true, Kenji asked
On Mon, 27 Aug 2012 14:45:54 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 8/27/12 11:08 AM, Steven Schveighoffer wrote:
It does. Also, Kenji found a variety of issues that have no clear
solution. I think there's no need for me to argue that features that
almost work are
On 08/24/2012 12:23 PM, JN wrote:
I feel kinda stupid here, what's wrong with C++ remove_if (
http://www.cplusplus.com/reference/algorithm/remove_if/ )?
you mean something like
c.erase(remove_if(c.begin(), c.end(), predicate), c.end())
?
That actually is the sort of thing one could
On 08/27/2012 12:46 PM, Ellery Newcomer wrote:
On 08/24/2012 12:23 PM, JN wrote:
I feel kinda stupid here, what's wrong with C++ remove_if (
http://www.cplusplus.com/reference/algorithm/remove_if/ )?
you mean something like
c.erase(remove_if(c.begin(), c.end(), predicate), c.end())
?
That
On Friday, 24 August 2012 at 13:57:42 UTC, bearophile wrote:
That code means:
foreach (i; 0 .. a.length) {
if (a[i] 0) {
// ...
}
}
How could this possibly be useful? It's like the loop, but you
lose the index variable. I can't see how you could possibly do
anything with
On Monday, 27 August 2012 at 14:53:57 UTC, F i L wrote:
in C#, you use 'new Type()' for both classes and structs, and
it works fine. In fact, it has some benefit with generic
programming. Plus, it's impossible to completely get away from
having to understand the type, even in C++/D today,
On 8/27/2012 4:46 AM, Timon Gehr wrote:
What is the point?
For that case, there is none, as you should be passing the lambda by alias
rather than by pointer.
On 8/27/2012 3:34 AM, Artur Skawina wrote:
On 08/27/12 10:24, Walter Bright wrote:
On 8/27/2012 1:10 AM, Manu wrote:
I don't see how the linker enters into it. Default args are irrelevant to the
linker.
Consider name mangling and what it's for. Now consider two *different* types
mangling to
Le 27/08/2012 00:41, Walter Bright a écrit :
On 8/26/2012 3:26 PM, Manu wrote:
I just updated to 2.60 and found errors throughout my code where function
pointers default args no longer work.
_Every single project_ I've written in D, 5 projects, don't work anymore,
including my projects at work.
Peter Alexander:
How could this possibly be useful? It's like the loop, but you
lose the index variable. I can't see how you could possibly do
anything with this.
I think this feature is a part of Cilk+. Maybe I have not fully
understood this feature, or maybe some Intel developers are mad
Le 27/08/2012 19:19, Andrei Alexandrescu a écrit :
Does the dmd implementation define the D language?
No, and I wouldn't know why one would think I asserted otherwise.
You didn't, but I'd be foolish to assert otherwise.
On Monday, 27 August 2012 at 20:29:29 UTC, bearophile wrote:
I think in code like this:
if (a[] = 0)
b[] += c[];
The 'b' and 'c' arrays receive the implicit index of the items
of 'a' that aren't negative.
Ok, I can see the use of this, but I find the syntax *very*
confusing.
On 8/27/2012 5:38 AM, Manu wrote:
I don't really care so much HOW it works, only that it does. I think 99% of my
cases would be addressed by the def args living in the variable declaration.
Can you please post a canonical 99% use case that you use? I cannot suggest an
alternative otherwise. I
On 8/27/2012 3:32 AM, Manu wrote:
Well likewise, can you provide an example where, assuming that one bug were
fixed, that the old approach actually caused a problem?
The bug report shows a situation that has a clear presumed behaviour, and could
surely have just been fixed.
Yes, I can make
On 8/27/2012 6:05 AM, Timon Gehr wrote:
On 08/27/2012 02:48 PM, Robert Clipsham wrote:
I seem to recall I looked at this issue myself at one point. It goes
something like:
auto foo = (int a = 1) { return a; };
auto bar = (int a) { return a; };
int function(int) is mangled exactly the
I think that D should be consistent with rules of types
derivation, in particular the pointer one. Two pointer types
should be same if and only if types they pointer are the same.
Breaking this rule would result in language complexity.
In case when default arguments are part of the type,
On 8/27/2012 7:03 AM, foobar wrote:
This discussion is all sorts of wrong. Whoever said that defargs are metadata
(Manu?) was right. Therefore it would make sense to implement a general metadata
facility for D and use *that* for defargs. C++11 has annotations, so that's the
place to start
On 8/27/2012 3:32 AM, Manu wrote:
Here's an advanced trick I use a lot since D doesn't extern to static C++
methods (heavily simplified, this is way out of context):
struct CPPClass
{
this()
{
// not my actual code, but effectively, write 'this' and the C++ method
pointer
On 27 August 2012 23:54, Walter Bright newshou...@digitalmars.com wrote:
On 8/27/2012 7:03 AM, foobar wrote:
This discussion is all sorts of wrong. Whoever said that defargs are
metadata
(Manu?) was right. Therefore it would make sense to implement a general
metadata
facility for D and use
On Monday, 27 August 2012 at 20:29:15 UTC, deadalnix wrote:
That guy just have to rework 5 projects. This is quite a lot of
work.
Obviously, that change have to be done. But you can't just
impose such a change on users. Their agenda isn't synchronized
with D's.
D NEED a better versioning
On Monday, 27 August 2012 at 20:22:47 UTC, Era Scarecrow wrote:
On Monday, 27 August 2012 at 14:53:57 UTC, F i L wrote:
in C#, you use 'new Type()' for both classes and structs, and
it works fine. In fact, it has some benefit with generic
programming. Plus, it's impossible to completely get
1 - 100 of 142 matches
Mail list logo
