On Monday, 9 September 2013 at 04:00:39 UTC, Manu wrote:
Indeed. These opinions are my own, and I raised it on the merit
of our
experience last weekend in a 48hour game-dev-jam with a few
former
colleagues (including one who still works at Remedy).
This discussion has come up at remedy in the
On Monday, 9 September 2013 at 04:00:39 UTC, Manu wrote:
On 9 September 2013 05:46, Andrej Mitrovic
wrote:
On 9/8/13, Jesse Phillips wrote:
> I realize that we want to make it as painless as possible for
> Remedy to switch from C++ to D (along with the rest of the
> game
> developers).
FWI
Correction (3rd paragraph)
My personal view is that we should *not* make D a mixed pickles
with
lots of "but C++ has that" and then some more gadgets thrown in
for good measure.
Sorry -R
Manu has pointed to some issue behind the obvious issue that will
come up again and again unless it's settled once and for all.
Let's call it "To please everyone somewhat (and never really
enough) - vs - to stick to a clear and well founded concept".
My personal view is that we should make D
On Monday, September 09, 2013 07:41:44 Volcz wrote:
> Good idea!
>
> What about other useful projects? I know that a official lexer
> was discussed some time ago. What about DCD? Should ex VisualD
> use software like DCD if both are on the dlang GitHub?
The plan is to integrate a full lexer and p
Good idea!
What about other useful projects? I know that a official lexer
was discussed some time ago. What about DCD? Should ex VisualD
use software like DCD if both are on the dlang GitHub?
Should we make "pull requests"/empty repos. for other nice to
have software?
This seems like a waste of time compared to the other complaints
Manu brought up(bad IDE/debugger support etc.)
On 9/8/13 9:32 PM, Manu wrote:
On 8 September 2013 05:04, Walter Bright mailto:newshou...@digitalmars.com>> wrote:
Recent threads here have made it pretty clear that VisualD is a
critical piece of D infrastructure. (VisualD integrated D usage into
Microsoft Visual Studio.)
Andre
On 9 September 2013 14:32, Manu wrote:
> On 8 September 2013 05:04, Walter Bright wrote:
>
>> Recent threads here have made it pretty clear that VisualD is a critical
>> piece of D infrastructure. (VisualD integrated D usage into Microsoft
>> Visual Studio.)
>>
>> Andrei, myself and Rainer (Visua
On Mon, Sep 09, 2013 at 02:32:40PM +1000, Manu wrote:
> On 8 September 2013 05:04, Walter Bright wrote:
>
> > Recent threads here have made it pretty clear that VisualD is a
> > critical piece of D infrastructure. (VisualD integrated D usage into
> > Microsoft Visual Studio.)
> >
> > Andrei, myse
On 8 September 2013 05:04, Walter Bright wrote:
> Recent threads here have made it pretty clear that VisualD is a critical
> piece of D infrastructure. (VisualD integrated D usage into Microsoft
> Visual Studio.)
>
> Andrei, myself and Rainer (VisualD's champion) are all in agreement on
> this.
>
On Monday, 9 September 2013 at 03:46:23 UTC, Manu wrote:
For the record, I tend to agree with the arguments of many in
the 'against'
camp *from a purist point of view*, but the problem remains,
and the reason
I raised it; this has demonstrated to me and my colleagues on a
number of
occasions t
On 9 September 2013 05:46, Andrej Mitrovic wrote:
> On 9/8/13, Jesse Phillips wrote:
> > I realize that we want to make it as painless as possible for
> > Remedy to switch from C++ to D (along with the rest of the game
> > developers).
>
> FWIW I don't think this has anything to do with Remedy (a
On 08/09/13 16:47, Walter Bright wrote:
On 9/7/2013 11:08 PM, Peter Williams wrote:
In summary, you've gotten rid of the need for this type of duplication
so why
would you introduce it?
I believe that is covered in the "Rationale" section of the dip.
Couldn't see a rational answer to my ques
Missed the action...
Well it's clear this is not a popular proposal.
And even to me personally, it's certainly not of critical importance. If
there was a single thing I'd like to see *DONE* in D, it would be
temporary/r-value->ref args, without question (really, really annoying to
work around).
F
On Monday, 9 September 2013 at 01:25:00 UTC, Mike Parker wrote:
On 9/9/2013 8:52 AM, Stewart Gordon wrote:
>
> What do people think we should do?
>
Eliminate declare handle and alias all HANDLE types to void*.
I think this is the lazy and shortsighted answer. Even the
official Windows headers
On Sunday, 8 September 2013 at 03:37:35 UTC, Walter Bright wrote:
On the other hand, DRY, and I don't recall anyone ever
complaining about this in C++ outlined members.
Let me be the first, then, to formally lodge my complaint.
As for the DIP itself, I had enough of this tedium in C++. I
woul
On Sunday, 8 September 2013 at 23:52:46 UTC, Stewart Gordon wrote:
1. Define a hierarchy of dummy classes for the handle types.
No actual objects will exist of these types, but since classes
are reference types they can be set to null.
But there's a nasty bug lurking in this: if somebody trie
On 9/9/2013 8:52 AM, Stewart Gordon wrote:
>
> What do people think we should do?
>
Eliminate declare handle and alias all HANDLE types to void*.
On Sun, Sep 08, 2013 at 08:13:33PM +0200, Simen Kjaeraas wrote:
> In response to Walter's DIP47 I have created my own take on what I
> see as the main problem:
>
> http://wiki.dlang.org/DIP48
[...]
I don't see this as a fundamentally better or different solution than
DIP47, which I already vote a
On Sun, Sep 08, 2013 at 02:53:10PM +0200, Dicebot wrote:
> On Sunday, 8 September 2013 at 12:46:49 UTC, Gary Willoughby wrote:
[...]
> >Seriously, this goes against everything you learn as a programmer,
> >nothing should ever be typed twice and then to say that the
> >declaration and implementation
On 09/09/13 02:03, Iain Buclaw wrote:
Both the C# specification (
http://www.ecma-international.org/publications/standards/Ecma-334.htm ) and the
common language infrastructure (CLI) (
http://www.ecma-international.org/publications/standards/Ecma-335.htm ) have
been standardised for some time no
On 08/09/13 22:46, Gary Willoughby wrote:
On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright wrote:
Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and
placing the definition of it at global scope in the module or
On Sep 8, 2013 11:49 PM, "Joseph Rushton Wakeling" <
joseph.wakel...@webdrake.net> wrote:
>
> On 08/09/13 23:21, Iain Buclaw wrote:
>>
>> From an ethical viewpoint, I think most of it is FUD that still
>> lingers from back when there was confusion over what Microsoft was
>> going to do C# (there wa
On 9/8/13 5:33 AM, Andrej Mitrovic wrote:
On 9/8/13, Michel Fortin wrote:
So I'd like to suggest this: allow a .d file to "import" its corresponding
.di file.
This is actually what Andrei proposed as well.
I have to say I was a lot more in favor of the proposal before this thread.
The prob
On Sunday, September 08, 2013 12:08:07 monarch_dodra wrote:
> On Sunday, 8 September 2013 at 09:43:02 UTC, Kenji Hara wrote:
> > I also agree that the compiler enhancement is overkill.
> >
> > Kenji Hara
>
> Let's not throw this away quite yet: There is *another*
> fundamental difference:
>
> en
It has just come to my attention that there's a problem with the DECLARE_HANDLE template
in the Win32 bindings.
This is the definition in MinGW:
#define DECLARE_HANDLE(n) typedef struct n##__{int i;}*n
And this is the definition in our bindings:
package template DECLARE_HANDLE(string
On Sunday, 8 September 2013 at 22:37:00 UTC, Ramon wrote:
On Sunday, 8 September 2013 at 21:47:59 UTC, Andrej Mitrovic
wrote:
On 9/8/13, Ramon wrote:
Fox and fltk are
nice little thingies but not up to (todays) par lacking even
functionality like printing.
Printing seems like something that
On 9/8/2013 6:03 AM, "Øivind" wrote:
That throws safety out the window for one. If you want safety and
no new language features, this should work:
a[base..$][0..width]
Thanks
Still a little verbose, but at least you don't have to type the same things
twice.
I guess the double slice will b
On Sunday, 8 September 2013 at 23:24:32 UTC, Walter Bright wrote:
On 9/7/2013 9:45 PM, Daniel Murphy wrote:
tl;dr I don't think this justifies a new feature. A lint
rule, absolutely.
A warning, possibly. But not a new feature.
I agree with the reasoning of the others here - not worth it.
On 9/7/2013 9:45 PM, Daniel Murphy wrote:
tl;dr I don't think this justifies a new feature. A lint rule, absolutely.
A warning, possibly. But not a new feature.
I agree with the reasoning of the others here - not worth it.
On 08/09/13 23:21, Iain Buclaw wrote:
From an ethical viewpoint, I think most of it is FUD that still
lingers from back when there was confusion over what Microsoft was
going to do C# (there was for a long time fear that it would drive all
free C# implementations underground). But all that mist
On Sunday, 8 September 2013 at 21:47:59 UTC, Andrej Mitrovic
wrote:
On 9/8/13, Ramon wrote:
Fox and fltk are
nice little thingies but not up to (todays) par lacking even
functionality like printing.
Printing seems like something that should be in a separate
library,
and maybe the GUI library
On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright
wrote:
Recent threads here have made it pretty clear that VisualD is a
critical piece of D infrastructure. (VisualD integrated D usage
into Microsoft Visual Studio.)
Andrei, myself and Rainer (VisualD's champion) are all in
agreemen
On Fri, 6 Sep 2013 17:59:41 -0400
Nick Sabalausky wrote:
> On Fri, 06 Sep 2013 08:45:29 +0200
> Jacob Carlborg wrote:
>
> > On 2013-09-05 22:07, Nick Sabalausky wrote:
> >
> > > I've decided I'm going to add proper support for 32-bit-only and
> > > 64-bit-only via optional cmdline flags. That
On 9/8/13, Andrej Mitrovic wrote:
> Does the alias member feature pull its weight? Or is it overkill and
> we should drop it?
Anyway after some more thought I think it's overkill, since not
resetting the counter could be just as confusing as resetting it.
On Sun, 08 Sep 2013 23:00:17 +0200
"Ramon" wrote:
> Visual$$ on Windoze
Let's stick to grown-up words here. I'm not a fan of MS or Win either,
but every time you write "Windoze" or spell something with $ it does
nothing to hurt MS/Win and only makes you and other Posix users look
like immature b
I don't like DIP47, but I think I like this less. The original
DIP this is competing against at least has some sense of
familiarity. This is some weird new thing, and neither DIP really
does anything meaningful.
On 2013-09-08, 20:28, Jesse Phillips wrote:
On Sunday, 8 September 2013 at 18:13:52 UTC, Simen Kjaeraas wrote:
In response to Walter's DIP47 I have created my own take on what I see
as the main problem:
http://wiki.dlang.org/DIP48
Destroy!
Personally I find this practice of creating a com
On 9/8/13, Ramon wrote:
> Fox and fltk are
> nice little thingies but not up to (todays) par lacking even
> functionality like printing.
Printing seems like something that should be in a separate library,
and maybe the GUI library would provide a nice interface over its
functionality. I've no ide
On Sunday, 8 September 2013 at 21:08:59 UTC, Iain Buclaw wrote:
...
Against because we need a solution for *all* major platforms
(Lx32, Lx64,
*BSD, apple, w32,w64) and I'm worried that this resolution
here might lead
to a "So, we *do* have an IDE. Case closed" attitude.
Why not cross-platfo
I'm opposed to this DIP. It's aimed solely at aiding readability,
but having two ways to do something usually detracts from
readability. I don't see the point.
On Sunday, 8 September 2013 at 10:42:22 UTC, Savsak wrote:
...
In the example you give, but I receive this error during
compilation.
savsak:~ savsak$ dmd /Users/savsak/Desktop/test.d
ld: library not found for -lphobos2
collect2: ld returned 1 exit status
--- errorlevel 1
To help dicebot and
On 8 September 2013 22:00, Ramon wrote:
> Just for the sake of completeness:
>
> mono is *detested* and considered even more inacceptable than java by many
> linux and (even more) *BSD users.
>
Swings in roundabouts. Also depends what you mean by detest and inacceptable...
>From an ethical viewp
On 7 September 2013 22:57, Ramon wrote:
> On Saturday, 7 September 2013 at 20:02:37 UTC, Paulo Pinto wrote:
>>
>> Am 07.09.2013 21:55, schrieb Peter Alexander:
>>>
>>> On Saturday, 7 September 2013 at 19:39:21 UTC, Russel Winder wrote:
Sadly, Visual Studio is a huge player in the game. M
Just for the sake of completeness:
mono is *detested* and considered even more inacceptable than
java by many linux and (even more) *BSD users.
Actually I *did* try the eclipse D IDE thing ... and found it to
match my (utterly negative) perception of java (which has pretty
nothing to do with
On 9/8/13, Jesse Phillips wrote:
> I realize that we want to make it as painless as possible for
> Remedy to switch from C++ to D (along with the rest of the game
> developers).
FWIW I don't think this has anything to do with Remedy (afaik Manu
doesn't work there anymore).
On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright
wrote:
Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and
placing the definition of it at global scope in the module or
even in another module.
http://wiki.dl
On 08/09/13 01:22, Flamaros wrote:
I hope to see MonoD on github/d-programming-language too if it's the case of
VisualD.
One thing that could help with MonoD would be if it could effectively support
more than the most recent stable version of MonoDevelop. Version 3.0 is still
the one used in
On Sunday, 8 September 2013 at 18:13:52 UTC, Simen Kjaeraas wrote:
In response to Walter's DIP47 I have created my own take on
what I see as the main problem:
http://wiki.dlang.org/DIP48
Destroy!
Personally I find this practice of creating a competing DIP to be
very annoying. This was speci
On Sunday, 8 September 2013 at 18:13:52 UTC, Simen Kjaeraas wrote:
In response to Walter's DIP47 I have created my own take on
what I see as the main problem:
http://wiki.dlang.org/DIP48
Destroy!
I like it but would prefer
@interface instead of interface
Since using interface in this way, r
In response to Walter's DIP47 I have created my own take on what I see as
the main problem:
http://wiki.dlang.org/DIP48
Destroy!
--
Simen
On 2013-09-07, 19:00, Walter Bright wrote:
Outlining of member functions is the practice of placing the declaration
of a member function in the struct/class/union, and placing the
definition of it at global scope in the module or even in another module.
http://wiki.dlang.org/DIP47
I like
On 2013-09-08, 12:46, Tove wrote:
Wouldn't this style be an acceptable compromise instead? with both
declaration and definition 100% identical.
struct S
{
// member function declarations
static int mfunc1(int a, int b = 5) pure;
static int mfunc2(int a, int b = 5) pure;
static int
On Sunday, 8 September 2013 at 13:00:11 UTC, Dmitry Olshansky
wrote:
08-Sep-2013 16:02, Michel Fortin пишет:
[Snip]
Example:
// test.di
module test;
class A {
void foo(int a, int b);
}
// test.d
import module test; // import declarations from the .di
file
On Sunday, 8 September 2013 at 15:14:51 UTC, deadalnix wrote:
On Sunday, 8 September 2013 at 12:34:06 UTC, Andrej Mitrovic
wrote:
On 9/8/13, Michel Fortin wrote:
So I'd like to suggest this: allow a .d file to "import" its
corresponding
.di file.
This is actually what Andrei proposed as wel
On Sunday, 8 September 2013 at 15:09:31 UTC, Gary Willoughby
wrote:
This is a job for the *documentation* and if documentation is
automatically generated (which it is, see '-D') then this
argument is moot.
Documentation is tool to help with cross-project learning. I have
never seen one used i
On Sunday, 8 September 2013 at 12:34:06 UTC, Andrej Mitrovic
wrote:
On 9/8/13, Michel Fortin wrote:
So I'd like to suggest this: allow a .d file to "import" its
corresponding
.di file.
This is actually what Andrei proposed as well.
+42
I have never worked on any reasonably large Java/C# code base.
But it C++ once amount of entities grows large enough clear
interface overview in header files is basically only way to get
familiar quickly with sources.
This is a job for the *documentation* and if documentation is
automatically
On Sunday, 8 September 2013 at 12:46:49 UTC, Gary Willoughby
wrote:
I'm absolutely against this DIP.
This proposal is just going back to the hell of header files
again. Why on earth would you emulate C/C++ when D was supposed
to be designed taking into account lessons learned from them.
This
On Sunday, 8 September 2013 at 13:11:01 UTC, Gary Willoughby
wrote:
That said, I am strongly against permissive rules proposed in
this DIP. It should be similar to overriding rules - any
smallest difference between to signatures and program stops
compiling. Otherwise it is maintenance hell.
W
Am 08.09.2013 15:11, schrieb Gary Willoughby:
On Sunday, 8 September 2013 at 12:53:11 UTC, Dicebot wrote:
Seriously, this goes against everything you learn as a programmer,
nothing should ever be typed twice and then to say that the
declaration and implementation could be different just boggles
On 2013-09-07, 15:19, ilya-stromberg wrote:
On Saturday, 7 September 2013 at 13:02:39 UTC, Simen Kjaeraas wrote:
It's a bit weird in D though, as operators are instance methods, and
opImplicitRightCast (or opImplicitCastFrom, which is the name used in
discussions before, see WalterAndrei.pdf fr
On Sunday, 8 September 2013 at 12:53:11 UTC, Dicebot wrote:
Seriously, this goes against everything you learn as a
programmer, nothing should ever be typed twice and then to say
that the declaration and implementation could be different
just boggles my mind?!?! Great more work!
It is no diffe
On Sunday, 8 September 2013 at 12:08:50 UTC, Simen Kjaeraas wrote:
On 2013-09-08, 14:02, Chang Long wrote:
On Sunday, 8 September 2013 at 10:53:23 UTC, Øivind wrote:
a[c -: d] //D: a[c-d .. c]
I think this should be
a[c -: d] //D: a[c-d+1 .. c+1], e.g. a[5 -: 2] == [a[4],
a[5]]
t
On Sunday, 8 September 2013 at 10:42:22 UTC, Savsak wrote:
Thanks acehreli
In the example you give, but I receive this error during
compilation.
savsak:~ savsak$ dmd /Users/savsak/Desktop/test.d
ld: library not found for -lphobos2
collect2: ld returned 1 exit status
--- errorlevel 1
Your dm
08-Sep-2013 16:02, Michel Fortin пишет:
On 2013-09-07 17:00:05 +, Walter Bright
said:
Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and
placing the definition of it at global scope in the module or even in
another m
P.S. In general I'd love to have feature feature proposed in
DIP47 but its importance is very, _very_ low, right now it is
probably the least important DIP in the whole list.
On Sunday, 8 September 2013 at 12:00:22 UTC, Nick Sabalausky
wrote:
On Sun, 08 Sep 2013 12:56:09 +0200
"Batuhan Göksu" wrote:
[Environment]
DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import
-L/usr/dmd2/lib
I'm not on Posix ATM, but I think that last arg is supposed to
be:
-L
On Sunday, 8 September 2013 at 12:46:49 UTC, Gary Willoughby
wrote:
This proposal is just going back to the hell of header files
again.
It has nothing to do with header files. Or real header file
problems.
Seriously, this goes against everything you learn as a
programmer, nothing should eve
It won't work. (This is why my project uses IP sockets for
local communication, even on Linux)
That has already been fixed in the version of Phobos on Github
(I've marked it as fixed now, didn't know about that issue on
bugzilla before).
On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright
wrote:
Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and
placing the definition of it at global scope in the module or
even in another module.
http://wiki.dl
On 9/8/13, monarch_dodra wrote:
> enum S
> {
> a,
> alias b = a,
> }
>
> This would create an enum with a *single* entry, which can be
> accessed via two different names.
Yeah I've thought about this separately from that enhancement, I think
this feature *alone* would help to avoid issu
On 9/8/13, Daniel Murphy wrote:
> Two strategies that will prevent this bug are:
>
> 1) Put the 'alias' members directly after the member they reference
> 2) Put the 'alias' members at the end
There is another strategy, which I currently use, is to explicitly
initialize all enums.
As for #1 or #
On Sunday, 8 September 2013 at 10:56:11 UTC, Batuhan Göksu wrote:
.dmg file in the destination directory and the installation
does not want to set up.
What errors do you get using the installer?
-
/Jacob Carlborg
On 9/8/13, Michel Fortin wrote:
> So I'd like to suggest this: allow a .d file to "import" its corresponding
> .di file.
This is actually what Andrei proposed as well.
On Sunday, 8 September 2013 at 12:00:22 UTC, Nick Sabalausky
wrote:
On Sun, 08 Sep 2013 12:56:09 +0200
"Batuhan Göksu" wrote:
[Environment]
DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import
-L/usr/dmd2/lib
I'm not on Posix ATM, but I think that last arg is supposed to
be:
-L
On 2013-09-08, 14:02, Chang Long wrote:
On Sunday, 8 September 2013 at 10:53:23 UTC, Øivind wrote:
a[c -: d] //D: a[c-d .. c]
I think this should be
a[c -: d] //D: a[c-d+1 .. c+1], e.g. a[5 -: 2] == [a[4], a[5]]
try &a[base][0..width]
That throws safety out the window for one. I
On 2013-09-07 17:00:05 +, Walter Bright said:
Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and placing
the definition of it at global scope in the module or even in another
module.
http://wiki.dlang.org/DIP47
On Sun, 08 Sep 2013 12:56:09 +0200
"Batuhan Göksu" wrote:
> [Environment]
>
> DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import
> -L/usr/dmd2/lib
>
I'm not on Posix ATM, but I think that last arg is supposed to be:
-L-L/usr/dmd2/lib
On Sunday, 8 September 2013 at 11:24:32 UTC, Russel Winder wrote:
And why is the target audience for D only C and C++ people?
Surely the
target audience for D is any programmer wanting a native code
executable.
I think that D visibility isn't enough for the moment to be able
to convince Java
On Sunday, 8 September 2013 at 10:53:23 UTC, Øivind wrote:
a[c -: d] //D: a[c-d .. c]
I think this should be
a[c -: d] //D: a[c-d+1 .. c+1], e.g. a[5 -: 2] == [a[4],
a[5]]
try &a[base][0..width]
On 9/8/13 18:56, "Batuhan Göksu" " wrote:
Hi Friends,
dmd2 files downloaded at this address.
I took the files to the destination directory in this way.
/usr/dmd2
/usr/dmd2/bin
/usr/dmd2/lib
/usr/dmd2/man
/usr/dmd2/src
edited config file.
[Environment]
DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dm
On 08/09/13 13:24, Russel Winder wrote:
And why is the target audience for D only C and C++ people? Surely the
target audience for D is any programmer wanting a native code
executable.
They're not the _only_ target audience but they're surely the _main_ target
audience. Users of higher-level
Am 08.09.2013 13:24, schrieb Russel Winder:
On Sun, 2013-09-08 at 00:35 +0200, Paulo Pinto wrote:
[…]
And why is the target audience for D only C and C++ people? Surely the
target audience for D is any programmer wanting a native code
executable.
Because many of us are actually aware of compi
On Sun, 2013-09-08 at 00:35 +0200, Paulo Pinto wrote:
[…]
> Well, if you want a production quality multi-platform IDE the only
> options are InteliJ and Eclipse, both of which are not that well
> received by most C and C++ guys. The target audience for D.
>
> That is my humble opinion, regarding
On Sunday, 8 September 2013 at 10:59:34 UTC, Robert Schadek wrote:
On 09/08/2013 06:46 AM, Jonathan M Davis wrote:
If I had to vote though, I'd vote against this, because I
think that
it's a bad paradigm, and I don't want to deal with it.
+1
+1
Also issues mentioned by Manu are easily solv
08-Sep-2013 09:00, Jonathan M Davis пишет:
On Saturday, September 07, 2013 10:00:05 Walter Bright wrote:
Outlining of member functions is the practice of placing the declaration of
a member function in the struct/class/union, and placing the definition of
it at global scope in the module or even
Hi Friends,
dmd2 files downloaded at this address.
I took the files to the destination directory in this way.
/usr/dmd2
/usr/dmd2/bin
/usr/dmd2/lib
/usr/dmd2/man
/usr/dmd2/src
edited config file.
[Environment]
DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import
-L/usr/dmd2/lib
A
On 09/08/2013 06:46 AM, Jonathan M Davis wrote:
> If I had to vote though, I'd vote against this, because I think that
> it's a bad paradigm, and I don't want to deal with it.
+1
a[c -: d] //D: a[c-d .. c]
I think this should be
a[c -: d] //D: a[c-d+1 .. c+1], e.g. a[5 -: 2] == [a[4], a[5]]
Wouldn't this style be an acceptable compromise instead? with
both declaration and definition 100% identical.
struct S
{
// member function declarations
static int mfunc1(int a, int b = 5) pure;
static int mfunc2(int a, int b = 5) pure;
static int mfunc3(int a, int b = 5) pure;
// mem
On 08/09/13 06:26, Paul Jurczak wrote:
Right on target. If D wants to achieve some level of visibility for Windows C++
developers, Visual Studio presence is crucial. We are talking about a huge chunk
of market share here!
Disclosure: I have to use Visual Studio in work for my clients.
I don't.
I find myself writing the following a lot:
a[base..base+width]
to get the slice starting at 'base' of width 'width'. In verilog,
we select members of a vector/array in three ways
a[c : d] //D: a[c .. d+1]
a[c +: d] //D: a[c .. c+d]
a[c -: d] //D: a[c-d .. c]
Borrowing a bi
On Friday, 6 September 2013 at 21:02:09 UTC, Ali Çehreli wrote:
On 09/06/2013 01:47 PM, Savsak wrote:
> Hi Friends,
>
> Socket programming with the D programming language is the
most simple
> way how to do it
>
> For example, the sample with Tango, but not by phobos
>
> How do I do this with a s
On Sunday, 8 September 2013 at 09:24:52 UTC, Michael wrote:
On Sunday, 8 September 2013 at 09:15:52 UTC, Namespace wrote:
I'm against it. More important than such a gimmick are the
many open bugs, auto ref, AA, scope, etc. And don't forget the
implementation of the virtual keyword.
+1
I str
Most awesome
On Sunday, 8 September 2013 at 09:43:02 UTC, Kenji Hara wrote:
I also agree that the compiler enhancement is overkill.
Kenji Hara
Let's not throw this away quite yet: There is *another*
fundamental difference:
enum S
{
a,
b = a,
}
This creates an enum with *two* entries.
enum S
{
2013/9/8 Jonathan M Davis
> On Sunday, September 08, 2013 14:45:21 Daniel Murphy wrote:
> > Honestly, it seems like overkill to me.
> >
> > I can understand it would be an annoying bug to hit, but I doubt it
> would be
> > that common.
>
> Agreed.
I also agree that the compiler enhancement is o
On Sunday, 8 September 2013 at 09:15:52 UTC, Namespace wrote:
I'm against it. More important than such a gimmick are the many
open bugs, auto ref, AA, scope, etc. And don't forget the
implementation of the virtual keyword.
+1
1 - 100 of 110 matches
Mail list logo
