On 2013-07-05 14:31, Andrej Mitrovic wrote:
Related: https://github.com/D-Programming-Language/dmd/pull/1485
Although this pull does the opposite of what's requested here.
In this case I don't think you want to show the methods the mixin
expands to.
--
/Jacob Carlborg
On 2013-07-03 03:42, Daniel Murphy wrote:
You should probably try using template mixins, if all you need to do is
expand some code.
I don't think that works so well together with ddoc comments. Ideally
you should be able to do something like this:
class Foo
{
/// Get/set bar
mixin
Jacob Carlborg d...@me.com wrote in message
news:kr673g$179s$1...@digitalmars.com...
On 2013-07-03 03:42, Daniel Murphy wrote:
You should probably try using template mixins, if all you need to do is
expand some code.
I don't think that works so well together with ddoc comments. Ideally you
On 7/5/13, Jacob Carlborg d...@me.com wrote:
I don't think that works so well together with ddoc comments. Ideally
you should be able to do something like this:
class Foo
{
/// Get/set bar
mixin property!(int, bar);
}
Related:
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
I believe that the way that this sort of enhancement has
typically been suggested
Oh hey, I remember the DIP23 madness. Is it that time again
already?
is to do something like
public @property int value;
Yes. Please, yes.
On 07/05/2013 03:53 PM, Wyatt wrote:
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
I believe that the way that this sort of enhancement has typically
been suggested
Oh hey, I remember the DIP23 madness. Is it that time again already?
is to do something like
public
On Wednesday, 3 July 2013 at 01:42:06 UTC, Daniel Murphy wrote:
You should probably try using template mixins, if all you need
to do is
expand some code.
https://github.com/D-Programming-Language/phobos/pull/1294
On Tuesday, 2 July 2013 at 04:49:55 UTC, estew wrote:
It's location in the class my not be the same but that is,
in
general, irrelevant unless you are messing with the bits of
the class.
Actually we do this a lot in C++ where I work to ensure proper
alignment. We are also starting to
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
I believe that the way that this sort of enhancement has
typically been
suggested is to do something like
public @property int value;
which would be lowered to something like
public @property int value() @safe const pure
On Tuesday, July 02, 2013 19:49:39 Kapps wrote:
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
I believe that the way that this sort of enhancement has
typically been
suggested is to do something like
public @property int value;
which would be lowered to something
Kapps opantm2+s...@gmail.com wrote in message
news:zroaabiwkaxqybrtd...@forum.dlang.org...
As someone who uses properties almost everywhere, and almost never uses
public fields, this is one of my biggest gripes with D remaining. It's
incredibly annoying to have to do things like
private
On 2013-07-01 03:43, JS wrote:
But yet absolutely useless and does nothing over using a field directly.
The advantage is that you get virtual methods. I also think it should be
possible to manually implement just the setter, or getter. The compiler
would only generate what's not already
On 06/30/2013 08:54 PM, JS wrote:
On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:
I have the complete opposite view: Seeing what m_data explicitly in
the code would be simpler than reading code to see that data.value
would mean implicit storage.
huh? There is absolutely no
On Monday, 1 July 2013 at 16:24:40 UTC, Ali Çehreli wrote:
On 06/30/2013 08:54 PM, JS wrote:
On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:
I have the complete opposite view: Seeing what m_data
explicitly in
the code would be simpler than reading code to see that
data.value
It's location in the class my not be the same but that is, in
general, irrelevant unless you are messing with the bits of
the class.
Actually we do this a lot in C++ where I work to ensure proper
alignment. We are also starting to do this in D where we have C++
- D bindings so we can make
struct Foo
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } //
write property
private: int m_data;
}
It would be nice if properties had an internal variable to use
instead of having to declare it explicitly:
On Monday, July 01, 2013 03:22:15 JS wrote:
struct Foo
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } //
write property
private: int m_data;
}
It would be nice if properties had an internal variable to
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
On Monday, July 01, 2013 03:22:15 JS wrote:
struct Foo
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; }
//
write property
private: int m_data;
}
On 07/01/2013 03:22 AM, JS wrote:
struct Foo
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } // write
property
private: int m_data;
}
It would be nice if properties had an internal variable to use instead
of
On 7/1/13, JS js.m...@gmail.com wrote:
But yet absolutely useless and does nothing over using a field
directly.
Not completely useless, this syntax would theoretically disallow
taking the address of such a field.
On Monday, July 01, 2013 04:03:41 Andrej Mitrovic wrote:
On 7/1/13, JS js.m...@gmail.com wrote:
But yet absolutely useless and does nothing over using a field
directly.
Not completely useless, this syntax would theoretically disallow
taking the address of such a field.
Yeah. public
W dniu 01.07.2013 03:35, Jonathan M Davis pisze:
On Monday, July 01, 2013 03:22:15 JS wrote:
struct Foo
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } //
write property
private: int m_data;
}
It would be
On 06/30/2013 06:43 PM, JS wrote:
On Monday, July 01, 2013 03:22:15 JS wrote:
struct Foo
{
@property int data() { return m_data; } // read property
@property int data(int value) { return m_data = value; } //
write property
private: int m_data;
}
It would be nice if
On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:
On 06/30/2013 06:43 PM, JS wrote:
On Monday, July 01, 2013 03:22:15 JS wrote:
struct Foo
{
@property int data() { return m_data; } // read
property
@property int data(int value) { return m_data = value;
} //
write
24 matches
Mail list logo
