[enum foo = Test.test2;]
On 2013-08-17 01:03, JS wrote:
pragma( msg, foo ); // why does it print: cast(Test)2
// it should be: test2
// or at least simply: 2
It is 2! Notice the 2 at the end? The cast is just mumbo jumbo due to
the the compiler deals with the stuff. You can remove the casts
m
On Saturday, 17 August 2013 at 05:22:53 UTC, captaindet wrote:
are these bugs or expected behavior? (2 issues, see code below)
i thought enums are just compile time copy&paste magic so i
cannot think of a reason why it should not be available at
compile time...
if buggy, what is broken, enum
On Saturday, 17 August 2013 at 05:37:18 UTC, H. S. Teoh wrote:
On Sat, Aug 17, 2013 at 07:19:19AM +0200, Alan wrote:
On Saturday, 17 August 2013 at 05:05:12 UTC, H. S. Teoh wrote:
>On Sat, Aug 17, 2013 at 06:53:16AM +0200, Alan wrote:
>>Hello! The past few hours I've been working on some things
On Sat, Aug 17, 2013 at 07:19:19AM +0200, Alan wrote:
> On Saturday, 17 August 2013 at 05:05:12 UTC, H. S. Teoh wrote:
> >On Sat, Aug 17, 2013 at 06:53:16AM +0200, Alan wrote:
> >>Hello! The past few hours I've been working on some things and I
> >>came accross a small bug.
> >>
> >>I'm essentiall
are these bugs or expected behavior? (2 issues, see code below)
i thought enums are just compile time copy&paste magic so i cannot think of a
reason why it should not be available at compile time...
if buggy, what is broken, enum (really bad) or pragma(msg,...) (worse enough)?
and are they in b
On Saturday, 17 August 2013 at 05:05:12 UTC, H. S. Teoh wrote:
On Sat, Aug 17, 2013 at 06:53:16AM +0200, Alan wrote:
Hello! The past few hours I've been working on some things
and I
came accross a small bug.
I'm essentially practicing lexing and parsing by implementing a
(very) simple languag
On Sat, Aug 17, 2013 at 06:53:16AM +0200, Alan wrote:
> Hello! The past few hours I've been working on some things and I
> came accross a small bug.
>
> I'm essentially practicing lexing and parsing by implementing a
> (very) simple language. Everything is going great so far (variable
> declarat
Hello! The past few hours I've been working on some things and I
came accross a small bug.
I'm essentially practicing lexing and parsing by implementing a
(very) simple language. Everything is going great so far
(variable declarations, writing to stdout etc...) but I have a
small problem wi
On Friday, 16 August 2013 at 22:11:24 UTC, Jonathan M Davis wrote:
On Friday, August 16, 2013 23:18:51 Carl Sturtivant wrote:
The operator overloading page in the Language Reference and the
operator overloading discussion in TDLP say different things
about
T opCast(bool)() if(is(T==bool))
and
On Friday, 16 August 2013 at 22:11:24 UTC, Jonathan M Davis wrote:
On Friday, August 16, 2013 23:18:51 Carl Sturtivant wrote:
The operator overloading page in the Language Reference and the
operator overloading discussion in TDLP say different things
about
T opCast(bool)() if(is(T==bool))
and
On Sat, Aug 17, 2013 at 01:21:13AM +0200, DLearner wrote:
> Hi,
>
> Please, under Debian / GDC, what functions are available to read
> keys directly as pressed (no wait for )?
>
> And how used (infinite loop exited on specific keycode, eg for
> 'Esc')?
Currently, Phobos doesn't have this capabil
On Friday, 16 August 2013 at 21:41:10 UTC, Ali Çehreli wrote:
import std.typetuple;
void main()
{
alias TT = TypeTuple!(int, string);
TT twoVars;
static assert(is(typeof(twoVars[0]) == int));
static assert(is(typeof(twoVars[1]) == string));
}
I am speechless. :)
Ali
Seeing as
Hi,
Please, under Debian / GDC, what functions are available to read
keys directly as pressed (no wait for )?
And how used (infinite loop exited on specific keycode, eg for
'Esc')?
Jonathan M Davis:
I'd advise against that,
Related:
http://d.puremagic.com/issues/show_bug.cgi?id=3926
Bye,
bearophile
On Friday, August 16, 2013 14:35:53 Ali Çehreli wrote:
> On 08/16/2013 02:18 PM, Carl Sturtivant wrote:
> > The operator overloading page in the Language Reference and the operator
> > overloading discussion in TDLP say different things about
> >
> > T opCast(bool)() if(is(T==bool))
>
> The curre
On Friday, August 16, 2013 23:18:51 Carl Sturtivant wrote:
> The operator overloading page in the Language Reference and the
> operator overloading discussion in TDLP say different things about
> T opCast(bool)() if(is(T==bool))
> and experimentally it seems that in any context where a bool is
> ex
On 08/16/2013 09:02 AM, Dicebot wrote:
> It does complicate things that sometimes TypeTuple is accepted in cases
> where comma-separated list does not:
>
> import std.typetuple;
>
> void main()
> {
> //alias TT = TypeTuple!(int, string);
> //TT twoVars;
> (int, string) twoVars; //
On 08/16/2013 02:18 PM, Carl Sturtivant wrote:
> The operator overloading page in the Language Reference and the operator
> overloading discussion in TDLP say different things about
>T opCast(bool)() if(is(T==bool))
The current syntax is the following:
bool opCast(T : bool)() const
> a
On 08/16/2013 02:35 PM, Ali Çehreli wrote:
> As far as I know, opCast in general is for explicit type conversions,
> not explicit.
Ha! Should be: ... is for explicit type conversions, not *implicit*.
Ali
On Friday, 16 August 2013 at 15:47:21 UTC, Joseph Rushton
Wakeling wrote:
On 08/16/2013 05:40 PM, JS wrote:
Can you describe how this helps?
Sure, if you use A the compiler should be able to optimize
method calls but you
can't use A in inheritance because it is a final class. e.g.,
The poin
The operator overloading page in the Language Reference and the
operator overloading discussion in TDLP say different things about
T opCast(bool)() if(is(T==bool))
and experimentally it seems that in any context where a bool is
expected and x occurs (where x is a struct with such an opCast
On Friday, 16 August 2013 at 18:20:46 UTC, H. S. Teoh wrote:
I'm not an OOP *hater* per se, but I *am* a skeptic about
applying OOP
anywhere and everywhere, even when it doesn't really belong
(*cough*Java*cough*). Different problems need different
solutions;
insisting on turning a screw with a
On Fri, Aug 16, 2013 at 07:51:22PM +0200, Joseph Rushton Wakeling wrote:
> On Friday, 16 August 2013 at 17:08:36 UTC, Dicebot wrote:
[...]
> >From the conceptual purity point of view I still think that having
> >bunch of template mixins instead of _A and just combining them
> >into A or B is the pr
On Friday, 16 August 2013 at 17:08:36 UTC, Dicebot wrote:
That makes some sense indeed, all you need is to stop naming
base class "_A" and give it a proper meaningful name that
reflects its role in object model :)
Hey, it's shorthand :-)
From the conceptual purity point of view I still think
On Friday, 16 August 2013 at 16:27:37 UTC, Joseph Rushton
Wakeling wrote:
On 08/16/2013 06:12 PM, Dicebot wrote:
Maybe we can come with a better proposal if you explain what
object model are
you trying to achieve?
The idea is maybe more to be able to have,
_A -- base class
A : _A --
On 08/16/2013 06:12 PM, Dicebot wrote:
> Maybe we can come with a better proposal if you explain what object model are
> you trying to achieve?
The idea is maybe more to be able to have,
_A -- base class
A : _A -- final class that doesn't change _A's functionality
B : _A -- final cla
On Friday, 16 August 2013 at 14:15:50 UTC, H. S. Teoh wrote:
I would do it myself, except that after reading Kenji's notes
on #10803
I'm no longer so sure I understand it myself. :-/
+1 :D
It very is likely that you in fact want A to be a struct and _A -
template mixin.
In other words, you are trying to express a relationship that
does not really model anything in OOP terms. You proposal will
work but it will essentially be just hacky implementation of
mixins with some extra in
On Friday, 16 August 2013 at 15:40:35 UTC, Ali Çehreli wrote:
Exactly. Only then this concept would be easy to understand and
explain. It would make "a comma-separated list of
expressions/types" a language construct. Done.
It does complicate things that sometimes TypeTuple is accepted in
case
On 08/16/2013 05:40 PM, JS wrote:
> Can you describe how this helps?
>
> Sure, if you use A the compiler should be able to optimize method calls but
> you
> can't use A in inheritance because it is a final class. e.g.,
The point is, you should be able to use _A for inheritance, A for performance
On 08/16/2013 04:09 AM, Timon Gehr wrote:
> IMO it should work everywhere a comma-separated list of
> expressions/types is expected.
Exactly. Only then this concept would be easy to understand and explain.
It would make "a comma-separated list of expressions/types" a language
construct. Done.
On Friday, 16 August 2013 at 15:12:03 UTC, Joseph Rushton
Wakeling wrote:
Hi all,
I'm writing some class-based code and so my concerns have
turned to the issue of
final classes vs. inheritance.
Suppose that you want a particular class to be able to act as a
base class, but
also to perform at
Hi all,
I'm writing some class-based code and so my concerns have turned to the issue of
final classes vs. inheritance.
Suppose that you want a particular class to be able to act as a base class, but
also to perform at top speed. Is the following kind of pattern worth
considering:
class _A
On Friday, 16 August 2013 at 06:39:42 UTC, Jacob Carlborg wrote:
No, I don't think so. At least on Mac OS X it always tell you
the architecture:
void foo();
void main ()
{
foo();
}
Undefined symbols for architecture x86_64:
"_D4main3fooFZv", referenced from:
__Dmain in main.d.o
ld
On Thu, Aug 15, 2013 at 11:18:21PM -0700, Jonathan M Davis wrote:
[...]
> You should probably read this article if you haven't:
>
> http://dlang.org/tuple.html
>
> Unfortunately, it muddles things a fair bit, because it uses Tuple
> instead of std.typetuple.TypeTuple, and then it talks about expr
On Friday, 16 August 2013 at 04:14:04 UTC, Ali Çehreli wrote:
...
dlang.org documentation on this topic is quite confusing,
unfortunately. There was a small discussion in this
http://d.puremagic.com/issues/show_bug.cgi?id=10803 bug report
recently where Kenji has surprised me a lot with expl
On 08/16/2013 01:09 PM, Timon Gehr wrote:
- Arguments to string mixins:
mixin(Seq!"int x=2;"); // error
fixed.
On 08/16/2013 06:14 AM, Ali Çehreli wrote:
I know of three places a TypeTuple can be used at:
1) Function parameter list
2) Template parameter list
In fact, no.
template A(Seq!(int,int) a){ enum A=a[0]; } // error
3) Array literal element list
Are there more?
...
I assume you mean just
On Thursday, 15 August 2013 at 18:54:40 UTC, Jesse Phillips wrote:
I don't have an answer, but in case you are not familiar with
cryptic linker:
On Wednesday, 14 August 2013 at 13:21:49 UTC, Gary Willoughby
wrote:
But when i import it and use the getUnixTime function i get
the following linke
On Friday, 16 August 2013 at 05:39:32 UTC, Meta wrote:
On Friday, 16 August 2013 at 04:14:04 UTC, Ali Çehreli wrote:
I know of three places a TypeTuple can be used at:
1) Function parameter list
2) Template parameter list
3) Array literal element list
Are there more?
import std.typetuple;
40 matches
Mail list logo
