Don:
> Personally, I'd love to see implicit conversions int<->floating point
> completely removed from the language. But I think there'd be an outcry
> if that happened.
It's a significant change. How much work does it need to create a complied side
branch of DMD 2.051 with this difference? Wi
On 12/31/10, Manfred_Nowak wrote:
> Andrej Mitrovic wrote:
>
>> > "Overload sets can be merged with an alias declaration"
> [...]
>> That's not the point. The point is it works with a long variable, but
>> not with a long literal.
>
> ???
>
> According to the specs it shoudn't compile in both case
On 12/31/10, Simen kjaeraas wrote:
> We thus see that the template this parameter has absolutely no value.
Oh, you thought the D documentation is describing features *that
work*? Ha! Classic mistake.
You see, the D documentation is about showcasing features which don't
work, while TDPL is about
Andrej Mitrovic wrote:
On 12/31/10, Simen kjaeraas wrote:
This will give you both:
class A
{
void bar(this T) ( )
{
writeln(typeid(T));
writeln(typeid(this));
}
}
class B : A
{
}
void main( )
{
A a = new B;
a.bar();
}
Indeed it will. Now, if you loo
But the "native" code still need the VM to run, right?
On 31-Dec-10 7:09 AM, Klaim wrote:
Nope. There is a "native" SDK too. And it have been recently enhanced to
allow native-only application (no java).
On Thu, Dec 30, 2010 at 15:50, Michel Fortin mailto:michel.for...@michelf.com>> wrote:
Andrej Mitrovic wrote:
> > "Overload sets can be merged with an alias declaration"
[...]
> That's not the point. The point is it works with a long variable, but
> not with a long literal.
???
According to the specs it shoudn't compile in both cases.
-manfred
On Thu, 30 Dec 2010 14:34:45 -0600
Andrei Alexandrescu wrote:
> >> Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).
> >
> > I've got a lot of sympathy for the first alternative (absolutely NONE
> > for the second!). But unfortunately, the language allows sqrt(2) to
> > compile
On 12/31/10, Simen kjaeraas wrote:
>
This will give you both:
class A
{
void bar(this T) ( )
{
writeln(typeid(T));
writeln(typeid(this));
}
}
class B : A
{
}
void main( )
{
A a = new B;
a.bar();
}
On Thu, 30 Dec 2010 21:13:05 +0100
Don wrote:
> Yes, but OCaML isn't a C-family language, inheriting C's broken
> treatment of literals.
Just for information (I really mean information, not starting a new
discussion): was it proposed to let down such legacy mess form C at the time
when D1-->D
Steven Schveighoffer wrote:
Where the new scheme wins in brevity (for written code at least, and
certainly not simpler to understand) is cases where:
1. inheritance is not used
2. you can consolidate many overloads into one function.
As others have pointed out, this likely accounts for 99%
On Thu, 30 Dec 2010 19:17:09 +0100, Max Samukha
wrote:
On 12/30/2010 07:08 PM, Steven Schveighoffer wrote:
auto opAdd(Foo other)
vs.
auto opBinary(string op)(Foo other) if (op == "+")
For the latter not to look so intimidating, it can be shortened to:
auto opBinary(string op : "+")(Fo
Don wrote:
> disallow conversions integer->floating point
In version 0.80 floating point->integer was disallowed. The reasons that
triggered that disallowance in 0.80 are symmetric.
A reason was:
`(4,2)' might be mistyped as `(4.2)'
and symmetric means:
`(4.2)' might be mistyped as `(4,2)
Michel Fortin wrote:
I stubbled upon this yesterday:
Template This Parameters
TemplateThisParameters are used in member function templates to pick up
the type of the this reference.
import std.stdio;
struct S
{
const void foo(this T)(int i
Andrei Alexandrescu wrote:
I agree there's an issue here, but not only with floating point numbers:
void fun(long);
void fun(ulong);
...
fun(2); // whaa?
That's a feature, not a bug.
Don wrote:
Personally, I'd love to see implicit conversions int<->floating point
completely removed from the language. But I think there'd be an outcry
if that happened.
I'd be in favor of that. Can't see it break stuff in anything but
good ways.
--
Simen
Nope. There is a "native" SDK too. And it have been recently enhanced to
allow native-only application (no java).
On Thu, Dec 30, 2010 at 15:50, Michel Fortin wrote:
> On 2010-12-30 09:44:46 -0500, Trass3r said:
>
> Well you can always compile to native ARM code with gdc for example.
>>
>
> Bu
On 31.12.2010 1:17, Andrei Alexandrescu wrote:
On 12/30/10 3:59 PM, Dmitry Olshansky wrote:
On 28.12.2010 16:08, Daniel Gibson wrote:
[snip]
## UnbufferedInputTransport:
I'd like "void readFully(ubyte[] buffer)" which reads buffer.length
bytes or throws an exception if that is not possible
Thi
Andrei Alexandrescu wrote:
I'm thinking of an API that allows people to dynamically add "to do"
stuff, a la C's atexit(). Yours above is dynamic (because client code
can append to toFree) but is hand-written by the client.
So like this:
import std.stdio;
void delegate()[] terminators;
On 31.12.2010 1:14, Steven Schveighoffer wrote:
On Thu, 30 Dec 2010 16:49:15 -0500, Dmitry Olshansky
wrote:
[snip]
-
Question: Should we allow read to return an empty slice even if
atEnd is false? If we do, we allow non-blocking streams with burst
transfer. However, naive client code o
On 12/31/10, Manfred_Nowak wrote:
> Andrej Mitrovic wrote:
>
>> bug with [...] cross-module overloading
>
> "Overload sets can be merged with an alias declaration"
> http://www.digitalmars.com/d/2.0/function.html (cited 12/31/10)
>
> -manfred
>
That's not the point. The point is it works with a l
Andrej Mitrovic wrote:
> bug with [...] cross-module overloading
"Overload sets can be merged with an alias declaration"
http://www.digitalmars.com/d/2.0/function.html (cited 12/31/10)
-manfred
On 12/30/10 11:29 PM, Andrej Mitrovic wrote:
Try filing a feature request on bugzilla.
I don't quite see how this would be a feature request – »I'd like to be
able to actually express the implicitly used types in D code«?
The reason I brought this here instead of directly filing a
specifica
On 12/30/2010 11:10 PM, KennyTM~ wrote:
On Dec 30, 10 20:23, Stanislav Blinov wrote:
30.12.2010 15:05, bearophile пишет:
Peter Alexander:
but val is far too vague. It does not suggest that the value is
immutable at all.
In Scala you tag assignments with "val" or "var". "var" means
variable,
bearophile wrote:
Adam Ruppe:
bearophile wrote:
writing "immutable" often is boring and makes code longer.
im -> immutable
That doesn't shorten the code.
You did say "writing" implying the act of typing it was the problem.
I prefer something like "val", it's shorter to write, uses l
Yes, I agree. This will not work either but I'd like it to:
extern(C) void foo() { }
void bar(typeof(foo) func) { }
> Error: variable main.bar.func cannot be declared to be a function
Try filing a feature request on bugzilla.
On 12/30/10, David Nadlinger wrote:
> On 12/30/10 10:44 PM, Andrej M
On Thu, 30 Dec 2010 17:03:05 -0500, so wrote:
?? The only type in this list without a division operator is vector
all the others have it.
Matrix matrix, matrix vector, vector matrix division also not defined,
there is one syntactic similarity but it is not division.
Didn't give much
On 12/30/10 3:59 PM, Dmitry Olshansky wrote:
On 28.12.2010 16:08, Daniel Gibson wrote:
[snip]
## UnbufferedInputTransport:
I'd like "void readFully(ubyte[] buffer)" which reads buffer.length
bytes or throws an exception if that is not possible
This would also fix busy-waiting (it'd block until
On 12/30/10 10:44 PM, Andrej Mitrovic wrote:
Try this: [snip]
Thanks for your answer, but as I mentioned in my original post, I don't
see why creating an alias for the function pointer type should be
necessary – it is quite annoying when you are automatically creating
code, you'd need a spec
On Thu, 30 Dec 2010 16:49:15 -0500, Dmitry Olshansky
wrote:
[snip]
-
Question: Should we allow read to return an empty slice even if atEnd
is false? If we do, we allow non-blocking streams with burst transfer.
However, naive client code on non-blocking streams will be inefficient
b
FYI, there is a bug with long literals and cross-module overloading.
But I've managed to screw up the first report over 4 months ago and
just noticed it now (sorry!). The revised report is in the second
comment:
http://d.puremagic.com/issues/show_bug.cgi?id=4702#c1
?? The only type in this list without a division operator is vector
all the others have it.
Matrix matrix, matrix vector, vector matrix division also not defined,
there is one syntactic similarity but it is not division.
Didn't give much of a thought to others since vector, matrix and
Steven Schveighoffer wrote:
This doesn't help. The requirement is that it is one contiguous piece
of memory.
I don't know if we can solve the GC problems (although it seems that is
all people want to talk about here), I was wondering if we can provide a
library/language supported solution to
On 28.12.2010 16:08, Daniel Gibson wrote:
[snip]
## UnbufferedInputTransport:
I'd like "void readFully(ubyte[] buffer)" which reads buffer.length
bytes or throws an exception if that is not possible
This would also fix busy-waiting (it'd block until buffer.length bytes
are available).
Also "
On 12/30/10 3:36 PM, "Jérôme M. Berger" wrote:
so wrote:
On Thu, 30 Dec 2010 21:15:30 +0200, Jérôme M. Berger
wrote:
Andrei Alexandrescu wrote:
Many good examples do prove a ton though. Just off the top of my head:
- complex numbers
Multiplication and division are different from each o
On 12/30/10 3:36 PM, "Jérôme M. Berger" wrote:
so wrote:
On Thu, 30 Dec 2010 21:15:30 +0200, Jérôme M. Berger
wrote:
Andrei Alexandrescu wrote:
Many good examples do prove a ton though. Just off the top of my head:
- complex numbers
Multiplication and division are different from each o
I'm pretty sure this will work as well, because I have this defined in
a module where I'm passing a function pointer to C:
alias extern(C) size_t function(/*params*/) CallbackType;
Here's a snippet of how I used the OS to get a pointer to a C
function, which I've used to pass my own callback, and
[snip]
-
Question: Should we allow read to return an empty slice even if atEnd
is false? If we do, we allow non-blocking streams with burst transfer.
However, naive client code on non-blocking streams will be inefficient
because it would essentially implement busy-waiting.
Why not return
Try this:
extern(C) void foo() {}
extern(C)
{
alias void function() FooFunc;
// alias typeof(foo) FooFunc; // or try this one if it works
}
void bar(FooFunc func) { }
void main() {
bar( &foo );
}
I've had a nasty bug where I forgot to put extern(C) on a function
type like that. I spe
so wrote:
> On Thu, 30 Dec 2010 21:15:30 +0200, Jérôme M. Berger
> wrote:
>
>> Andrei Alexandrescu wrote:
>>> Many good examples do prove a ton though. Just off the top of my head:
>>>
>>> - complex numbers
>> Multiplication and division are different from each other and from
>> addition and
As easily verified e.g. by compiling
---
extern(C) void foo() {}
pragma( msg, typeof( &foo ) );
---,
function pointers types include the linkage type (the code above prints
»void C function()«).
However, there is no way to specify the linkage type e.g. in the
signature of a function accepting
But people don't expect 1/2 to return 0.5000 and D isn't C++
There are languages that have had to wait for a major language update to
reach that:
http://ideone.com/YdFbl
I am not familiar with Python and its community, but such a change in a
language even in a major update... great work!
On 12/30/10 2:13 PM, Don wrote:
bearophile wrote:
Don:
No. People expect sqrt(2) to compile, and to return 1.414
Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).
I've got a lot of sympathy for the first alternative (absolutely NONE
for the second!). But unfortunately,
Andrei Alexandrescu Wrote:
> On 12/30/10 12:38 PM, Sean Kelly wrote:
> > Andrei Alexandrescu Wrote:
> >
> >> On 12/30/10 11:19 AM, Sean Kelly wrote:
> >>> Adam Ruppe Wrote:
> >>>
> On 12/27/10, Steven Schveighoffer wrote:
> > What about tools to make deallocation easier? For example, w
spir wrote:
On Thu, 30 Dec 2010 07:46:19 +0100
Don wrote:
This problem has already hit Phobos. We inserted a hack so that sqrt(2)
will work. But exp(1) doesn't work.
Note that the problems really arise because we've inherited C's rather
cavalier approach to implicit conversion.
I'm unsure o
so wrote:
This problem has already hit Phobos. We inserted a hack so that
sqrt(2) will work. But exp(1) doesn't work.
Note that the problems really arise because we've inherited C's rather
cavalier approach to implicit conversion.
Classifying 2 as an int was a very wrong start.
Exactly. It's
bearophile wrote:
Don:
No. People expect sqrt(2) to compile, and to return 1.414
Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).
I've got a lot of sympathy for the first alternative (absolutely NONE
for the second!). But unfortunately, the language allows sqrt(2) to
On 2010-12-29 04:20, Robert Clipsham wrote:
Hey all,
I've just uploaded the source code to a pet project I've been working on
over the past few weeks - an MVC web framework written with D.
https://bitbucket.org/mrmonday/serenity/src
It's by no means ready for production use, I'm posting here p
On Dec 30, 10 20:23, Stanislav Blinov wrote:
30.12.2010 15:05, bearophile пишет:
Peter Alexander:
but val is far too vague. It does not suggest that the value is
immutable at all.
In Scala you tag assignments with "val" or "var". "var" means
variable, and "val" means value, it's not mutable.
On Thu, 30 Dec 2010 18:38:00 +0200, Adam Ruppe
wrote:
Something along these lines:
That code is "something along the lines" of data.d (but for D2) :)
https://github.com/CyberShadow/data.d
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
Alex_Dovhal:
> But people don't expect 1/2 to return 0.5000 and D isn't C++
There are languages that have had to wait for a major language update to reach
that:
http://ideone.com/YdFbl
While other ones have gotten it right from the beginning (Scheme numerical
tower is well designed):
http://i
bearophile wrote:
Walter:
I don't believe that has been objectively demonstrated. It's a claim.
Here at page 6 (Table 1) you see some bug frequencies for various languages,
C, Ada, SPARK, etc:
http://www.cs.virginia.edu/~jck/cs686/papers/andy.german.pdf (This is not a
demonstration).
Than
Jacob Carlborg wrote:
I uploaded packages for Mac OS X 10.6 Snow Leopard
to SourceForge, for Apple GCC build 5664 ("gcc-4.2"):
http://sourceforge.net/projects/gdcmac/files/gdc/6e7de627acdd/
PPS.
Maintainer for a D2 version of my "gdcgnu/gdcmac/gdcwin"
packages wanted, "just add -v2 to the ./
On 12/30/10 1:17 PM, Steven Schveighoffer wrote:
On Thu, 30 Dec 2010 12:52:32 -0500, Andrei Alexandrescu
wrote:
On 12/30/10 11:08 AM, Steven Schveighoffer wrote:
I'd have to see how it works. I also thought the new operator
overloading scheme was reasonable -- until I tried to use it.
You m
On 2010-12-29 10:00, Anders F Björklund wrote:
I uploaded packages for Mac OS X 10.6 Snow Leopard
to SourceForge, for Apple GCC build 5664 ("gcc-4.2"):
http://sourceforge.net/projects/gdcmac/files/gdc/6e7de627acdd/
You need the regular Xcode Tools installed (3.2.x),
and the installer .pkg adds
But people don't expect 1/2 to return 0.5000 and D isn't C++
People don't expect it because of the existence of a rule that makes no
sense.
I would absolutely expect 1/2 to return 0.5!
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
On 12/30/10 1:15 PM, "Jérôme M. Berger" wrote:
Andrei Alexandrescu wrote:
Many good examples do prove a ton though. Just off the top of my head:
- complex numbers
Multiplication and division are different from each other and from
addition and subtraction.
- checked integers
- checked
"Don" wrote:
>> Because the coder could have typed `0.0' instead of `0', the coder
>> probably wanted the compile time error you described.
>
> No. People expect sqrt(2) to compile, and to return 1.414
> For example, it works in C and in C++.
>
> The only other possible solution would be to d
On 12/30/10 12:38 PM, Sean Kelly wrote:
Andrei Alexandrescu Wrote:
On 12/30/10 11:19 AM, Sean Kelly wrote:
Adam Ruppe Wrote:
On 12/27/10, Steven Schveighoffer wrote:
What about tools to make deallocation easier? For example, we have
scope(exit) that you could potentially use to ensure a
s/most/some
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
On Thu, 30 Dec 2010 21:15:30 +0200, Jérôme M. Berger
wrote:
Andrei Alexandrescu wrote:
Many good examples do prove a ton though. Just off the top of my head:
- complex numbers
Multiplication and division are different from each other and from
addition and subtraction.
- checked i
On Thu, 30 Dec 2010 12:52:32 -0500, Andrei Alexandrescu
wrote:
On 12/30/10 11:08 AM, Steven Schveighoffer wrote:
I'd have to see how it works. I also thought the new operator
overloading scheme was reasonable -- until I tried to use it.
You mean until you tried to use it /once/.
Note thi
Andrei Alexandrescu wrote:
> Many good examples do prove a ton though. Just off the top of my head:
>
> - complex numbers
Multiplication and division are different from each other and from
addition and subtraction.
> - checked integers
> - checked floating point numbers
> - ranged/constra
bearophile wrote:
> That doesn't shorten the code.
Completely irrelevant. We're not playing code golf. What matters
is: a) Is it easy to change? and b) Is it clear to read?
immutable is easy to change. It's just one word. immutable is clear
to read, it says what it means.
> [val is] clear enough
On Thu, 30 Dec 2010 11:19:33 -0600
Andrei Alexandrescu wrote:
> On 12/30/10 6:41 AM, spir wrote:
> > Hello,
> >
> >
> > In the course of a project (1) 2 partner D programmers and myself are
> > currently implementing, we faced 2 issues which prevented us using a
> > range interface as planned. We
Andrei Alexandrescu Wrote:
> On 12/30/10 11:19 AM, Sean Kelly wrote:
> > Adam Ruppe Wrote:
> >
> >> On 12/27/10, Steven Schveighoffer wrote:
> >>> What about tools to make deallocation easier? For example, we have
> >>> scope(exit) that you could potentially use to ensure a memory block is
> >>>
On 12/30/2010 07:08 PM, Steven Schveighoffer wrote:
auto opAdd(Foo other)
vs.
auto opBinary(string op)(Foo other) if (op == "+")
For the latter not to look so intimidating, it can be shortened to:
auto opBinary(string op : "+")(Foo other)
On 12/30/10 11:37 AM, Michel Fortin wrote:
On 2010-12-30 11:02:43 -0500, Andrei Alexandrescu
said:
On 12/30/10 9:22 AM, Michel Fortin wrote:
On 2010-12-30 10:00:05 -0500, "Steven Schveighoffer"
said:
The thing I find ironic is that with the original operator overloading
scheme, the issue w
Adam Ruppe:
> bearophile wrote:
> > writing "immutable" often is boring and makes code longer.
>
> im -> immutable
That doesn't shorten the code.
> btw you might say "an editor is no excuse for bad language design"
> but this isn't bad language design, it's just a preference on your
> part.
On 12/30/10 11:19 AM, Sean Kelly wrote:
Adam Ruppe Wrote:
On 12/27/10, Steven Schveighoffer wrote:
What about tools to make deallocation easier? For example, we have
scope(exit) that you could potentially use to ensure a memory block is
deallocated on exit from a scope, what about a thread e
First it was simpler to understand. Second it worked well with
inheritance.
The current design requires that you know of templates and template
constrains, and it requires complicated workarounds if you're dealing
with inheritance (as illustrated by this thread). Basically, we've made
a s
On 12/30/10 11:08 AM, Steven Schveighoffer wrote:
I'd have to see how it works. I also thought the new operator
overloading scheme was reasonable -- until I tried to use it.
You mean until you tried to use it /once/.
Note this is even more bloated because you generate one function per
pair of
On 2010-12-30 11:02:43 -0500, Andrei Alexandrescu
said:
On 12/30/10 9:22 AM, Michel Fortin wrote:
On 2010-12-30 10:00:05 -0500, "Steven Schveighoffer"
said:
The thing I find ironic is that with the original operator overloading
scheme, the issue was that for types that define multiple oper
In my experience, I have not yet defined a type that uses a multitude of
operators with the same code. In fact, I have only defined the "~=" and
"~" operators for the most part.
So I'd say, while my example is not proof that this is a disaster, I
think it shows the change in operator overl
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
> Iain Buclaw Wrote:
> >
> > OK, I've had a proper look, is there any reason why phobos isn't using the
stat_t
> > implementation in druntime?
> No good reason. I think the 64-bit version of stat_t may be screwed up
(there's a bug report
Don:
> No. People expect sqrt(2) to compile, and to return 1.414
Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).
> For example, it works in C and in C++.
And maybe it doesn't work in OCaML.
Bye,
bearophile
Andrei:
> > Anyway, what is the need for a range-specific output format? And why should
> > it exactly look like an array (misleading)?
>
> Because I needed to put something there and couldn't think of something
> better...
In a bug report I have suggested to print:
[1; 2; 3]
Instead of:
[1, 2
On 12/30/10 6:41 AM, spir wrote:
Hello,
In the course of a project (1) 2 partner D programmers and myself are
currently implementing, we faced 2 issues which prevented us using a
range interface as planned. We initially intended to do it for better
compliance with D's coming new style, and nice
Adam Ruppe Wrote:
> On 12/27/10, Steven Schveighoffer wrote:
> > What about tools to make deallocation easier? For example, we have
> > scope(exit) that you could potentially use to ensure a memory block is
> > deallocated on exit from a scope, what about a thread exit?
>
> It seems to me that
On Thu, 30 Dec 2010 15:15:32 + (UTC)
Adam Ruppe wrote:
> > My guess is programmers spend ~ half of their time thinking, a
> > quarter of their time controlling & another quarter fixing;
> > the rest, typing.
>
> I don't know about that! If my personal vices are any indication,
> it is more
On Thu, 30 Dec 2010 11:00:20 -0500, Andrei Alexandrescu
wrote:
On 12/30/10 9:00 AM, Steven Schveighoffer wrote:
I'm assuming you meant this (once the bug is fixed):
template translateOperators()
{
auto opBinary(string op)(List other) {return doCat(other);} if (op ==
"~")
}
and adding t
Iain Buclaw Wrote:
>
> OK, I've had a proper look, is there any reason why phobos isn't using the
> stat_t
> implementation in druntime?
No good reason. I think the 64-bit version of stat_t may be screwed up
(there's a bug report for it on dsource/druntime) but I'll take care of that
before t
On 12/27/10, Steven Schveighoffer wrote:
> What about tools to make deallocation easier? For example, we have
> scope(exit) that you could potentially use to ensure a memory block is
> deallocated on exit from a scope, what about a thread exit?
It seems to me that the simplest thing might simply
This problem has already hit Phobos. We inserted a hack so that sqrt(2)
will work. But exp(1) doesn't work.
Note that the problems really arise because we've inherited C's rather
cavalier approach to implicit conversion.
Classifying 2 as an int was a very wrong start.
This proposal reminds me
On 12/30/10 10:10 AM, Steven Schveighoffer wrote:
On Thu, 30 Dec 2010 11:02:43 -0500, Andrei Alexandrescu
wrote:
On 12/30/10 9:22 AM, Michel Fortin wrote:
I stubbled upon this yesterday:
Template This Parameters
TemplateThisParameters are used in member function templates to pick up
the typ
(2010/12/29 15:01), Andrei Alexandrescu wrote:
1.
There seems to be it on the basis of the deriving.
In comparison with current std.stream, what will the advantage be?
With dynamically polymorphic interface, client code need not be
templated in order to accommodate any implementation of the i
On Thu, 30 Dec 2010 11:02:43 -0500, Andrei Alexandrescu
wrote:
On 12/30/10 9:22 AM, Michel Fortin wrote:
I stubbled upon this yesterday:
Template This Parameters
TemplateThisParameters are used in member function templates to pick up
the type of the this reference.
import std.stdio;
struc
On 12/30/10 9:00 AM, Steven Schveighoffer wrote:
On Wed, 29 Dec 2010 16:14:11 -0500, Andrei Alexandrescu
wrote:
On 12/29/10 2:58 PM, Steven Schveighoffer wrote:
On Wed, 29 Dec 2010 15:38:27 -0500, Andrei Alexandrescu
wrote:
On 12/29/10 2:10 PM, Steven Schveighoffer wrote:
On Wed, 29 Dec 2
On 12/30/10 9:22 AM, Michel Fortin wrote:
On 2010-12-30 10:00:05 -0500, "Steven Schveighoffer"
said:
The thing I find ironic is that with the original operator overloading
scheme, the issue was that for types that define multiple operator
overloads in a similar fashion, forcing you to repeat b
On Thu, 30 Dec 2010 05:41:18 -0700, spir wrote:
Hello,
In the course of a project (1) 2 partner D programmers and myself are
currently implementing, we faced 2 issues which prevented us using a
range interface as planned. We initially intended to do it for better
compliance with D's comi
Manfred_Nowak wrote:
Don wrote:
0 converts to double using implicit conversions.
The coder should know this while typing.
The coder should know about the possible problems while typing.
Because the coder could have typed `0.0' instead of `0', the coder probably
wanted the compile time error
On Thu, 30 Dec 2010 10:22:22 -0500, Michel Fortin
wrote:
On 2010-12-30 10:00:05 -0500, "Steven Schveighoffer"
said:
The thing I find ironic is that with the original operator overloading
scheme, the issue was that for types that define multiple operator
overloads in a similar fashio
For what it's worth invariant still works. It's a nice keyword, but we
already use it for class invariants. I prefer immutable over "val",
it's much more explicit and noticable in code and you'll never mistake
it for anything else since it's not a made up word. Plus you don't
have to do a "translat
On 2010-12-30 10:00:05 -0500, "Steven Schveighoffer"
said:
The thing I find ironic is that with the original operator overloading
scheme, the issue was that for types that define multiple operator
overloads in a similar fashion, forcing you to repeat boilerplate code.
The solution to it
spir wrote:
> Actually, do you know any editor _without_ this feature?
Notepad! I don't think elvis or gedit do either, all three of
which I've used for code in the past.
> But the actual issue is not about time at all, instead plain
> human laziness
There is more to it than laziness - it is fru
On Wed, 29 Dec 2010 19:45:54 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
Any other ideas?
Garbage collection tends to break down when you have enormous blocks of
memory allocated - 200Mb certainly qualifies.
I suggest breaking up the data structure into smaller pieces, like
On Wed, 29 Dec 2010 16:14:11 -0500, Andrei Alexandrescu
wrote:
On 12/29/10 2:58 PM, Steven Schveighoffer wrote:
On Wed, 29 Dec 2010 15:38:27 -0500, Andrei Alexandrescu
wrote:
On 12/29/10 2:10 PM, Steven Schveighoffer wrote:
On Wed, 29 Dec 2010 14:42:53 -0500, Andrei Alexandrescu
wrote:
On 2010-12-30 09:44:46 -0500, Trass3r said:
Well you can always compile to native ARM code with gdc for example.
But has the runtime been ported to ARM?
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Well you can always compile to native ARM code with gdc for example.
But normal apps use Java.
On Thu, 30 Dec 2010 13:19:52 + (UTC)
Adam Ruppe wrote:
> === back to the main point ===
>
> Of course, I'm sure there's dozens of editors with a similar feature.
> There might also be an existing option or plugin in your current
> editor of choice. It's worth investigating.
Actually, do yo
On Thu, 30 Dec 2010 05:55:13 -0500
bearophile wrote:
> An alternative is to use Go syntax, and use the Pascal-like ":=" to denote a
> value assignment (function signature can't use := ).
> Here there is another idea from Go syntax: if the "then" clause of the "if"
> uses {} then the () around t
1 - 100 of 116 matches
Mail list logo
