On Wed, 03 Nov 2010 10:19:27 -0700, Jonathan M Davis wrote:
I would like to point out that the table in the documentation for
std.container is still messed up. Walter, could this be because you
are building the docs using win32.mak? When I build with posix.mak it
looks fine.
-Lars
An
On Mon, 8 Nov 2010 18:13:54 +1000
Daniel Murphy yebbl...@nospamgmail.com wrote:
spir denis.s...@gmail.com wrote in message
news:mailman.157.1289146124.21107.digitalmar...@puremagic.com...
I'd like to know, aside user-side semantics, whether the compiler uses the
in qualifier for efficiency
This way or another, you need a null check. Why extra syntax?
This is also how it is done in those languages no?
They also have null checks at every assignment, but since compiler puts
those lines, you don't know anything.
Maybe this is not what you mean?
--
Using Opera's revolutionary
so Wrote:
At initialization rvalue should not contain anything about
lvalue, this is absurd.
That may well be the case.
I was only pointing out that as far as the Microsoft
compiler is concerned, saying the code:
'compiles with no warning, no error, nothing...'
is incorrect. It
On Monday 08 November 2010 00:03:55 spir wrote:
On Mon, 8 Nov 2010 18:13:54 +1000
Daniel Murphy yebbl...@nospamgmail.com wrote:
spir denis.s...@gmail.com wrote in message
news:mailman.157.1289146124.21107.digitalmar...@puremagic.com...
I'd like to know, aside user-side semantics, whether
Eric Poggel dnewsgro...@yage3d.net wrote:
On 11/6/2010 6:50 AM, bearophile wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse
of this is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language
will probably
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 11/7/10 4:21 PM, bearophile wrote:
Andrei Alexandrescu:
And what was exactly the claim that was wrong?
That there is no need of compiler syntax support to implement good
enough nonnullable reference types in D.
The only
On 2010-11-08 02:13, Andrei Alexandrescu wrote:
On 11/7/10 2:40 PM, Stewart Gordon wrote:
On 03/11/2010 03:06, Daniel Murphy wrote:
bearophilebearophileh...@lycos.com wrote in message
news:iaqbsb$1d3...@digitalmars.com...
Is it correct for immutable struct fields to act like enum or static
On Mon, 08 Nov 2010 12:08:01 +0300, Simen kjaeraas
simen.kja...@gmail.com wrote:
Eric Poggel dnewsgro...@yage3d.net wrote:
On 11/6/2010 6:50 AM, bearophile wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse
of this is impractical and is bad design.
I have just added a issue about class/struct attribute hiding:
http://d.puremagic.com/issues/show_bug.cgi?id=5187
In C# this code generates a warning:
public class Foo {
public int x = 10;
}
public class Test : Foo {
public int x = 20; // warning
public static void Main() {}
}
Simen kjaeraas:
Context-sensitive constructor disabling is a theoretical possibility, but
seems to me to conflict with D's other goals.
It's time to update those goals.
Bye,
bearophile
On Mon, 8 Nov 2010 11:48:20 +0100
spir denis.s...@gmail.com wrote:
[...]
A third point to solve is the one of recursive patterns (self-, mutual,
circular, recursion). The issue is indeed that patterns must be defined in
order, which is not possible in case of recursion. A side issue is that
On Monday 08 November 2010 01:10:07 Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 11/7/10 4:21 PM, bearophile wrote:
Andrei Alexandrescu:
And what was exactly the claim that was wrong?
That there is no need of compiler syntax support to implement
so Wrote:
This way or another, you need a null check. Why extra syntax?
This is also how it is done in those languages no?
They also have null checks at every assignment, but since compiler puts
those lines, you don't know anything.
Maybe this is not what you mean?
Do you care about
Jonathan M Davis jmdavisp...@gmx.com wrote:
??? Structs have no default constructor.
True. Disabling the default constructor here means that
struct Foo{
@disable this();
}
Foo f;
should halt compilation at Foo f;, and certain other places where a
default constructor would normally be
bearophile Wrote:
Simen kjaeraas:
Context-sensitive constructor disabling is a theoretical possibility, but
seems to me to conflict with D's other goals.
It's time to update those goals.
I studied the situation further. Now I've decided to leave D. I tried to cope
with all overly
On Thu, 04 Nov 2010 10:20:28 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
There is also the issue of a cryptic error message. Cyclic dependency
in module test gives you almost no information. This is an issue I
hope to solve, when I have some spare time. I have already tried
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Thu, 04 Nov 2010 10:20:28 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
There is also the issue of a cryptic error message. Cyclic dependency
in module test gives you almost no information. This is an issue I
On Mon, 08 Nov 2010 10:06:11 -0500, Iain Buclaw ibuc...@ubuntu.com wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Thu, 04 Nov 2010 10:20:28 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
There is also the issue of a cryptic error message. Cyclic
spir wrote:
What do you think of this solution?
A solution for what problem? I.e.: I do not see any solution for the
inherent ambiguity of PEGs.
-manfred
steveh Wrote:
bearophile Wrote:
Simen kjaeraas:
Context-sensitive constructor disabling is a theoretical possibility, but
seems to me to conflict with D's other goals.
It's time to update those goals.
I studied the situation further. Now I've decided to leave D. I tried to
Intensive test suites guarantee safety and quality. An extreme version of TDD.
sounds good, but strong typesystem pissed poeple normaly don't tend to
write such suit code - they just talk about writing it
and btw: TDD means Test Driven Development, but in real life it seems to
be Trial
steveh wrote:
less types = better
Then no types are best?
Do have some fun with assembler.
-manfred
Jonathan M Davis Wrote:
[...]
So, if you alter the elements of that array, it alters the elements of
the array that was passed in. However, if you alter the arrays size,
causing it to have to re-allocate memory, then that array is going to
be pointing to a different block of memory, and it
On Mon, 08 Nov 2010 20:30:03 +0300, Jens Mueller jens.k.muel...@gmx.de
wrote:
Hi,
I do not understand what's going on behind the scene with this code. Or
better said I have some idea but maybe I do not see the whole point.
void foo(int[] array) {
array.length += 1000; // may copy
Jens Mueller:
I find this behavior rather strange.
I don't know if it's strange, but surely it is a little bug-prone corner of D.
I have had two or three bugs in my code because of that.
Arrays are neither passed by value
(copying the whole array) nor by reference.
They are passed by fat
On Mon, 08 Nov 2010 19:30:03 +0200, Jens Mueller jens.k.muel...@gmx.de
wrote:
I find this behavior rather strange. Arrays are neither passed by value
(copying the whole array) nor by reference. I see reasons for doing it
like this, e.g. doing array = array[1..$] inside should not affect the
On Monday, November 08, 2010 05:01:57 Simen kjaeraas wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote:
??? Structs have no default constructor.
True. Disabling the default constructor here means that
struct Foo{
@disable this();
}
Foo f;
should halt compilation at Foo f;, and
bearophile wrote:
In practice on average my small Python programs are less buggy than my small D
ones.
One's experience with a particular language can have a very strong influence on
how buggy one's code is.
D's type system is also designed for large systems. For small programs, static
On Monday, November 08, 2010 08:43:20 Pillsy wrote:
Jonathan M Davis Wrote:
[...]
So, if you alter the elements of that array, it alters the elements of
the array that was passed in. However, if you alter the arrays size,
causing it to have to re-allocate memory, then that array is going
Vladimir Panteleev schrieb:
On Mon, 08 Nov 2010 19:30:03 +0200, Jens Mueller jens.k.muel...@gmx.de
wrote:
I find this behavior rather strange. Arrays are neither passed by value
(copying the whole array) nor by reference. I see reasons for doing it
like this, e.g. doing array = array[1..$]
On Sunday, November 07, 2010 18:42:08 Adam Burton wrote:
1. Default struct constructor.
This means the NN can be created without assigning a value. I have tried to
get around this issue somewhat by adding a null check in the invariant but
it seems the invariant is not called when using the
Jonathan M Davis wrote:
On Monday, November 08, 2010 05:01:57 Simen kjaeraas wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote:
??? Structs have no default constructor.
True. Disabling the default constructor here means that
struct Foo{
@disable this();
}
Foo f;
should halt compilation
I studied the situation further. Now I've decided to leave D. I tried to
cope with all overly complex type system quirks, but have had enough of
it now. These two months with D truly opened my eyes. It means I won't
touch C++ or Java either.
My next goal is to use an untyped (less types =
On Monday, November 08, 2010 10:06:35 Walter Bright wrote:
Jonathan M Davis wrote:
I was not aware of that. I didn't think that you could do that for
structs since default constructors are illegal in the first place. It
would likely have the negative side effect of making it illegal to put
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2 (while
in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natural to manipulate. It also
segues nicely into hopeful future support for the CPU's vector instructions.
Jonathan M Davis jmdavisp...@gmx.com wrote:
I was not aware of that. I didn't think that you could do that for
structs since
default constructors are illegal in the first place.
And you can't. That doesn't mean it can't be possible in the future.
It would likely have the
negative side
Walter Bright schrieb:
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2 (while
in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natural to manipulate. It
also segues nicely into hopeful future support for the CPU's vector
On Monday, November 08, 2010 09:40:47 bearophile wrote:
Jens Mueller:
I find this behavior rather strange.
I don't know if it's strange, but surely it is a little bug-prone corner of
D. I have had two or three bugs in my code because of that.
I don't know. I find it to be pretty
On Mon, 08 Nov 2010 13:35:38 -0500, Daniel Gibson metalcae...@gmail.com
wrote:
bearophile schrieb:
Jens Mueller:
I find this behavior rather strange.
I don't know if it's strange, but surely it is a little bug-prone
corner of D. I have had two or three bugs in my code because of that.
On Monday, November 08, 2010 10:46:52 Pillsy wrote:
Jonathan M Davis wrote:
On Monday, November 08, 2010 08:43:20 Pillsy wrote:
The length property of an array shouldn't be directly mutable,
and you shouldn't be able to append onto the end of a dynamic
array, because it can cause some
Jonathan M Davis schrieb:
On Monday, November 08, 2010 10:35:38 Daniel Gibson wrote:
bearophile schrieb:
Jens Mueller:
I find this behavior rather strange.
I don't know if it's strange, but surely it is a little bug-prone corner
of D. I have had two or three bugs in my code because of that.
On Mon, 08 Nov 2010 14:19:47 -0500, Pillsy pillsb...@gmail.com wrote:
Steven Schveighoffer Wrote:
On Mon, 08 Nov 2010 13:46:52 -0500, Pillsy pillsb...@gmail.com
wrote:
Besides, isn't catenating or appending in place impossible with D's
(immutable) strings anyway?
This is a
On Mon, 08 Nov 2010 14:22:36 -0500, Ali Çehreli acehr...@yahoo.com wrote:
Steven Schveighoffer wrote:
On Mon, 08 Nov 2010 13:35:38 -0500, Daniel Gibson
If you pass a dynamic array to a function and chance it's size within
the function, you have undefined behaviour - you never know if it
On Monday, November 08, 2010 11:22:36 Ali Çehreli wrote:
Steven Schveighoffer wrote:
On Mon, 08 Nov 2010 13:35:38 -0500, Daniel Gibson
If you pass a dynamic array to a function and chance it's size within
the function, you have undefined behaviour - you never know if it will
On 11/7/10 6:33 AM, bioinfornatics wrote:
So D community will be split in 2. And D1 continue to evolve without
D2 community, D1 frontend is open source and he coulb be used for
improve and fix D1
The current situation and the dynamics are quite interesting, and I am
looking forward to
On Mon, 08 Nov 2010 20:30:33 +0100
Daniel Gibson metalcae...@gmail.com wrote:
The documentation[1] says: For dynamic array and object parameters, which
are
passed by reference, in/out/ref apply only to the reference and not the
contents.
So, by reading the documentation one would assume
Jens Mueller Wrote:
I find this behavior rather strange. Arrays are neither passed by value
(copying the whole array) nor by reference. I see reasons for doing it
like this, e.g. doing array = array[1..$] inside should not affect the
outside.
But I wonder whether these semantics are well
On Monday 08 November 2010 12:07:39 spir wrote:
On Mon, 08 Nov 2010 20:30:33 +0100
Daniel Gibson metalcae...@gmail.com wrote:
The documentation[1] says: For dynamic array and object parameters,
which are passed by reference, in/out/ref apply only to the reference
and not the contents.
Jens Mueller Wrote:
Hi,
I do not understand what's going on behind the scene with this code. Or
better said I have some idea but maybe I do not see the whole point.
void foo(int[] array) {
array.length += 1000; // may copy the array
array[0] = 1;
}
auto a = new int[1];
Andrei:
A longer term perception problem is that some might
think the _design_ of such features has unsolvable issues,
That's my fear (so it's problem, even if it's just a perceived imaginary
problem). But I am not in a rush, so I am not going away.
I know of no major design flaws,
Uhm...
Jonathan M Davis:
Daniel Gibson:
So maybe yet another solution would be to *really* pass dynamic arrays by
reference (like the doc pretends it's already done)?
That would be a devastating change.
That's a solution that I have proposed lot of time ago, I did receive no
answers :-)
A
On 11/8/10 1:10 AM, Simen kjaeraas wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 11/7/10 4:21 PM, bearophile wrote:
Andrei Alexandrescu:
And what was exactly the claim that was wrong?
That there is no need of compiler syntax support to implement good
enough
On 11/7/10 11:34 PM, spir wrote:
On Sun, 07 Nov 2010 19:12:02 -0600
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote:
On 11/7/10 1:54 PM, retard wrote:
Sun, 07 Nov 2010 19:39:09 +0200, so wrote:
Andrei's stance is, either a library addon or ship D without that
feature. D's library
Daniel Gibson wrote:
Daniel Gibson schrieb:
Daniel Gibson schrieb:
Walter Bright schrieb:
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2
(while in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3]) natural to manipulate.
It
Walter Bright schrieb:
Daniel Gibson wrote:
Daniel Gibson schrieb:
Daniel Gibson schrieb:
Walter Bright schrieb:
Daniel Gibson wrote:
BTW: What were the reasons to pass static arrays by value in D2
(while in D1 they're passed by reference)?
It makes things like vectors (i.e. float[3])
On 11/8/10 12:48 PM, bearophile wrote:
Andrei:
A longer term perception problem is that some might think the
_design_ of such features has unsolvable issues,
That's my fear (so it's problem, even if it's just a perceived
imaginary problem). But I am not in a rush, so I am not going away.
Jonathan M Davis wrote:
How hard would it really be to insert code wherever a struct's init value is
used to default construct it either when the program starts up (for globals) or
right after it's declared (for locals)? If you could do that, then I don't see
why we couldn't have proper
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Jonathan M Davis wrote:
How hard would it really be to insert code wherever a struct's init value is
used to default construct it either when the program starts up (for
globals) or
right after it's declared (for locals)?
A potential mod_d Apache module would go a long way to promote D language to
the web application world.
But it seems that implementing a mod_d Apache module may require that C
instantiates a D language interpreter (similar to Py_NewInterpreter() for
Python), or do the functionality of RDMD with
Andrei Alexandrescu schrieb:
On 11/7/10 6:33 AM, bioinfornatics wrote:
So D community will be split in 2. And D1 continue to evolve without
D2 community, D1 frontend is open source and he coulb be used for
improve and fix D1
The current situation and the dynamics are quite interesting, and I
JFD schrieb:
A potential mod_d Apache module would go a long way to promote D language to
the web application world.
But it seems that implementing a mod_d Apache module may require that C
instantiates a D language interpreter (similar to Py_NewInterpreter() for
Python), or do the functionality
On Mon, 08 Nov 2010 15:32:56 -0500
Jesse Phillips jessekphillip...@gmail.com wrote:
But they are past by reference. You can modify the data all you want, but
cannot reassign the reference itself.
No, they are _not_ passed by reference. Stop saying that, this is precisely
what causes
Jesse Phillips wrote:
Jens Mueller Wrote:
Hi,
I do not understand what's going on behind the scene with this code. Or
better said I have some idea but maybe I do not see the whole point.
void foo(int[] array) {
array.length += 1000; // may copy the array
array[0] = 1;
Trass3r schrieb:
You gain a lot of power by using D1 instead of Java/C++: Usable
Templates with static if, slices, a GC, unsigned types, ..
Yep, working with C++ again feels like being thrown back to the stone age.
It's also the (at least felt) immaturity of DMD for D2, I guess. You
read
Andrei:
I think we have different definitions of what a design flaw is. C++
export was a design flaw. PHP also has several design flaws. The fact
that you can't implement non-nullable references in e.g. C++ or Java is
not a design flaw in those respective languages.
You are right. I am
Shouldn't GDC work on windows with MinGW? Maybe someone could try that
and build an installer or something.
Just try compiling it ;)
dsimcha wrote:
While I'm also skeptical of the idea that simply declaring a variable can cause
arbitrarily complex code to be executed, I'll play Devil's Advocate a little:
What if we required the default struct constructor to be nothrow? We could also
require some level of purity (at least
Why are you even here? D is a waste of time if you believe the half of the
nonsense you have written.
It is much better for you to be part of that stream, much safer.
Steven Schveighoffer wrote:
No, it doesn't. If you are appending to data that was passed in, you are
not changing the *original data* passed in. You are only appending
to it.
I must be remembering an old behavior. I think appending could affect
the original if it had enough capacity.
Yes, you're right. One should implement Apache module in D.
One thing is that Apache module entry point expects a C function. I've figure
that that one could just add extern(C) in front of D function to be callable
from
C, so that was easy. Also, Apache expects .so shared library, and one
On Monday, November 08, 2010 16:11:46 so wrote:
I like that explanation. Jonathan is saying the same, I think. I'll
guess my misunderstanding is mainly caused by figuring out that a
reassign is happening and that a reassign to a reference changes the
reference. In C++ you cannot change a
D arrays very powerful but you first need to understand what is going on.
You should check the book.
An inconsistency is the copy of static arrays at assignment, but necessary
one.
One thing i don't like about D arrays is an undefined case in dynamic
array reallocation.
--
Using Opera's
On 11/8/10 4:50 PM, so wrote:
D arrays very powerful but you first need to understand what is going
on. You should check the book.
Or a mildly outdated but accurate preview of the relevant chapter:
http://erdani.com/d/thermopylae.pdf
Andrei
On Tue, Nov 9, 2010 at 1:24 AM, Jesse Phillips
jessekphillip...@gmail.com wrote:
The array-struct is the reference, so it is what gets compared. That means
both the internal pointer and length must be the same. Just because the
reference is more than an address does not make it any less a
On Monday, November 08, 2010 15:23:40 Walter Bright wrote:
dsimcha wrote:
While I'm also skeptical of the idea that simply declaring a variable can
cause arbitrarily complex code to be executed, I'll play Devil's
Advocate a little: What if we required the default struct constructor to
be
On Monday, November 08, 2010 16:50:46 so wrote:
D arrays very powerful but you first need to understand what is going on.
You should check the book.
An inconsistency is the copy of static arrays at assignment, but necessary
one.
One thing i don't like about D arrays is an undefined case in
I didn't mean that one, check page 112 on
http://erdani.com/d/thermopylae.pdf
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Oh yeh you are right, i said reallocation. Should have said assignment.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
If anyone would like to use the latest compiler release, but cannot
because of a compiler regression, please specify which bug is the
blocker (and whether you are using D1 or D2).
I'll try to get any such compiler regressions fixed in the next release.
Daniel Gibson Wrote:
On Tue, Nov 9, 2010 at 1:24 AM, Jesse Phillips
jessekphillip...@gmail.com wrote:
The array-struct is the reference, so it is what gets compared. That means
both the internal pointer and length must be the same. Just because the
reference is more than an address
On 11/8/10 4:37 PM, JFD wrote:
Yes, you're right. One should implement Apache module in D.
One thing is that Apache module entry point expects a C function. I've figure
that that one could just add extern(C) in front of D function to be callable
from
C, so that was easy. Also, Apache
2010/11/9 Andrei Alexandrescu seewebsiteforem...@erdani.org:
People at Facebook told me that the adoption of D inside the company might
be helped if they could simply write ?d ... ? to insert D code into a
page. I'm not sure how difficult such a plugin would be to implement. Also,
D code
On Monday 08 November 2010 20:10:42 Walter Bright wrote:
Jonathan M Davis wrote:
Well, if it's a default constructer which has to be nothrow and maybe
pure or nothing, I'll take the default constructor. Now, if there's a
better way to handle this which would result in full-blown, arbitrary
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:ibaepi$vf...@digitalmars.com...
People at Facebook told me that the adoption of D inside the company might
be helped if they could simply write ?d ... ? to insert D code into a
page. I'm not sure how difficult such a
Walter Bright newshou...@digitalmars.com wrote in message
news:ib87ai$26u...@digitalmars.com...
Nick Sabalausky wrote:
Well I'll be damned, even C/C++ knows that uninitialized variables
shouldn't be used, and yet D doesn't. This is where Walter claims that
getting rid of that warning
so s...@so.do wrote in message news:op.vlubxy2a7dt...@so-pc...
int i;
i = i + 5;
I can't see any uninitialized var there, can you? :P
There's no usage of an undeclared variable, but the right-hand-side of the
second line uses 'i' before *the programmer* initializes it. Yes, the D
compiler
There's no usage of an undeclared variable, but the right-hand-side of
the
second line uses 'i' before *the programmer* initializes it. Yes, the D
compiler chooses to automatically initialize it, but by doing so it
silently
creates a bug every time the programmer intends 'i' to start out as
so s...@so.do wrote in message news:op.vlua80b47dt...@so-pc...
I think I figured out what you meant. When I said C# got it right, you
thought I was talking about how C# doesn't allow any int x = void;
whatsoever, right? That's not what I meant. I was talking about how C#
issues a compile-time
so s...@so.do wrote in message news:op.vlv3iukp7dt...@so-pc...
There's no usage of an undeclared variable, but the right-hand-side of
the
second line uses 'i' before *the programmer* initializes it. Yes, the D
compiler chooses to automatically initialize it, but by doing so it
silently
On Tue, 9 Nov 2010 00:17:48 -0500
Nick Sabalausky a...@a.a wrote:
People at Facebook told me that the adoption of D inside the company might
be helped if they could simply write ?d ... ? to insert D code into a
page. I'm not sure how difficult such a plugin would be to implement.
I'm
spir denis.s...@gmail.com wrote in message
news:mailman.201.1289284596.21107.digitalmar...@puremagic.com...
On Tue, 9 Nov 2010 00:17:48 -0500
Nick Sabalausky a...@a.a wrote:
People at Facebook told me that the adoption of D inside the company
might
be helped if they could simply
On 11/8/10 10:36 PM, spir wrote:
On Tue, 9 Nov 2010 00:17:48 -0500
Nick Sabalauskya...@a.a wrote:
People at Facebook told me that the adoption of D inside the company might
be helped if they could simply write?d ... ? to insert D code into a
page. I'm not sure how difficult such a plugin
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:ibark6$1k3...@digitalmars.com...
On 11/8/10 10:36 PM, spir wrote:
On Tue, 9 Nov 2010 00:17:48 -0500
Nick Sabalauskya...@a.a wrote:
People at Facebook told me that the adoption of D inside the company
might
be helped
Walter Bright wrote:
I see no reason why people would do that. It doesn't save typing, it
isn't convenient, etc.
What I mean is that I've never seen anyone do that, and I've seen a lot of junk
people did to shut the compiler up.
bearophile wrote:
Don:
There's only really one. But it's huge.
Really? :-) I didn't know this. (You are very often right, but I have a hard
time believing this).
Bye,
bearophile
Bug 314 is the root cause of every module bug that I know of. Basically
the compiler isn't keeping track of
Don:
Bug 314 is the root cause of every module bug that I know of. Basically
the compiler isn't keeping track of how symbols got imported. So it gets
everything wrong.
Bug 314 is among my voted bugs since a lot of time. Even if bug 314 isn't the
only module system bug present, solving it
Hello,
I don't understand why the compiler refuses the code below, with the error
__trials__.d(33): found '.' when expecting ';' following statement
(Note that method set returns this.)
class C {
int i,j;
this (int i) {
this.i = i;
}
C set (int j) {
this.j = j;
Hello,
It seems that if function has no parameters, it's possible to omit the
parentheses when calling it:
string sayHello() {
return hello;
}
void main() {
writeln(sayHello); // same as writeln(sayHello());
}
Is this an actual defined (and documented) behaviour
On Mon, 08 Nov 2010 14:39:43 -0500, spir denis.s...@gmail.com wrote:
Hello,
I don't understand why the compiler refuses the code below, with the
error
__trials__.d(33): found '.' when expecting ';' following statement
(Note that method set returns this.)
class C {
int i,j;
this
1 - 100 of 164 matches
Mail list logo
