Looks like GDC's made a little splash over at Phoronix this
morning. In case no one here reads Phoronix, here's the link:
http://www.phoronix.com/scan.php?page=news_itempx=MTEyMzM
The forums rather quiet just yet, but I imagine some C++11 folks
may start raising their voices fairly soon.
On 06/20/2012 05:12 PM, Iain Buclaw wrote:
On 20 June 2012 15:26, F i L witte2...@gmail.com wrote:
Looks like GDC's made a little splash over at Phoronix this morning. In case
no one here reads Phoronix, here's the link:
http://www.phoronix.com/scan.php?page=news_itempx=MTEyMzM
The forums
I've been working on a couple of D projects. The first one is a
game engine at sourceforge.net/projects/d-game-engine; the other
is a GUI library that I haven't uploaded because I still need a
name for it. Both are in pre-alpha state, but hopefully they
won't stay that way for too long. If
On 20 June 2012 15:26, F i L witte2...@gmail.com wrote:
Looks like GDC's made a little splash over at Phoronix this morning. In case
no one here reads Phoronix, here's the link:
http://www.phoronix.com/scan.php?page=news_itempx=MTEyMzM
The forums rather quiet just yet, but I imagine some
Le mercredi 20 juin 2012 à 17:36 +0200, BLM768 a écrit :
I've been working on a couple of D projects. The first one is a
game engine at sourceforge.net/projects/d-game-engine; the other
is a GUI library that I haven't uploaded because I still need a
name for it. Both are in pre-alpha state,
Does the d-game-engine use an octree ?
I haven't really implemented any sort of BVH yet. I'm thinking
about using a sphere tree or AABBs instead of an octree, but I'm
not sure what I'm doing about that. Right now, the focus is on
fixing and finishing the shader code.
Le mercredi 20 juin 2012 à 22:27 +0200, BLM768 a écrit :
sphere tree
ok i see this pdf about sphere tree
http://www.cs.tcd.ie/publications/tech-reports/reports.99/TCD-CS-1999-10.pdf
Le mercredi 20 juin 2012 à 22:27 +0200, BLM768 a écrit :
sphere tree
and some comparison here http://isg.cs.tcd.ie/spheretree/
have fun
good luck
On 2012-06-20 17:36, BLM768 wrote:
I've been working on a couple of D projects. The first one is a game
engine at sourceforge.net/projects/d-game-engine; the other is a GUI
library that I haven't uploaded because I still need a name for it. Both
are in pre-alpha state, but hopefully they won't
Can you tell us more about the GUI library, like:
* Which platforms and GUI systems it's available on
* Does it use native drawing operations
* Or is it more directed to gaming
It's currently Windows-only, but the plan is to make it
cross-platform. It's designed for native widgets. So far,
On 2012-06-19 21:14, Russel Winder wrote:
I never used V1 (though I do have the Tango book) so enforcing V2 will
nto be a problem. Actually this means I can delete 65% of the SCons D
tool :-)
You can use the Tango book with D2.
3) For anyone who has submitted patches for Mingw and
Le 19/06/2012 20:11, Artur Skawina a écrit :
On 06/19/12 19:30, Christophe Travert wrote:
Artur Skawina , dans le message (digitalmars.D:170175), a écrit :
On 06/19/12 15:29, deadalnix wrote:
Le 19/06/2012 14:30, Artur Skawina a écrit :
Due to D concept of weak purity, this doesn't ensure
Le 19/06/2012 17:49, Timon Gehr a écrit :
On 06/18/2012 11:04 PM, deadalnix wrote:
Le 18/06/2012 17:29, Timon Gehr a écrit :
On 06/18/2012 05:14 PM, Christophe Travert wrote:
Matthias Walter , dans le message (digitalmars.D:170036), a écrit :
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it
Artur Skawina , dans le message (digitalmars.D:170191), a écrit :
The proper way to do this is not cast, it is to give the proper
constness for all types and methods :
struct S {
int i; this(int i) { this.i = i; }
T* p;
void f(int i) const { this.i = i; /*p.i++;*/ }
Le 19/06/2012 22:58, Manu a écrit :
Thinking more about the implications of removing the inline asm, what
would REALLY roxors, would be a keyword to insist a variable is
represented by a register, and by extension, to associate it with a
specific register:
register int x; //
I'm not too experienced with Github - am I right in thinking that
the SharedRuntime repository has been idle for six months? If so,
does this indicate that Martin has likely abandoned the project?
Like Wouter, I'm looking into developing a project with D that
would eventually require plugins,
Le 20/06/2012 04:34, Walter Bright a écrit :
I don't think we need to worry about that. Implementers tend to follow
existing practice unless there is a very, very good reason.
Did you ever heard of a company named microsoft ?
On 20 June 2012 10:42, deadalnix deadal...@gmail.com wrote:
Le 19/06/2012 22:58, Manu a écrit :
This would almost entirely eliminate the usefulness of an inline
assembler.
Better yet, this could use the 'new' attribute syntax, which most agree
will support arguments:
@register(rsp) int x;
Le 20/06/2012 09:58, Manu a écrit :
On 20 June 2012 10:42, deadalnix deadal...@gmail.com
mailto:deadal...@gmail.com wrote:
Le 19/06/2012 22:58, Manu a écrit :
This would almost entirely eliminate the usefulness of an inline
assembler.
Better yet, this could use the
deadalnix , dans le message (digitalmars.D:170262), a écrit :
Once again, this is inconsistent with how purity is defined elsewhere.
I'm all for fixing this hole - it's just that the proposed fix would
have consequences, which can't simply be ignored.
They are not ignored, but it seems
Inline assembly has been relatively useless in GCC for years.
Inline asm
interferes with the optimisers ability to do a good job, which
basically
makes use of inline assembly self-defeating.
The only time I ever need to use inline-asm is to interface an
arch feature
that has no API. As long as
Le 20/06/2012 10:18, Christophe Travert a écrit :
deadalnix , dans le message (digitalmars.D:170262), a écrit :
Once again, this is inconsistent with how purity is defined elsewhere.
I'm all for fixing this hole - it's just that the proposed fix would
have consequences, which can't simply be
On 19/06/12 11:02, Iain Buclaw wrote:
On 19 June 2012 09:18, Don Clugstond...@nospam.com wrote:
So would I. Can you think of one?
It was the best name I could come up with, given that the 'pure' was the
keyword.
We want a word that means 'no hidden state'.
I thought that was what pure was
On Mon, 18 Jun 2012 15:47:07 +0200, nazriel wrote:
On Sunday, 17 June 2012 at 16:38:25 UTC, Damian wrote:
I've noticed a few languages are adopting this, for example Haskell:
http://tryhaskell.org
Go: http://play.golang.org
Will D get something like this? I find it to be of great use with
deadalnix , dans le message (digitalmars.D:170272), a écrit :
Le 20/06/2012 10:18, Christophe Travert a écrit :
What is the conclusion here ?
I think it is the same as yours.
My conclusion is that delegate's signature should be the same has
methods's signature, and have the same meaning. That
On 20 June 2012 11:14, deadalnix deadal...@gmail.com wrote:
Le 20/06/2012 09:58, Manu a écrit :
On 20 June 2012 10:42, deadalnix deadal...@gmail.com
mailto:deadal...@gmail.com wrote:
Le 19/06/2012 22:58, Manu a écrit :
This would almost entirely eliminate the usefulness of an
On 20 June 2012 09:32, Tobias Pankrath tob...@pankrath.net wrote:
Inline assembly has been relatively useless in GCC for years. Inline asm
interferes with the optimisers ability to do a good job, which basically
makes use of inline assembly self-defeating.
The only time I ever need to use
On 06/19/2012 04:04 PM, Timon Gehr wrote:
On 06/19/2012 02:54 PM, Christophe Travert wrote:
Jonathan M Davis , dans le message (digitalmars.D:170054), a écrit :
I'd propose to always add a bool template parameter (maybe isConst?) to
the range since most of the write-functionality can be
On 20 June 2012 03:58, Walter Bright newshou...@digitalmars.com wrote:
Do a grep for asm across the druntime library sources. Can you
justify all
of that with some other scheme?
I think almost all the blocks I just browsed through could be easily
written
with nothing more than the
On 20 June 2012 11:32, Tobias Pankrath tob...@pankrath.net wrote:
Inline assembly has been relatively useless in GCC for years. Inline asm
interferes with the optimisers ability to do a good job, which basically
makes use of inline assembly self-defeating.
The only time I ever need to use
On 19/06/12 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on
/ the compiler version they want to use.
1) D Inline Asm and naked function support is raising far too
On 20/06/12 03:01, Alex Rønne Petersen wrote:
On 20-06-2012 02:58, Timon Gehr wrote:
On 06/20/2012 02:04 AM, Alex Rønne Petersen wrote:
On 20-06-2012 01:55, Timon Gehr wrote:
On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
On 6/19/2012 1:36 PM,
On 20/06/12 00:55, Manu wrote:
On 20 June 2012 01:07, Walter Bright newshou...@digitalmars.com
mailto:newshou...@digitalmars.com wrote:
On 6/19/2012 1:58 PM, Manu wrote:
I find a thorough suite of architecture intrinsics are usually
the fastest and
cleanest way to
On 20 June 2012 13:51, Don Clugston d...@nospam.com wrote:
On 19/06/12 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on
/ the compiler version they want to use.
On 2012-06-20 09:50, R. Grocott wrote:
I'm not too experienced with Github - am I right in thinking that
the SharedRuntime repository has been idle for six months? If so,
does this indicate that Martin has likely abandoned the project?
The last commit was three months ago, Mars 20, 2012:
On 20 June 2012 13:59, Don Clugston d...@nospam.com wrote:
You and I seem to be from different planets. I have almost never written
as asm function which was suitable for inlining.
Take a look at std.internal.math.biguintX86.d
I do not know how to write that code without inline asm.
It's because the compiler doesn't understand assembly code. It
has no
knowledge of what it actually does, and as a result, just
treats it as a
black box.
But this is not set in stone. If I teach a compiler how to
optimize intrinsics, can't I teach him to understand and optimize
a (maybe
On 06/20/2012 09:16 AM, deadalnix wrote:
Le 19/06/2012 17:49, Timon Gehr a écrit :
The question is, what the meaning of 'const' references should be:
1. data cannot be changed transitively through the reference
2. the reference can reference both 'const' and 'immutable' data and
'immutable'
On Wednesday, 20 June 2012 at 02:35:10 UTC, Walter Bright wrote:
On 6/19/2012 6:06 PM, Alex Rønne Petersen wrote:
On 20-06-2012 03:01, Walter Bright wrote:
On 6/19/2012 3:47 PM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
GDC can certainly define its D calling
On 2012-06-20 12:51, Don Clugston wrote:
You seem to be conflating a couple of unrelated issues here.
One is the calling convention. The other is inline asm.
Comments in the thread about asm is mostly used for short things which
get inlined leave me completely baffled, as it is completely
Timon Gehr , dans le message (digitalmars.D:170288), a écrit :
On 06/20/2012 09:16 AM, deadalnix wrote:
Le 19/06/2012 17:49, Timon Gehr a écrit :
The question is, what the meaning of 'const' references should be:
1. data cannot be changed transitively through the reference
2. the reference
On 20 June 2012 14:19, Tobias Pankrath tob...@pankrath.net wrote:
It's because the compiler doesn't understand assembly code. It has no
knowledge of what it actually does, and as a result, just treats it as a
black box.
But this is not set in stone. If I teach a compiler how to optimize
Jacob Carlborg:
You do understand that the GCC-style inline assembly will still
be available?
Are DMD and LDC2 going to accept that GCC-style inline assembly?
Bye,
bearophile
On 06/20/2012 12:29 PM, Matthias Walter wrote:
On 06/19/2012 04:04 PM, Timon Gehr wrote:
On 06/19/2012 02:54 PM, Christophe Travert wrote:
Jonathan M Davis , dans le message (digitalmars.D:170054), a écrit :
I'd propose to always add a bool template parameter (maybe isConst?) to
the range
On 20/06/12 13:04, Manu wrote:
On 20 June 2012 13:51, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 19/06/12 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going to post
the main
issues here that most affect D
On 06/20/2012 01:36 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:170288), a écrit :
On 06/20/2012 09:16 AM, deadalnix wrote:
Le 19/06/2012 17:49, Timon Gehr a écrit :
The question is, what the meaning of 'const' references should be:
1. data cannot be changed
Le 20/06/2012 13:04, Manu a écrit :
Case 1 has no alternative to inline asm. I've thrown out some crazy
ideas to think about (but nobody seems to like them). I still think it
could be addressed though.
Case 2; I'm not convinced. These such long functions are the type I'm
generally interested in
Le 20/06/2012 11:28, Christophe Travert a écrit :
deadalnix , dans le message (digitalmars.D:170272), a écrit :
Le 20/06/2012 10:18, Christophe Travert a écrit :
What is the conclusion here ?
I think it is the same as yours.
My conclusion is that delegate's signature should be the same has
Le 20/06/2012 13:58, Timon Gehr a écrit :
Clarification: 'const' means 'const'. No other qualifiers.
There is no 'const' in that example code. 'immutable' obviously needs to
be transitive regardless of the particular interpretation of 'const'.
const means: maybe immutable.
Or maybe mutable.
On 20 June 2012 14:44, Don Clugston d...@nospam.com wrote:
On 20/06/12 13:04, Manu wrote:
On 20 June 2012 13:51, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 19/06/12 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going
On 20 June 2012 15:30, deadalnix deadal...@gmail.com wrote:
Le 20/06/2012 13:04, Manu a écrit :
Case 1 has no alternative to inline asm. I've thrown out some crazy
ideas to think about (but nobody seems to like them). I still think it
could be addressed though.
Case 2; I'm not convinced.
On 19/06/12 19:19, Iain Buclaw wrote:
Had round one of the code review process, so I'm going to post the main issues
here that most affect D users / the platforms they want to run on / the compiler
version they want to use.
A somewhat different take on these issues -- we've several times now
Le 20/06/2012 14:51, Manu a écrit :
On 20 June 2012 14:44, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 20/06/12 13:04, Manu wrote:
On 20 June 2012 13:51, Don Clugston d...@nospam.com
mailto:d...@nospam.com
mailto:d...@nospam.com
Timon Gehr , dans le message (digitalmars.D:170296), a écrit :
On 06/20/2012 01:36 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:170288), a écrit :
On 06/20/2012 09:16 AM, deadalnix wrote:
Le 19/06/2012 17:49, Timon Gehr a écrit :
The question is, what the meaning
On 06/20/12 09:31, Christophe Travert wrote:
Artur Skawina , dans le message (digitalmars.D:170191), a écrit :
The proper way to do this is not cast, it is to give the proper
constness for all types and methods :
struct S {
int i; this(int i) { this.i = i; }
T* p;
On 20 June 2012 14:01, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 19/06/12 19:19, Iain Buclaw wrote:
Had round one of the code review process, so I'm going to post the main
issues
here that most affect D users / the platforms they want to run on / the
compiler
version
Le 20/06/2012 15:13, Christophe Travert a écrit :
OK, that was not the right argument. Const is transitive according to
the spec. Making it not transitive would break the mutable const
immutable design. You're trying to make an exception for data hidden
behind a delegate, which is a dangerous
Artur Skawina , dans le message (digitalmars.D:170305), a écrit :
On 06/20/12 09:31, Christophe Travert wrote:
Artur Skawina , dans le message (digitalmars.D:170191), a écrit :
The proper way to do this is not cast, it is to give the proper
constness for all types and methods :
struct S
Le 20/06/2012 15:58, Christophe Travert a écrit :
Artur Skawina , dans le message (digitalmars.D:170305), a écrit :
On 06/20/12 09:31, Christophe Travert wrote:
Artur Skawina , dans le message (digitalmars.D:170191), a écrit :
The proper way to do this is not cast, it is to give the proper
On 20/06/12 14:31, Iain Buclaw wrote:
Hands are tied, sorry.
Is this planned as a short-term change for which a long-term solution will be
developed, or is it likely to be a permanent split with DMD?
On 20/06/12 13:22, Manu wrote:
On 20 June 2012 13:59, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
You and I seem to be from different planets. I have almost never
written as asm function which was suitable for inlining.
Take a look at std.internal.math.biguintX86.d
On 06/20/2012 02:38 PM, deadalnix wrote:
Le 20/06/2012 13:58, Timon Gehr a écrit :
Clarification: 'const' means 'const'. No other qualifiers.
There is no 'const' in that example code. 'immutable' obviously
needs to
be transitive regardless of the particular interpretation of 'const'.
const
On 06/20/2012 03:13 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:170296), a écrit :
On 06/20/2012 01:36 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:170288), a écrit :
On 06/20/2012 09:16 AM, deadalnix wrote:
Le 19/06/2012 17:49,
On 06/20/2012 02:32 PM, deadalnix wrote:
Le 20/06/2012 11:28, Christophe Travert a écrit :
deadalnix , dans le message (digitalmars.D:170272), a écrit :
Le 20/06/2012 10:18, Christophe Travert a écrit :
What is the conclusion here ?
I think it is the same as yours.
My conclusion is that
Le 20/06/2012 16:21, Timon Gehr a écrit :
On 06/20/2012 02:38 PM, deadalnix wrote:
Le 20/06/2012 13:58, Timon Gehr a écrit :
Clarification: 'const' means 'const'. No other qualifiers.
There is no 'const' in that example code. 'immutable' obviously
needs to
be transitive regardless of the
Is there any reason not to add this so you can use foo := bar as
a shorthand for auto foo = bar?
On 20 June 2012 17:15, Don Clugston d...@nospam.com wrote:
On 20/06/12 13:22, Manu wrote:
I find optimisers are very good at code simplification, assuming that
you massage the code/expressions to neatly match any architectural quirks.
I also appreciate that good x86 code is possibly the
On 06/20/2012 04:36 PM, deadalnix wrote:
Le 20/06/2012 16:21, Timon Gehr a écrit :
On 06/20/2012 02:38 PM, deadalnix wrote:
Le 20/06/2012 13:58, Timon Gehr a écrit :
Clarification: 'const' means 'const'. No other qualifiers.
There is no 'const' in that example code. 'immutable' obviously
On 20/06/12 14:51, Manu wrote:
On 20 June 2012 14:44, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 20/06/12 13:04, Manu wrote:
On 20 June 2012 13:51, Don Clugston d...@nospam.com
mailto:d...@nospam.com
mailto:d...@nospam.com mailto:d...@nospam.com
Timon Gehr , dans le message (digitalmars.D:170313), a écrit :
OK, I understand what you mean. I think this behavior is dangerous. You
have to add rules to make sure B is not violated. I am not sure this is
worth it.
No additional rules necessary, only loosening of existing rules. (in
the
ixid:
Is there any reason not to add this so you can use foo := bar
as a shorthand for auto foo = bar?
Often I prefer to write:
const foo = bar;
D is more complex than Go...
Bye,
bearophile
On 06/20/2012 04:56 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:170313), a écrit :
OK, I understand what you mean. I think this behavior is dangerous. You
have to add rules to make sure B is not violated. I am not sure this is
worth it.
No additional rules
Le 20/06/2012 16:55, Timon Gehr a écrit :
It works if implicit conversions from 'R delegate(A)' to
'R delegate(A) const' are allowed, as well as looking up an
'R delegate(A) in a const receiver object.
What about conversion from/to immutable ?
Simple application of transitivity. This part is
On 06/20/2012 05:17 PM, deadalnix wrote:
Le 20/06/2012 16:55, Timon Gehr a écrit :
It works if implicit conversions from 'R delegate(A)' to
'R delegate(A) const' are allowed, as well as looking up an
'R delegate(A) in a const receiver object.
What about conversion from/to immutable ?
Simple
On 06/20/2012 05:24 PM, Timon Gehr wrote:
static assert(is(typeof(immutable(S).mutable)==R delegate(A) immutable));
static assert(is(typeof(immutable(S).const_)==R delegate(A) immutable));
Actually,
static assert(is(typeof(cast()immutable(S).mutable)==R delegate(A)
immutable));
static
On 20 June 2012 15:07, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 20/06/12 14:31, Iain Buclaw wrote:
Hands are tied, sorry.
Is this planned as a short-term change for which a long-term solution will
be developed, or is it likely to be a permanent split with DMD?
Likely
How does that address my question? I didn't suggest the
replacement or removal of syntax.
Le 20/06/2012 17:24, Timon Gehr a écrit :
On 06/20/2012 05:17 PM, deadalnix wrote:
Le 20/06/2012 16:55, Timon Gehr a écrit :
It works if implicit conversions from 'R delegate(A)' to
'R delegate(A) const' are allowed, as well as looking up an
'R delegate(A) in a const receiver object.
What
ixid:
How does that address my question? I didn't suggest the
replacement or removal of syntax.
I think your suggestion is not so useful because in many cases
you don't want to use auto. To justify the introduction of a
new syntax it needs to cover many usage cases, or to do something
that
On Wednesday, 20 June 2012 at 14:36:48 UTC, ixid wrote:
Is there any reason not to add this so you can use foo := bar
as a shorthand for auto foo = bar?
No. That is not how it works. You don't swan in and say WHY NOT
ADD THIS SYNTAX GUYZ? _You_ have to justify it. Tell _us_ why
it's useful.
Your array syntax suggestion is a good one. I think both make the
syntax terser and more efficient which is a good justification
for their use.
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclaw ibuc...@ubuntu.com wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on /
the compiler version they want to use.
1) D Inline Asm and naked
On Wednesday, June 20, 2012 13:38:31 Timon Gehr wrote:
Escape the payload anyway and document that the range is invalid after
the container has been destroyed.
That's a given anyway. Ranges from containers are _always_ invalid after the
container that they come from is gone. They can also
On Wednesday, June 20, 2012 13:33:53 Jacob Carlborg wrote:
You do understand that the GCC-style inline assembly will still be
available?
But inline assembler with the syntax that dmd uses is supposed to be part of
the language. So, if gdc doesn't support it, it's not a fully compliant D
On 20 June 2012 17:00, Brad Anderson e...@gnuk.net wrote:
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclaw ibuc...@ubuntu.com wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on /
the
Le 20/06/2012 18:18, Iain Buclaw a écrit :
On 20 June 2012 17:00, Brad Andersone...@gnuk.net wrote:
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclawibuc...@ubuntu.com wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the
It is a terse way of assigning and initializing an automatically
typed variable, helping meld what I understand one of D's aims to
be that of the power of a C/C++ language with some of the
syntactic elegance of languages like Python. In broad terms D and
Go would seem to outline the general
I've made my own nullable type, and I think it works a bit more
naturally than Phobos's in some cases, since it takes advantage
of alias this and typeof(null) and some stuff.
(It's designed to mimic C#'s nullable types.)
Would it be a good addition to Phobos? If not, ideas on what
could be
On 20 June 2012 17:08, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Wednesday, June 20, 2012 13:33:53 Jacob Carlborg wrote:
You do understand that the GCC-style inline assembly will still be
available?
But inline assembler with the syntax that dmd uses is supposed to be part of
the
On 20-06-2012 18:08, Jonathan M Davis wrote:
On Wednesday, June 20, 2012 13:33:53 Jacob Carlborg wrote:
You do understand that the GCC-style inline assembly will still be
available?
But inline assembler with the syntax that dmd uses is supposed to be part of
the language. So, if gdc doesn't
On 20 June 2012 17:23, deadalnix deadal...@gmail.com wrote:
Le 20/06/2012 18:18, Iain Buclaw a écrit :
On 20 June 2012 17:00, Brad Andersone...@gnuk.net wrote:
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclawibuc...@ubuntu.com wrote:
Hi,
Had round one of the code review process, so I'm
Le 20/06/2012 18:40, Iain Buclaw a écrit :
On 20 June 2012 17:23, deadalnixdeadal...@gmail.com wrote:
Le 20/06/2012 18:18, Iain Buclaw a écrit :
On 20 June 2012 17:00, Brad Andersone...@gnuk.netwrote:
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclawibuc...@ubuntu.comwrote:
Hi,
Had
Mehrdad:
Would it be a good addition to Phobos? If not, ideas on what
could be improved?
What are the advantages over this one?
http://dlang.org/phobos/std_typecons.html#Nullable
Bye,
bearophile
On 20 June 2012 17:44, deadalnix deadal...@gmail.com wrote:
Le 20/06/2012 18:40, Iain Buclaw a écrit :
On 20 June 2012 17:23, deadalnixdeadal...@gmail.com wrote:
Le 20/06/2012 18:18, Iain Buclaw a écrit :
On 20 June 2012 17:00, Brad Andersone...@gnuk.net wrote:
On Tue, Jun 19, 2012
On Wednesday, 20 June 2012 at 16:09:14 UTC, Jonathan M Davis
wrote:
But inline assembler with the syntax that dmd uses is supposed
to be part of
the language. So, if gdc doesn't support it, it's not a fully
compliant D
compiler.
I am not too sure about that: In my opinion, your description
On Wednesday, June 20, 2012 16:36:47 ixid wrote:
Is there any reason not to add this so you can use foo := bar as
a shorthand for auto foo = bar?
Any proposed feature must have a solid use case and reason for being in the
language. It needs to add real value. If you want a feature in the
On Wednesday, 20 June 2012 at 16:52:26 UTC, bearophile wrote:
Mehrdad:
Would it be a good addition to Phobos? If not, ideas on what
could be improved?
What are the advantages over this one?
http://dlang.org/phobos/std_typecons.html#Nullable
Bye,
bearophile
I thought I mentioned?
1. It
On Wednesday, 20 June 2012 at 17:43:27 UTC, Mehrdad wrote:
I thought I mentioned?
1. It uses typeof(null) to _actually_ integrate with _null_,
instead of making up methods like nullify(), get(), etc.
2. It tries to do what C# does. (opEquals, opCmp, etc.)
In case that wasn't clear...
1.
On Wednesday, 20 June 2012 at 17:19:08 UTC, Jonathan M Davis
wrote:
On Wednesday, June 20, 2012 16:36:47 ixid wrote:
Is there any reason not to add this so you can use foo := bar
as
a shorthand for auto foo = bar?
Any proposed feature must have a solid use case and reason for
being in the
I see that this is not going to happen for D2 but as a debate for
a future D3 (and please just ignore my post if you find this in
some way exasperating, I am interested but do not mean to cause
friction):
Just as a question about the existing syntax as you listed
combinations to learn as a
1 - 100 of 155 matches
Mail list logo
