Is D 2.0 still in alpha?
--
-Arth
Is D 2.0 still in alpha?
It's in beta. Somewhat.
Nice one.. Thanks for the reply Trass3r...
I'm so excited [?]
On Sun, Jul 25, 2010 at 9:24 AM, Trass3r wrote:
> Is D 2.0 still in alpha?
>>
>
> It's in beta. Somewhat.
>
--
-Arth
<<360.gif>>
Hello Trass3r,
Is D 2.0 still in alpha?
It's in beta. Somewhat.
The language? More like an RC. DMD? Beta.
--
... <
On 25/07/10 5:21 AM, BCS wrote:
Hello Trass3r,
Is D 2.0 still in alpha?
It's in beta. Somewhat.
The language? More like an RC. DMD? Beta.
And Phobos, I'd say, is still in alpha. Half the simple stuff in there
doesn't work, never mind anything that's complex. e.g.
Peter Alexander Wrote:
> On 25/07/10 5:21 AM, BCS wrote:
> > Hello Trass3r,
> >
> >>> Is D 2.0 still in alpha?
> >>>
> >> It's in beta. Somewhat.
> >>
> >
> > The language? More like an RC. DMD? Beta.
> >
>
>
The language? More like an RC.
Well typedef is to be removed, delete has pretty much been deprecated as I
heard.
Now they seem to intend to remove scope too (didn't read the topic
thoroughly though, I'm sick of all those "remove every single keyword
there is in the language" threads)
Trass3r:
> Now they seem to intend to remove scope too (didn't read the topic
> thoroughly though, I'm sick of all those "remove every single keyword
> there is in the language" threads)
The Scope!() replacement for scope is not good enough yet:
1) The compiler doesn't test for escapes (as dmd
On 07/25/2010 08:22 AM, bearophile wrote:
Trass3r:
Now they seem to intend to remove scope too (didn't read the topic
thoroughly though, I'm sick of all those "remove every single
keyword there is in the language" threads)
The Scope!() replacement for scope is not good enough yet: 1) The
compi
Andrei Alexandrescu wrote:
> but scope must go
But scope(exit) stays, right?
Hello Tomek,
Andrei Alexandrescu wrote:
but scope must go
But scope(exit) stays, right?
Totally different thing. :)
--
... <
BCS wrote:
> Hello Tomek,
>
>> Andrei Alexandrescu wrote:
>>
>>> but scope must go
>>>
>> But scope(exit) stays, right?
>>
>
> Totally different thing. :)
Phew.. He did say "it doesn't deserve a keyword" so I got scared ;)
Le 25/07/2010 22:40, BCS a écrit :
Hello Tomek,
Andrei Alexandrescu wrote:
but scope must go
But scope(exit) stays, right?
Totally different thing. :)
I must admit I had the same reaction as Tomek while reading Andrei's
post :) I am relieved scope (exit|failure|success) is not on the r
> The issue is that the scope keyword is impossible to check against
> escapes without extra additions to the language (e.g. marking a method
> or a function parameter as scoped). Such an uncheckable pattern is best
> left to a library feature, it doesn't deserve a keyword. I agree that
> scoped()
> What guarantees is shared supposed to provide?
>
> Shared means that multiple threads can access the data. The
> guarantee is that if it is not shared, and not immutable, that
> only the current thread can see it.
What if I have a thread that contains some shared data? Should
the thread be crea
On Monday, 20 October 2014 at 13:29:47 UTC, Marco Leise wrote:
What guarantees is shared supposed to provide?
Shared means that multiple threads can access the data. The
guarantee is that if it is not shared, and not immutable, that
only the current thread can see it.
What if I have a thread t
Am Mon, 20 Oct 2014 16:18:51 +
schrieb "Sean Kelly" :
> On Monday, 20 October 2014 at 13:29:47 UTC, Marco Leise wrote:
> >
> > What if I have a thread that contains some shared data? Should
> > the thread be created as shared, be cast to shared after
> > construction or not be shared and fine
On Tuesday, 21 October 2014 at 13:10:57 UTC, Marco Leise wrote:
Am Mon, 20 Oct 2014 16:18:51 +
schrieb "Sean Kelly" :
But to the point: Doesn't defining it as shared means that it
can not have _any_ unshared methods? Ok, fair enough. So even
if a method is only working on technically unshare
On Tuesday, 21 October 2014 at 16:05:58 UTC, Sean Kelly wrote:
Also, of the shared methods that exist, there are synchronized
blocks but they occur at a fine grain within the shared methods
rather than the entire method being shared. I think that
labeling entire methods as synchronized is an i
On Tuesday, 21 October 2014 at 16:36:30 UTC, Marc Schütz wrote:
I think `shared` by itself is fine, as long as it is only take
to mean "this method can cope with the parameters being
shared". It's `synchronized` and casting that cause the
trouble, because they are too coarse, and synchronized
Am Tue, 21 Oct 2014 16:05:57 +
schrieb "Sean Kelly" :
> Good point about a shared class not having any unshared methods.
> I guess that almost entirely eliminates the cases where I might
> define a class as shared. For example, the MessageBox class in
> std.concurrency has one or two osten
On Tuesday, 21 October 2014 at 19:32:17 UTC, Marco Leise wrote:
Do you think it would be bad if a pthread_mutex_t* was
declared as shared or only usable when shared ?
No. But the issue in general concerns me. Like say my class
contains a C style FILE*. If shared is transitive, then
fprintf(
Am Tue, 21 Oct 2014 19:43:45 +
schrieb "Sean Kelly" :
> On Tuesday, 21 October 2014 at 19:32:17 UTC, Marco Leise wrote:
> >
> > Do you think it would be bad if a pthread_mutex_t* was
> > declared as shared or only usable when shared ?
>
> No. But the issue in general concerns me. Like say m
I'm working on a string conversion template (well, incidentally to more
important stuff). I've got it automatically converting enumerations to strings,
but I have mask-type enumerations, single-value enumerations, and combination
enumerations where there's a value in one part of the integer and
Recently, some new DDoc macros were introduced in the std.ddoc copy in
the d-programming-language.org repo, but apparently, these are not
defined in the version used at digitalmars.com, as e.g. seen here:
http://www.digitalmars.com/d/2.0/phobos/std_datetime.html. In the first
paragraph below
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http://3d.benjamin-thaut.de/?p=18
Comments and criticism
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http://3d.benjamin-thaut.de/?p=18
Comments and criticism
Dear all:
I've found that D 2.0 windows installer (one key installer) will clear the
original PATH and set it as the D path. Is it a bug in the installer? Should
it keep the original value and put the D paths in front of them? Thanks
Not even the great Jarrett Billingsley has done this one? Dmn. Guess we
will need attributes then.
> Anyone have a clue about any of these issues?
Use Lisp ;-)
On Fri, Mar 6, 2009 at 4:25 PM, Burton Radons wrote:
> Not even the great Jarrett Billingsley has done this one? Dmn. Guess we
> will need attributes then.
>
Psh! Most template hacking I learned from the best - Don and Kirk :P
Don't bother introspecting enums. It will give you nothing but
Jarrett Billingsley Wrote:
> On Fri, Mar 6, 2009 at 4:25 PM, Burton Radons wrote:
> > Not even the great Jarrett Billingsley has done this one? Dmn. Guess we
> > will need attributes then.
> >
>
> Psh! Most template hacking I learned from the best - Don and Kirk :P
>
> Don't bother intros
On Fri, Mar 6, 2009 at 7:26 PM, Burton Radons wrote:
>> Don't bother introspecting enums. It will give you nothing but
>> sadness. The compiler hates enums in many ways.
>
> Works great actually. The only thing I needed to do was turn __traits
> (allMembers) from whatever the hell it is into an
Burton Radons wrote:
Jarrett Billingsley Wrote:
On Fri, Mar 6, 2009 at 4:25 PM, Burton Radons wrote:
Not even the great Jarrett Billingsley has done this one? Dmn. Guess we
will need attributes then.
Psh! Most template hacking I learned from the best - Don and Kirk :P
Don't bother in
Hello,
I wrote this to the site admin (Jan Knepper) too. Walter and I are
trying to set up the digitalmars.com server such that all request for
pages under digitalmars.com/d/2.0/ go to the corresponding file in
d-programming-language.org/.
I experimented on my own website and here is the
On 8/27/2011 1:14 PM, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http://3d.benjamin
On 8/27/2011 10:16 AM, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and having
completed 3 projects with it, I wrote a small article about the problems I had
with the D 2.0 programming language and what suggestions I have to improve it.
http
Benjamin Thaut wrote:
> After having used the D 2.0 programming language for a year now and
> having completed 3 projects with it, I wrote a small article about the
> problems I had with the D 2.0 programming language and what suggestions
> I have to improve it.
>
> http://3d
On Sat, Aug 27, 2011 at 12:39 PM, Walter Bright
wrote:
> On 8/27/2011 10:16 AM, Benjamin Thaut wrote:
>
>> After having used the D 2.0 programming language for a year now and having
>> completed 3 projects with it, I wrote a small article about the problems I
>> had
>&
"Caligo" wrote in message
news:mailman.2547.1314469962.14074.digitalmar...@puremagic.com...
> On Sat, Aug 27, 2011 at 12:39 PM, Walter Bright
> wrote:
>
>>
>> I find it very hard to read. Can you boost the font size, please? Have
>> pity
>> on us old guys!
>>
>
> Ctrl and + to increase the font
On 8/27/2011 10:14 AM, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what
suggestions I have to improve it.
http
Hope this works.
Just click this link: Ingrater%u2019s 3D Blog ï¿1/2 Suggestions for the
D 2.0 Programming Language <http://3d.benjamin-thaut.de/?p=18>
Sent from Readability <http://lab.arc90.com/experiments/re
Am 27.08.2011 19:39, schrieb Walter Bright:
On 8/27/2011 10:16 AM, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having
completed 3 projects with it, I wrote a small article about the
problems I had
with the D 2.0 programming language and what
On 8/27/2011 12:29 PM, Benjamin Thaut wrote:
Am 27.08.2011 19:39, schrieb Walter Bright:
I find it very hard to read. Can you boost the font size, please? Have
pity on us old guys!
Increased the font size a bit, I hope it is better that way
Better, but still a strain to read. The browser's d
On 8/27/2011 11:32 AM, Caligo wrote:
Ctrl and + to increase the font size. should work on any browser.
Thanks, I didn't know that. Tried it, it works.
"Mehrdad" wrote in message
news:j3beu2$25a8$1...@digitalmars.com...
> Related suggestion: All methods that return /new/ strings should return
> *mutable* arrays. There's really no reason (that I can think of) to not do
> this: if you see something returning a mutable array, you _know_ it's a
>
On 8/27/2011 3:47 PM, Daniel Murphy wrote:
"Mehrdad" wrote in message
news:j3beu2$25a8$1...@digitalmars.com...
Related suggestion: All methods that return /new/ strings should return
*mutable* arrays. There's really no reason (that I can think of) to not do
this: if you see something returning
aving used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about
the problems I had with the D 2.0 programming language and what
suggestions I have to improve it.
http://3d.benjamin-thaut.de/?p=18
Comments and criticism welcome
Mehrdad:
> "With transitivity, there is no way to have a const pointer to mutable int."
>
> But... so what? Maybe it should actually explain the benefit, since I
> can't figure it out on my own.
D wants both mutable data and (strongly) pure functions. How do you bridge such
two worlds? If you
On Saturday, August 27, 2011 12:01:21 Mehrdad wrote:
> On 8/27/2011 10:14 AM, Benjamin Thaut wrote:
> > After having used the D 2.0 programming language for a year now and
> > having completed 3 projects with it, I wrote a small article about the
> > problems I had with
14 AM, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about
the problems I had with the D 2.0 programming language and what
suggestions I have to improve it.
http://3d.benjamin-thaut.de/
dsimcha:
>Some of the things you mention are definitely bugs. (I'd call emplace
>requiring exact c'tor arguments, TID not supporting shared, the thread-local
>storage/GC issue, and maybe no function overloading with template parameters
>bugs. The TLS issue is already known.) These have a lot
"dsimcha" wrote in message
news:j3bk94$2e72$1...@digitalmars.com...
>>
>> Since a few days ago, mutable strings returned from strongly pure
>> functions
>> can be implicitly converted to immutable ones, so a cast won't be needed
>> any
>> more.
>
> Does the same apply to all arrays of primitive
On 8/27/2011 10:30 AM, dsimcha wrote:
Walter Bright is an idiot,
I'm sorry about that :-)
On 28-08-2011 01:05, bearophile wrote:
Mehrdad:
"With transitivity, there is no way to have a const pointer to mutable int."
But... so what? Maybe it should actually explain the benefit, since I
can't figure it out on my own.
D wants both mutable data and (strongly) pure functions. How do yo
On 8/28/11 8:54 PM, Alex Rønne Petersen wrote:
const_cast is the root of all evil. I really don't want to see it in D.
- Alex
It is already in D, and in an, in my personal opinion, much worse way:
You can just cast away const/immutable with cast().
What do you propose for the situations whe
On 8/28/2011 12:44 PM, David Nadlinger wrote:
It is already in D, and in an, in my personal opinion, much worse way: You can
just cast away const/immutable with cast().
True, but such is explicitly undefined behavior, and is not allowed in safe
mode.
What do you propose for the situations w
On 08/28/2011 02:44 PM, David Nadlinger wrote:
On 8/28/11 8:54 PM, Alex Rønne Petersen wrote:
const_cast is the root of all evil. I really don't want to see it in D.
- Alex
It is already in D, and in an, in my personal opinion, much worse way:
You can just cast away const/immutable with cast(
On 8/28/2011 4:52 PM, Andrei Alexandrescu wrote:
It is quite easy to define C++-like cast operators as D functions. If
there's enough demand for that, we may include such in the standard
library.
Andrei
I think we should define at least the following and probably put them in
std.conv, since t
Andrei Alexandrescu:
> It is quite easy to define C++-like cast operators as D functions. If
> there's enough demand for that, we may include such in the standard library.
I'd like this one in Phobos:
http://d.puremagic.com/issues/show_bug.cgi?id=5559
Having it in Phobos is hopefully better tha
Am 28.08.2011 23:13, schrieb dsimcha:
On 8/28/2011 4:52 PM, Andrei Alexandrescu wrote:
It is quite easy to define C++-like cast operators as D functions. If
there's enough demand for that, we may include such in the standard
library.
Andrei
I think we should define at least the following and
On 8/28/11 10:17 PM, Walter Bright wrote:
On 8/28/2011 12:44 PM, David Nadlinger wrote:
I know that this is not the general consensus, but I very much like
the C++
casting operators, because you can quickly get a rough idea what is
going on
when you see a cast in the code, whereas for D, cast()
On 8/28/2011 5:18 PM, Mafi wrote:
dynamicCast: Cast a class to another. This should throw something
derived from Error (not Exception) on failure instead of just returning
null. If you want null, just use the cast operator. Maybe we should
change its name, though. How about checkedCast or downCas
On 08/28/2011 04:31 PM, dsimcha wrote:
On 8/28/2011 5:18 PM, Mafi wrote:
dynamicCast: Cast a class to another. This should throw something
derived from Error (not Exception) on failure instead of just returning
null. If you want null, just use the cast operator. Maybe we should
change its name,
On 08/27/2011 12:14 PM, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http
On 8/28/11 10:52 PM, Andrei Alexandrescu wrote:
It is quite easy to define C++-like cast operators as D functions. If
there's enough demand for that, we may include such in the standard
library.
I hope this finally goes through, there still seem to be some –
hurricane-related, probably – stabi
Andrei Alexandrescu:
> Reddit discussion has turned to tuples:
boost::tuples::tie is ugly compared to the syntax proposed in that pull request.
> They work well except when expanding to multiple variables,
There are two more places where it's handy to expand tuples: function
signatures and for
On 8/28/2011 3:56 PM, David Nadlinger wrote:
I hope this finally goes through, there still seem to be some –
hurricane-related, probably – stability issues with the server.
The only stability issue was the massive power outage. Jan got it back up
running using a generator.
Jan has always don
On 8/29/11 1:27 AM, Walter Bright wrote:
On 8/28/2011 3:56 PM, David Nadlinger wrote:
I hope this finally goes through, there still seem to be some –
hurricane-related, probably – stability issues with the server.
The only stability issue was the massive power outage. Jan got it back
up runnin
On 8/28/2011 4:34 PM, David Nadlinger wrote:
On 8/29/11 1:27 AM, Walter Bright wrote:
On 8/28/2011 3:56 PM, David Nadlinger wrote:
I hope this finally goes through, there still seem to be some –
hurricane-related, probably – stability issues with the server.
The only stability issue was the m
On 8/27/11 12:14 PM, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http://3d.benjamin
Andrei Alexandrescu wrote:
> On 8/27/11 12:14 PM, Benjamin Thaut wrote:
>> After having used the D 2.0 programming language for a year now and
>> having completed 3 projects with it, I wrote a small article about the
>> problems I had with the D 2.0 programming language and
Am 29.08.2011, 05:44 Uhr, schrieb kennytm :
On the pattern matching syntax for templates in the comments -- Sigh, the
spec gotta advertise this valid syntax in the operator overloading page
more:
Foo opBinary(string op:"+")(...) { ... }
Is 'more' an euphemism? ;) Good to know this syntax
One of the comments written by Walter:
>Few programmers stuff so much on one line that it becomes difficult picking
>out the error.<
If you write D code in functional-style then lines of code often become quite
long.
Bye,
bearophile
On 8/29/11, kennytm wrote:
> On the pattern matching syntax for templates in the comments -- Sigh, the
> spec gotta advertise this valid syntax in the operator overloading page
> more:
>
> Foo opBinary(string op:"+")(...) { ... }
>
Wow I didn't know about this. So now I can do this:
enum Foo
On 29-08-2011 18:15, Andrej Mitrovic wrote:
On 8/29/11, kennytm wrote:
On the pattern matching syntax for templates in the comments -- Sigh, the
spec gotta advertise this valid syntax in the operator overloading page
more:
Foo opBinary(string op:"+")(...) { ... }
Wow I didn't know abou
On 08/29/2011 06:30 PM, Alex Rønne Petersen wrote:
On 29-08-2011 18:15, Andrej Mitrovic wrote:
On 8/29/11, kennytm wrote:
On the pattern matching syntax for templates in the comments -- Sigh,
the
spec gotta advertise this valid syntax in the operator overloading page
more:
Foo opBinary(string
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
I'm not sure how that would work with multiple constraints or
constraints that need comparisons, e.g. ElementType:
void test(R1:isInputRange && ElementType == int, R2:
On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
wrote:
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
I'm not sure how that would work with multiple constraints or
constraints that need comparisons, e.g. E
On 08/29/2011 07:44 PM, Martin Nowak wrote:
On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
wrote:
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
I'm not sure how that would work with multiple constraints o
On 8/29/11 1:39 PM, Timon Gehr wrote:
On 08/29/2011 07:44 PM, Martin Nowak wrote:
On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
wrote:
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
I'm not sure how that
On 08/29/2011 08:59 PM, Andrei Alexandrescu wrote:
On 8/29/11 1:39 PM, Timon Gehr wrote:
On 08/29/2011 07:44 PM, Martin Nowak wrote:
On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
wrote:
Oh man wouldn't it be cool if we could use this syntax like this:
void test(R1:isInputRange, R2:isF
Yeah it's not important. But I'll definitely use the colon syntax more
often now.
I hoped for a little bit more feedback about the article itself.
Especially about the move constructor I suggested. Does anyone see a
need for this, or is it just me?
--
Kind Regards
Benjamin Thaut
On 8/27/2011 10:14 AM, Benjamin Thaut wrote:
Comments and criticism welcome
This guy wants to contact you:
http://www.reddit.com/r/programming/comments/jwkvx/suggestions_for_the_d_20_programming_language/c2g2wos
On Monday, August 29, 2011 13:35 Benjamin Thaut wrote:
> I hoped for a little bit more feedback about the article itself.
> Especially about the move constructor I suggested. Does anyone see a
> need for this, or is it just me?
Honestly, I find the fact that you're writing code which relies on the
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the ramifications of the compiler not
being able to rely on a move having the bits stay absolutely identical (and a
move constructor would mak
On 8/29/11 4:36 PM, Walter Bright wrote:
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the ramifications of the
compiler not
being able to rely on a move having the bits stay absolutely i
On 27.08.2011 19:16, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http://3d.benjamin
On Tuesday, August 30, 2011 03:44:33 Stephan Soller wrote:
> On 27.08.2011 19:16, Benjamin Thaut wrote:
> > After having used the D 2.0 programming language for a year now and
> > having completed 3 projects with it, I wrote a small article about the
> > problems I had with
On 8/30/11, Jonathan M Davis wrote:
> But
> it's
> definitely true that allowing overloads between templatized and
> non-templatized
> functions would be an improvement. Hopefully, we get it at some point.
Seeing as example code that uses such overloading is already in TDPL,
this is probably only
Am 30.08.2011 02:56, schrieb Andrei Alexandrescu:
On 8/29/11 4:36 PM, Walter Bright wrote:
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the ramifications of the
compiler not
being able
On 8/30/11 12:45 AM, Benjamin Thaut wrote:
Am 30.08.2011 02:56, schrieb Andrei Alexandrescu:
On 8/29/11 4:36 PM, Walter Bright wrote:
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the r
Mehrdad Wrote:
> I feel like you hit the nail on the head. I feel the same way about const.
>
> Transitivity is beautiful on the outside, but I can never actually get
> it working, so I just make everything non-const. I have to sometimes do
> this even in Phobos itself, because the compiler com
But it's definitely true that allowing overloads between templatized and
non-templatized functions would be an improvement. Hopefully, we get it
at some point.
In the end this is not an "enhancement" but it is *required* to do proper
D2 style operator overloading.
Nick Sabalausky Wrote:
> I like Ctrl-ScrollWheel. Don't know if that's cross-browser, though. Works
> on FF. The font size on that page is pretty small though, I had to increase
> it a few clicks. But it was a nice change from so many of the newer sites
> these days that have everything cranked
On Aug 27, 2011, at 10:14 AM, Benjamin Thaut wrote:
> After having used the D 2.0 programming language for a year now and having
> completed 3 projects with it, I wrote a small article about the problems I
> had with the D 2.0 programming language and what suggestions I have to
>
On Aug 27, 2011, at 10:14 AM, Benjamin Thaut wrote:
> After having used the D 2.0 programming language for a year now and having
> completed 3 projects with it, I wrote a small article about the problems I
> had with the D 2.0 programming language and what suggestions I have to
>
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
> I really need to fix this. It's a pain though, for the reasons related
> to the ones you mention in "5. Shared". A tid, for example, fronts a
> message queue object that has some shared interface elements and some
> unshared interface
On Aug 30, 2011, at 1:41 PM, dsimcha wrote:
> == Quote from Sean Kelly (s...@invisibleduck.org)'s article
>> I really need to fix this. It's a pain though, for the reasons related
>> to the ones you mention in "5. Shared". A tid, for example, fronts a
>> message queue object that has some shared
1 - 100 of 174 matches
Mail list logo
