Andrei Alexandrescu wrote:
> Daniel Keep wrote:
>> ...
>> Of course, most people HATE this method because it requires you to write
>> mountains of boilerplate code. Pity, then, it's also the fastest and
>> most flexible. :P (It's a pity D doesn't have extension methods since
>> then you could
Daniel Keep wrote:
Andrei Alexandrescu wrote:
It would be great if you could contribute to Phobos. Two things I hope
from any replacement (a) works with ranges and ideally outputs ranges,
(b) uses alias functions instead of delegates if necessary.
There's really only one sane way to map XML
== Quote from Daniel Keep (daniel.keep.li...@gmail.com)'s article
> This is basically the only way to map xml parsing to ranges. As for
> CONSUMING ranges, I think that'd be a bad idea for the same reason
> basing IO entirely on ranges is a bad idea.
> The only other use for ranges I can think of
> Andrei Alexandrescu wrote:
>> It would be great if you could contribute to Phobos. Two things I hope
>> from any replacement (a) works with ranges and ideally outputs ranges,
>> (b) uses alias functions instead of delegates if necessary.
There's really only one sane way to map XML parsing to r
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4lsuo$au...@digitalmars.com...
For me, I get a breath of fresh air whenever I get to not write "()". I
can't figure how some are missing it.
Every time I call a parameterless function in D, I curse under my breath at
how i
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Tue, 28 Jul 2009 16:08:58 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
However, when I see:
x.empty;
I can't tell what is implied here.
You can. In either C# or D language it could execute arbitrary code
that yo
== Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
> On Thu, Jul 30, 2009 at 9:35 PM, zsxxsz wrote:
> > Hi, below are the functions from Phobos and Tango with the same use, we can
> > see why so many people like Tango more than Phobos.
> Uh, who exactly are you trying to co
zsxxsz wrote:
Hi, below are the functions from Phobos and Tango with the same use, we can
see why so many people like Tango more than Phobos.
[snip]
We can see the function's performance from Tango is more high than which one
from Phobos. This maybe not the only one function difference. :)
Th
On Thu, Jul 30, 2009 at 9:35 PM, zsxxsz wrote:
> Hi, below are the functions from Phobos and Tango with the same use, we can
> see why so many people like Tango more than Phobos.
Uh, who exactly are you trying to convince?
For that matter, what's the point of this thread?
Michael Rynn wrote:
I did look at the code for the xml module, and posted a suggested bug
fix to the empty elements problem. I do not have access rights to
updating the source repository, and at the time was too busy for this.
Andrei Alexandrescu wrote:
It would be great if you could contribute
zsxxsz wrote:
Hi, below are the functions from Phobos and Tango with the same use, we can
see why so many people like Tango more than Phobos.
In Phobos:
string encode(string s)
{
// The ifs are (temprarily, we hope) necessary, because
// std.string.write.replace
// does not do cop
On 2009-07-30 15:32:58 -0400, "Nick Sabalausky" said:
C# shows us *A* solution. Doesn't mean we can't do one better.
The whole point of properties is that, to the outside observer, they behave,
as much as possible, like plain fields. Obviously this can't be done in all
cases (like getting an i
John C wrote:
Chad J wrote:
John C wrote:
Here's a couple of annoying problems I encounter quite often with D's
properties. Would having some form of property syntax fix them?
1) Array extensions:
class Person {
string name_;
string name() {
return name_;
}
}
auto
Jarrett Billingsley wrote:
The issue is that the compiler accepts
no-effect modifications of temporary values as valid statements.
There is no setter being invoked here, nor should there be.
Or should there? In the face of a value type, should the compiler
rewrite this code as
auto t = a.b();
Chad J wrote:
Steven Schveighoffer wrote:
struct Rectangle
{
float x,y,w,h;
}
class Widget
{
Rectangle _rect;
Rectangle rect() { return _rect; }
Rectangle rect(Rectangle r) { return _rect = r; }
// etc
}
void main()
{
auto widget = new Widget();
// DOES WORK:
a
Hi, below are the functions from Phobos and Tango with the same use, we can
see why so many people like Tango more than Phobos.
>>> In Phobos:
string encode(string s)
{
// The ifs are (temprarily, we hope) necessary, because
// std.string.write.replace
// does not do copy-on-write, bu
Nick Sabalausky wrote:
"Zhenyu Zhou" wrote in message
news:h4rfif$2os...@digitalmars.com...
e.g.
Rectangle rect(Rectangle r) {
_rect = r;
redraw();
return _rect;
}
If you allow
widget.rect.w = 200;
widget.rect.h = 100;
you will have to write much more code to handle the painting correctly.
Chad J wrote:
Chad J wrote:
Bill Baxter wrote:
On Wed, Jul 29, 2009 at 1:14 PM, grauzone wrote:
Chad J wrote:
Thinking about it a little more, the extra temporaries could run you out
of registers. That still sounds like a negligable cost in most code.
Temporaries can be on the stack. That's
How would compete template specialization and matching functions ?
like :
double foo(double x) { return x * 2; }
double foo(T)(T x) { return x * 3; }
double foo(T : double)(T x) { return x * 4; }
writeln(foo(4.0));
bearophile schrieb:
Even if for every person that may ask for such feature, there are probably 30 persons
that may ask for the "stacktrace hack" built-in in DMD
>
That's true :)
My intuition would be that functions are more concrete than templates, and
thus will be checked first.
Will implicit conversions match the same way as exact type matches?
"Ary Borenszweig" wrote in message
news:h4su5p$2ct...@digitalmars.com...
> Nick Sabalausky wrote:
>>
>> C# shows us *A* solution. Doesn't mean we can't do one better.
>>
>> The whole point of properties is that, to the outside observer, they
>> behave, as much as possible, like plain fields. Obv
Reply to Walter,
Currently, that can't be done. But it would be good to get it in for
D2. The question is, what rule to use?
I suggest that:
1. if any functions match, then overload functions the usual way
2. if no functions match, then overload the function templates the
usual way
Or revers
grauzone:
>What for?<
Even if for every person that may ask for such feature, there are probably 30
persons that may ask for the "stacktrace hack" built-in in DMD, I presume such
overload of functions against function templates is more fun to implement :-)
DMD is probably fun-driven too, not ju
Walter Bright:
>Currently, that can't be done. But it would be good to get it in for D2.<
I think someone has already asked for this feature, time ago :-)
> The question is, what rule to use?
> I suggest that:
> 1. if any functions match, then overload functions the usual way
> 2. if no function
Michiel Helvensteijn wrote:
> downs wrote:
>
>> 1) If it's a word, put it in the standard library.
>> 2) Otherwise, put it in the compiler.
>
> What an interesting theory.
>
>> For example:
>>
>> assert() -> library.
>
> Compile-time proof of assertion/contract correctness would be far more
> p
Walter Bright wrote:
Currently, that can't be done. But it would be good to get it in for D2.
What for?
downs wrote:
1) If it's a word, put it in the standard library.
2) Otherwise, put it in the compiler.
for -> compiler.
foreach -> library.
But "for" is a word, while "foreach" isn't! ;-P
Walter Bright wrote:
Compare your car with a Model T. The T is simple, easily repaired,
easily understood. But who wants to drive a T these days compared with
driving a modern car?
It would be the _ultimate_ pimpmobile.
Currently, that can't be done. But it would be good to get it in for D2.
The question is, what rule to use?
I suggest that:
1. if any functions match, then overload functions the usual way
2. if no functions match, then overload the function templates the usual way
Or reverse the priority of
downs wrote:
Walter, of course I didn't intend to criticize your knowledge of your
own compiler; the implied accusation makes me feel bad in retrospect
:p
No reason to feel bad. I'm not insulted :-)
It's just that I feel that D could and should be simpler than it is,
and I'm worried that no a
downs wrote:
Well, I can't really argue with that, but please consider that you
implemented the C++ compiler against a "known set of features", at
least in part, so to speak, whereas DMD grew with the language. An
outsider would face the difficulty of building a reliable C++
compiler, vs. a relia
downs wrote:
> 1) If it's a word, put it in the standard library.
> 2) Otherwise, put it in the compiler.
What an interesting theory.
> For example:
>
> assert() -> library.
Compile-time proof of assertion/contract correctness would be far more
problematic.
> complex -> library.
> void -> C-d
downs wrote:
> Walter Bright wrote:
>> downs wrote:
>>> As it stands, the claim on the homepage that it's easier to implement
>>> a D compiler than a C++ one is highly dubious.
>> Since I'm the only person to have implemented both, I think I'm in a
>> good position to judge that yes, it is easier!
To clarify for a few criticisms that have come up in IRC: this is meant as a
rule of thumb to fall back on where no other considerations are present.
For instance, const and shared are type constructors, and as such hard to do in
the standard library.
To my knowledge, assert() for instance has
language_fan wrote:
> Thu, 30 Jul 2009 21:57:33 +0200, downs thusly wrote:
>
>> As it stands, the claim on the homepage that it's easier to implement a
>> D compiler than a C++ one is highly dubious.
>
> Isn't D simpler to implement than C++ because the template syntax goes
> like !(foo) instead
Walter Bright wrote:
> downs wrote:
>> As it stands, the claim on the homepage that it's easier to implement
>> a D compiler than a C++ one is highly dubious.
>
> Since I'm the only person to have implemented both, I think I'm in a
> good position to judge that yes, it is easier!
Well, I can't re
downs wrote:
As it stands, the claim on the homepage that it's easier to implement
a D compiler than a C++ one is highly dubious.
Since I'm the only person to have implemented both, I think I'm in a
good position to judge that yes, it is easier!
Thu, 30 Jul 2009 21:57:33 +0200, downs thusly wrote:
> As it stands, the claim on the homepage that it's easier to implement a
> D compiler than a C++ one is highly dubious.
Isn't D simpler to implement than C++ because the template syntax goes
like !(foo) instead of ?
Nick Sabalausky wrote:
"Ary Borenszweig" wrote in message
news:h4pn90$307...@digitalmars.com...
Yes they can. And also C# shows us the solution to the problem (similar to
what Walter proposed).
---
public class Bar
{
public Foo Foo { get; set; }
}
public struct Foo
{
public int Prope
In this post, I present a simple rule of thumb that covers most cases of the
common decision: should a feature go in the compiler, or in the standard
library?
Note: this only applies to features that aren't in C.
1) If it's a word, put it in the standard library.
2) Otherwise, put it in the com
Nick Sabalausky wrote:
"Chad J" wrote in message
news:h4oku0$ue...@digitalmars.com...
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
I'd always suspected C# properties did something like this, though it's
been so long since I've used C# now
"Ary Borenszweig" wrote in message
news:h4pn90$307...@digitalmars.com...
>
> Yes they can. And also C# shows us the solution to the problem (similar to
> what Walter proposed).
>
> ---
> public class Bar
> {
> public Foo Foo { get; set; }
> }
>
> public struct Foo
> {
> public int Proper
"Steven Schveighoffer" wrote in message
news:op.uxv89qjieav...@localhost.localdomain...
> On Thu, 30 Jul 2009 14:40:21 -0400, Nick Sabalausky wrote:
>
>> "Chad J" wrote in message
>> news:h4oku0$ue...@digitalmars.com...
>>> Daniel Keep wrote:
Maybe the compiler could rewrite the above
Steven Schveighoffer wrote:
On Thu, 30 Jul 2009 14:40:21 -0400, Nick Sabalausky wrote:
"Chad J" wrote in message
news:h4oku0$ue...@digitalmars.com...
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
I'd always suspected C# properties did
On Thu, 30 Jul 2009 14:40:21 -0400, Nick Sabalausky wrote:
"Chad J" wrote in message
news:h4oku0$ue...@digitalmars.com...
Daniel Keep wrote:
Maybe the compiler could rewrite the above as:
auto t = a.b;
t.c = 3;
a.b = t;
I'd always suspected C# properties did something like this, though
"Steven Schveighoffer" wrote in message
news:op.uxv7r6ndeav...@localhost.localdomain...
> On Thu, 30 Jul 2009 14:09:06 -0400, Nick Sabalausky wrote:
>
>> "Zhenyu Zhou" wrote in message
>> news:h4rfif$2os...@digitalmars.com...
>>>
>>> e.g.
>>> Rectangle rect(Rectangle r) {
>>> _rect = r;
>>> r
"Chad J" wrote in message
news:h4oku0$ue...@digitalmars.com...
> Daniel Keep wrote:
>>
>> Maybe the compiler could rewrite the above as:
>>
>> auto t = a.b;
>> t.c = 3;
>> a.b = t;
>>
>
> I'd always suspected C# properties did something like this, though it's
> been so long since I've used C# now
On Thu, 30 Jul 2009 14:09:06 -0400, Nick Sabalausky wrote:
"Zhenyu Zhou" wrote in message
news:h4rfif$2os...@digitalmars.com...
e.g.
Rectangle rect(Rectangle r) {
_rect = r;
redraw();
return _rect;
}
If you allow
widget.rect.w = 200;
widget.rect.h = 100;
you will have to write much more
"Zhenyu Zhou" wrote in message
news:h4rfif$2os...@digitalmars.com...
>
> e.g.
> Rectangle rect(Rectangle r) {
> _rect = r;
> redraw();
> return _rect;
> }
>
> If you allow
> widget.rect.w = 200;
> widget.rect.h = 100;
> you will have to write much more code to handle the painting correctly.
>
Ary Borenszweig schrieb:
http://d.puremagic.com/issues/show_bug.cgi?id=314
That bug annoys me since 3 years!
It seems like it has been (at least partly) fixed in LDC, that guy even
posted the changesets...
Jesse Phillips schrieb:
Added these to: http://d.puremagic.com/issues/show_bug.cgi?id=3108
That one seems pretty senseless to me.
http://d.puremagic.com/issues/show_bug.cgi?id=314
That bug annoys me since 3 years!
It seems like it was already fixed in LDC, that guy even posted the
changesets
"Walter Bright" wrote in message
news:h4ocet$27...@digitalmars.com...
> The issue is what if b is a property, returns a temporary object, and that
> temp's .c field is uselessly set to 3?
>
> It's a classic problem with properties that are implemented as functions.
>
> I don't see how C#'s spec
Ary Borenszweig wrote:
2. modifiers that don't make sense should be disallowed.
There's been wars about this one. IMO, this is a good thing for writing
templated/generic code -- if a modifier only makes sense in one instance
of a template, all the others should not be marked as errors.
I th
Ary Borenszweig Wrote:
>
> There are several now about protection attributes not working as expected:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=1161
> http://d.puremagic.com/issues/show_bug.cgi?id=1567
> http://d.puremagic.com/issues/show_bug.cgi?id=2225
> http://d.puremagic.com/issues/s
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 15:14:04 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:08:18 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
It would be nice if the compiler could help by simply rejecting
what it can r
Michael Rynn wrote:
On Mon, 27 Jul 2009 20:15:46 -0400, llee wrote:
The std.xml module contains several bugs that need to be fixed. The most important one is that
the parser fails to parse empty elements (IE elements that use the format). I'd like to report this bug to the modules' maintaine
Steven Schveighoffer wrote:
On Thu, 30 Jul 2009 12:17:53 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Thu, 30 Jul 2009 12:04:54 -0400, Ary Borenszweig
wrote:
1. private applied to structs, classes, etc., doesn't have any
effect: I can access them anyway.
2. modifiers tha
On Thu, 30 Jul 2009 12:17:53 -0400, Ary Borenszweig
wrote:
Steven Schveighoffer wrote:
On Thu, 30 Jul 2009 12:04:54 -0400, Ary Borenszweig
wrote:
1. private applied to structs, classes, etc., doesn't have any effect:
I can access them anyway.
2. modifiers that don't make sense should
Steven Schveighoffer wrote:
On Thu, 30 Jul 2009 12:04:54 -0400, Ary Borenszweig
wrote:
1. private applied to structs, classes, etc., doesn't have any effect:
I can access them anyway.
2. modifiers that don't make sense should be disallowed.
I think these are pretty serious bugs (specially t
On Thu, 30 Jul 2009 12:04:54 -0400, Ary Borenszweig
wrote:
1. private applied to structs, classes, etc., doesn't have any effect: I
can access them anyway.
2. modifiers that don't make sense should be disallowed.
I think these are pretty serious bugs (specially the first one). Why new
fe
1. private applied to structs, classes, etc., doesn't have any effect: I
can access them anyway.
2. modifiers that don't make sense should be disallowed.
I think these are pretty serious bugs (specially the first one). Why new
features are added to D and these things are not getting fixed?
On Wed, 29 Jul 2009 18:33:29 -0400, Dimitar Kolev
wrote:
I'm not getting your example...
Different example:
class plane
{
bool fly = false;
bool fly()
{
if (fly == false) return false;
// code for flying.
// If it breaks for some reason
ret
On Wed, 29 Jul 2009 15:14:04 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 14:08:18 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
It would be nice if the compiler could help by simply rejecting what
it can reject (assignment to rvalu
On Wed, 29 Jul 2009 18:27:09 -0400, Chad J
wrote:
Steven Schveighoffer wrote:
On Wed, 29 Jul 2009 15:01:47 -0400, Chad J
wrote:
So we could have semantics that actually work, but you don't want them
because, oh man, my code might have to do a few more assignments. A
few
assignments.
Chad J wrote:
John C wrote:
2) Indexing:
struct Map(K, V) {
void opIndexAssign(V value, K key) { ... }
V opIndex(K key) { ... }
}
class WebClient {
private Map!(string, string) headers_;
Map!(string, string) headers() {
return headers_;
}
}
auto clien
Walter Bright wrote:
> How about #d-lang ?
>
> #dpl ?
I just tested those two.
Although noone else uses #d-lang, it seems that twitter.com
doesn't treat it as a hashtag (because it contains a dash?).
#dpl gives a few false positives.
Chad J wrote:
John C wrote:
Here's a couple of annoying problems I encounter quite often with D's
properties. Would having some form of property syntax fix them?
1) Array extensions:
class Person {
string name_;
string name() {
return name_;
}
}
auto person = getPer
On Thu, 30 Jul 2009 18:03:39 +1000, Michael Rynn
wrote:
corrections..
>I had little trouble in compiling a static library version of the
>Expat 2.01
Whoops, I used an import library to the LibExpat.dll.
>Pity I seen jobs yet offering for D language programmers.
Any jobs in Sydney Australia for D
MIURA Masahiro wrote:
> Is there a common Twitter hashtag for D?
>
> If there isn't any, how about #dlang?
> #D and #DMD give too many false positives,
> #D_programming_language is ridiculously too long.
How about #d-lang ?
#dpl ?
On Mon, 27 Jul 2009 20:15:46 -0400, llee wrote:
>The std.xml module contains several bugs that need to be fixed. The most
>important one is that the parser fails to parse empty elements (IE elements
>that use the format). I'd like to report this bug to the
>modules' maintainer, but I don't kn
Jeremie Pelletier wrote:
Another suggestion would be to have the ?: syntax supported for static
statements, as we're currently forced to use static ifs. It really adds a lot
of code to templates for even simple conditions.
?: already works at compile time, at least in D2. I use it all the ti
Zhenyu Zhou wrote:
> Chad J Wrote:
>> Zhenyu Zhou wrote:
>>> What about:
>>>
>>> class Widget
>>> {
>>> Rectangle _rect;
>>> immutable(Rectangle) rect() const { return _rect; }
>>> Rectangle rect(Rectangle r) { return _rect = r; }
>>> }
>> You'll fall into the trap unless you know about
73 matches
Mail list logo
