This doesn't work when the method is marked as @property. Any
idea why is that so?
On Wednesday, 5 June 2013 at 02:19:38 UTC, Jonathan M Davis wrote:
is(typeof(A.func) == const)
- Jonathan M Davis
On Wednesday, June 05, 2013 08:52:35 lomereiter wrote:
This doesn't work when the method is marked as @property. Any
idea why is that so?
On Wednesday, 5 June 2013 at 02:19:38 UTC, Jonathan M Davis wrote:
is(typeof(A.func) == const)
- Jonathan M Davis
I don't know. My first guess
On Tue, 04 Jun 2013 23:47:07 +0100, ixid nuacco...@gmail.com wrote:
On Monday, 3 June 2013 at 09:29:20 UTC, Regan Heath wrote:
On Fri, 31 May 2013 21:26:56 +0100, ixid nuacco...@gmail.com wrote:
We really don't want D to become a TMTOWTDI language. Ideally there
should be 1 right way and
On Wednesday, 5 June 2013 at 09:02:44 UTC, Regan Heath wrote:
On Tue, 04 Jun 2013 23:47:07 +0100, ixid nuacco...@gmail.com
wrote:
On Monday, 3 June 2013 at 09:29:20 UTC, Regan Heath wrote:
On Fri, 31 May 2013 21:26:56 +0100, ixid
nuacco...@gmail.com wrote:
We really don't want D to become
Hi all,
I'd like to design a unittest that will fail -- that is, it will trigger an
assert() or enforce() failure inside the function it is testing.
How would I go about doing this so that the unittest {} block will confirm the
failure and count this as a pass?
Thanks best wishes,
-- Joe
Am Wed, 05 Jun 2013 14:31:58 +0200
schrieb Joseph Rushton Wakeling joseph.wakel...@webdrake.net:
Hi all,
I'd like to design a unittest that will fail -- that is, it will
trigger an assert() or enforce() failure inside the function it is
testing.
How would I go about doing this so that
Joseph Rushton Wakeling:
I'd like to design a unittest that will fail -- that is, it
will trigger an
assert() or enforce() failure inside the function it is testing.
How would I go about doing this so that the unittest {} block
will confirm the
failure and count this as a pass?
For the
Thanks to both of you :-) In the end I decided to go with collectExceptionMsg
as this allows a very precise unittest.
http://dpaste.dzfl.pl/79c29c19
(What you want to do does not work, but the issue is not that
UFCS does not work with opCall. It does.)
Thanks for the insights, undfortunatelly you're right. Is this
behaviour on purpose, or considered a bug ?
Couldn't read that much out of the original
On Saturday, 1 June 2013 at 14:41:13 UTC, Shriramana Sharma wrote:
On Sat, Jun 1, 2013 at 7:57 PM, Anthony Goins
neonto...@gmail.com wrote:
Sometimes running ldconfig will solve wierd problems like this.
Thanks and I tried that just now but no fruit. :-(
Try a *full* removal of the deb
On Saturday, 1 June 2013 at 01:10:05 UTC, Shriramana Sharma wrote:
On Sat, Jun 1, 2013 at 6:02 AM, Anthony Goins
neonto...@gmail.com wrote:
Works for me ubuntu 64.
Do you have both versions installed?
Of course not. The later install from the distributed DEB (from
dlang.org) overwrites the
I've been doing some coding and noticed something strange with
core.sys.posix.signal. In the following snippet you will see that
i have to decorate the handleTermination function with extern(C)
to satisfy the type requirements of the bsd_signal function.
import core.sys.posix.signal;
import
I've been using the -property compiler flag when i compile
programs and thought it was pretty cool but i've recently had a
conversation with someone who has informed me it's broken and a
bad idea.
Never, ever, ever use -property. Its implementation is totally
wrong
and based on a flawed idea
Not going to look into the file, but I'm pretty sure bsd_signal
is function for an external C library right?
If that is the case, it must use C calling convention, so yes
this is correct.
On 06/05/2013 05:11 PM, ParticlePeter wrote:
http://dpaste.dzfl.pl/79c29c19
(What you want to do does not work, but the issue is not that UFCS
does not work with opCall. It does.)
Thanks for the insights, undfortunatelly you're right. Is this behaviour
on purpose, or considered a bug ?
On Wednesday, June 05, 2013 20:09:29 Gary Willoughby wrote:
I've been using the -property compiler flag when i compile
programs and thought it was pretty cool but i've recently had a
conversation with someone who has informed me it's broken and a
bad idea.
There have been quite a few
On Wednesday, 5 June 2013 at 18:54:45 UTC, Jesse Phillips wrote:
Not going to look into the file, but I'm pretty sure bsd_signal
is function for an external C library right?
If that is the case, it must use C calling convention, so yes
this is correct.
Ah sorry i wasn't clear.
The question
I use @property consistently because I think it is absolutely
ugly and confusing to call functions without brackets or to mix
both versions. But I also use UFCS as good as never (I don't like
it that much)
And as long as there is the possibility to enable a strict
behavior with @property and
On Wednesday, 5 June 2013 at 20:43:54 UTC, Namespace wrote:
I use @property consistently because I think it is absolutely
ugly and confusing to call functions without brackets or to mix
both versions.
To specify this point:
I think it's ugly and confusing to be able to call *all*
functions
I had a better proposal:
http://forum.dlang.org/thread/rftboygivwmwizeyw...@forum.dlang.org
optional parens everywhere except last position of function chain.
This makes it visually unambiguous what is a function vs function call and
avoids all but last parens, makes @property/(-property)
And what if I like to write a property getter?
@property
float x() const pure nothrow { ... }
@property
void x(float x) { ... }
This should still be possible, otherwise you will not convince me.
how do i get a stacktrace inside handleTermination?
If not currently possible, could we have a compile flag that would enable
this kind of feature? (making code slower would be OK, its an opt in
feature)
Ideally we'd also be able to walk up or down the stack trace (kind of what
gdb would do, but
You probably don't want to read it. It's huge. I'll try and
summarize the situation.
- Jonathan M Davis
Thanks for a great overview, that's cleared things up nicely.
On Wednesday, June 05, 2013 22:43:53 Namespace wrote:
I use @property consistently because I think it is absolutely
ugly and confusing to call functions without brackets or to mix
both versions. But I also use UFCS as good as never (I don't like
it that much)
I tend to agree, but the general
This is really sad. I think that's almost as big a mistake as the
lack of rvalue references ( I know you say it will come one day,
but don't lie to yourself ;) ).
The question is, how much the public will like it, if D should
ever become popular.
Anyway, this is IMO a huge mistake, to not offer
On Wednesday, June 05, 2013 13:55:30 Timothee Cour wrote:
I had a better proposal:
http://forum.dlang.org/thread/rftboygivwmwizeyw...@forum.dlang.org
optional parens everywhere except last position of function chain.
This makes it visually unambiguous what is a function vs function call
Isn't the compiler smart enough to detect UFSC and enable then
optional parenthesis and force they otherwise, except the
function is already marked with @property?
That would be a good midway.
But I just wonder: Is this really important enough to do this in
the near future? I know so much
On Wednesday, 5 June 2013 at 21:36:26 UTC, Jonathan M Davis wrote:
Walter and Andrei pretty much consider
@property to have been a failure and seem to want to get rid of
@property and go to pretty much what we had before.
Blah I hope that doesn't happen.
I'm the author of the quoted bit in
Sorry I don't get it. Are you for or against optional parenthesis
for function which are not marked with @property?
On Wednesday, 5 June 2013 at 22:31:15 UTC, Namespace wrote:
Sorry I don't get it. Are you for or against optional
parenthesis for function which are not marked with @property?
I'm for optional parens, but I'm also for @property, because the
problems @property ought to be fixing are semantic,
On Thursday, June 06, 2013 00:25:20 Adam D. Ruppe wrote:
BUT, and this is important, items #1, #2, and #3 are *still*
problems! That's what @property can and should fix. Throwing it
away entirely is a step in the wrong direction.
I don't disagree, but an appropriate proposal has to be
On Thursday, June 06, 2013 01:00:12 Adam D. Ruppe wrote:
On Wednesday, 5 June 2013 at 22:31:15 UTC, Namespace wrote:
Sorry I don't get it. Are you for or against optional
parenthesis for function which are not marked with @property?
I'm for optional parens, but I'm also for @property,
On Wed, Jun 05, 2013 at 08:08:16PM -0400, Jonathan M Davis wrote:
On Thursday, June 06, 2013 01:00:12 Adam D. Ruppe wrote:
On Wednesday, 5 June 2013 at 22:31:15 UTC, Namespace wrote:
Sorry I don't get it. Are you for or against optional
parenthesis for function which are not marked with
On Wednesday, June 05, 2013 17:12:38 H. S. Teoh wrote:
I was hoping for a clean way for functions to imitate class/struct
variables via @property, independently of whether or not non-@property
functions are allowed to be called without parens. But alas, it was not
to be. :-/
Part of the
On Thursday, 6 June 2013 at 00:08:31 UTC, Jonathan M Davis wrote:
Which is essentially the position of weak property enforcement.
Yes, though I wish we would stop calling it 'enforcement' because
nothing actually needs to be especially enforced if we do it
right!
@property int foo();
On 06/05/2013 12:02 AM, Jonathan M Davis wrote:
On Wednesday, June 05, 2013 08:52:35 lomereiter wrote:
This doesn't work when the method is marked as @property. Any
idea why is that so?
On Wednesday, 5 June 2013 at 02:19:38 UTC, Jonathan M Davis wrote:
is(typeof(A.func) == const)
- Jonathan
On Wednesday, 5 June 2013 at 20:40:59 UTC, Gary Willoughby wrote:
On Wednesday, 5 June 2013 at 18:54:45 UTC, Jesse Phillips wrote:
Not going to look into the file, but I'm pretty sure
bsd_signal is function for an external C library right?
If that is the case, it must use C calling
37 matches
Mail list logo
