On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby
wrote:
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma
via Digitalmars-d-
I submit that the syntax for attributes should be streamlined.
Shall I
go and open a Bugzilla item?
No need: http://wiki.dlang.org/DIP64
On Friday, October 24, 2014 23:38:38 Chris Williams via Digitalmars-d-learn
wrote:
On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby
wrote:
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma
via Digitalmars-d-
I submit that the syntax for attributes should
On Thu, 23 Oct 2014 06:29:12 +0530
Shriramana Sharma via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I submit that the syntax for attributes should be streamlined. Shall I
go and open a Bugzilla item?
hehe.
https://issues.dlang.org/show_bug.cgi?id=13388
https://issues.dlang.org
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma
via Digitalmars-d-
I submit that the syntax for attributes should be streamlined.
Shall I
go and open a Bugzilla item?
No need: http://wiki.dlang.org/DIP64
On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via
Digitalmars-d-learn wrote:
besides, no serious language can live without legacy.
legacy is a sign of maturity. ;-)
So you are basically saying that D is a teenager for whom wearing
ugly make-up is a sign of maturity?
On Thu, 23 Oct 2014 07:47:00 +
via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via
Digitalmars-d-learn wrote:
besides, no serious language can live without legacy.
legacy is a sign of maturity. ;-)
So you are
everyone agrees and yet Walter won't make the change, but there
are also plenty where there definitely isn't a consensus. For
attributes, there's a consensus that the situation is not ideal,
but there definitely isn't a consensus on what we should do about
it or whether it's worth breaking
you wrote here.
There _are_ cases where most
everyone agrees and yet Walter won't make the change, but there
are also plenty where there definitely isn't a consensus. For
attributes, there's a consensus that the situation is not ideal,
but there definitely isn't a consensus on what we should
On Thursday, 23 October 2014 at 22:20:28 UTC, ketmar via
Digitalmars-d-learn wrote:
i love D and i want D to be widespread, but what makes me love
D is
it's attitude to fixing stupid legacy we have in C and C++. and
now it
seems to me that someone should start BetterD project to fix
legacy
we
On 10/24/2014 7:20 AM, ketmar via Digitalmars-d-learn wrote:
why can't i see that J. Random in recent discussion about deprecating
prefix 'const'? the universal answer was: yes, break our code NOW!
PLEASE! including people from the companies with big D codebases.
There are people out there
Hello. See http://dlang.org/attribute. 3 attributes starting at
http://dlang.org/attribute#disable have a @ in front. Apparently safe,
trusted and system also do, though these are documented elsewhere:
http://dlang.org/function.html#function-safety.
Why are some language-defined attributes
On Wednesday, 22 October 2014 at 19:13:58 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
Hello. See http://dlang.org/attribute. 3 attributes starting at
http://dlang.org/attribute#disable have a @ in front.
Apparently safe,
trusted and system also do, though these are documented
I thought D was beyond carrying historical baggage. DMD 2.x is not
necessarily language-compatible with DMD 2.(x+1) since the language is
still evolving. You can deprecate one syntax and enforce the other in
a later version.
I submit that the syntax for attributes should be streamlined. Shall I
the
other in
a later version.
I submit that the syntax for attributes should be streamlined.
Shall I
go and open a Bugzilla item?
LOL. I understand the sentiment, but it's a waste of time. We've
long since reached the point where we try and not break people's
existing code unless we have
On 10/23/14, Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
So, yes, we do have historical baggage, albeit nowhere near as
much as C++ does.
OK understood, but I may just go and file that bug so that if there is
a future D 3 series, then stuff like this can be
On Thursday, 23 October 2014 at 02:22:41 UTC, Jonathan M Davis
wrote:
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
LOL. I understand the sentiment, but it's a waste of time.
Jonathan,
I agree It's impossible to debate such thing with Walter
On Thu, Oct 23, 2014 at 10:50:07AM +0530, Shriramana Sharma via
Digitalmars-d-learn wrote:
[...]
So I agree with you that for now this is not an urgent need. I guess
when we clean out all that ! = stuff this can be done too, or
something like that...
[...]
I believe those flying-saucer
this be a
bad idea in some way I cannot see?
I suppose the same question is valid for other attributes, like 'nothrow'
and '@safe'.
Thank you,
LMB
is valid for other attributes, like
'nothrow'
and '@safe'.
Actually, you can undo @safe with an explicit @system. nothrow
(and pure) are in the same boat as @nogc
Thank you,
LMB
Solutions I can see would be to:
a) Put your unittests in a separate module.
b) Place your unittests before
?
Nope. At best, you might be able to *declare* a function that is GC, but
even then, you wouldn't be able to call it.
I suppose the same question is valid for other attributes, like 'nothrow'
and '@safe'.
Actually, you can undo @safe with an explicit @system. nothrow (and
pure
On Wed, 20 Aug 2014 01:38:52 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler
function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like so:
auto function() @auto
{}
instead of manually writing:
auto function() pure @safe nothrow
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like
On Wednesday, 20 August 2014 at 01:38:53 UTC, uri wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
Hi!
I'm trying to handle the fact that an attribute has change since
I've set it for the first time (by desialising a bson), to
abstract the only-modified fields update with vibe.d and mongodb,
without storing two times the values. The idea is to have
something like that :
class Base {
...
I found this, which excactly is what I want to do :
http://dlang.org/phobos/std_signals.html
So in other terms, I want to abstract that, maybe with an UDA ?
But can I do this without compile time code changes ?
Thanks again!
But if I write
@(hello) struct Hello {}
so all of the variables that have type Hello will have attribute
@(hello) like come type qualifier because attribute is a part
of declaration of Hello. Do I understand correctly?
the symbol Hello that will have the attribute
@(hello). Attributes are attached to symbols, not types or
values.
I'm trying to declare format for database record in compile time.
I consider to use attributes fo this. Can I do something similar
to this code?
struct RecordFormat(T)
{}
alias Format = RecordFormat!( @(cool) int );
pragma( msg, Format );
void main()
{
}
Or I want something strange
UDA's are compile-time metadata associated with a specific
declaration. So in something like:
@foo int x;
The @foo is attached to x, but is not part of the type.
On Wed, Jun 25, 2014 at 05:10:06PM +, Chris Nicholson-Sauls via
Digitalmars-d-learn wrote:
UDA's are compile-time metadata associated with a specific
declaration. So in something like:
@foo int x;
The @foo is attached to x, but is not part of the type.
The term attribute is a bit
On Wednesday, 25 June 2014 at 17:21:21 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
The term attribute is a bit confusing, especially since
property is
also used in the language to refer to something completely
different. A
better term is perhaps annotation. The @foo is an annotation
on x,
Hi !
http://dpaste.dzfl.pl/2fa3dd2ea834
Why S.init not pure ? Is it expected behavior or bug ?
Thanks!
On Friday, 25 April 2014 at 07:59:29 UTC, Temtaime wrote:
Hi !
http://dpaste.dzfl.pl/2fa3dd2ea834
Why S.init not pure ? Is it expected behavior or bug ?
Thanks!
Fix
http://dpaste.dzfl.pl/03f73cd958f4
Hi, MrSmith !
Yes, i know that, but my question isn't about it.
I want to type `pure:` at module's beginning and have all
function(in classes, too) declared as pure.
I think `pure:` should do it. But it doesn't.
On Friday, 25 April 2014 at 09:08:50 UTC, Temtaime wrote:
Hi, MrSmith !
Yes, i know that, but my question isn't about it.
I want to type `pure:` at module's beginning and have all
function(in classes, too) declared as pure.
I think `pure:` should do it. But it doesn't.
pure is not a
Hi ! Thanks for reply.
Why so ?
And why @nogc not transitive too ?
a compile-time error if you tries
to use it
where it's not meant to be.
I'm not sure how I could do that.
You can recurse into UDAs for attributes and pass along the type
that had the uda. A static assert could verify that it's used on
the correct type.
(For my library, that would mean
On Monday, 16 September 2013 at 07:36:13 UTC, simendsjo wrote:
I don't have a full example without adding a lot of code, but
this partial
example might give you the gist of it.
// This is the type that validates
struct matches(string mustMatch)
{
alias re = ctRegex!(mustMatch);
On 2013-09-20 08:59, ilya-stromberg wrote:
Can I explicitly specify when I can use attribute? Something like
this:
@attribute(field)
struct matches(string mustMatch)
{
}
string wrongAttribute
{
}
class Foo
{
@matches([0-9]+)
string someNumber; //OK, it's a field
}
@matches([0-9]+)
On Friday, 20 September 2013 at 07:57:43 UTC, Jacob Carlborg
wrote:
On 2013-09-20 08:59, ilya-stromberg wrote:
Can I explicitly specify when I can use attribute? Something
like
this:
@attribute(field)
struct matches(string mustMatch)
{
}
string wrongAttribute
{
}
class Foo
{
On 2013-09-16 22:15, Namespace wrote:
Then of course I have not said anything.
The same thing I would suggest for scope. It exists as a library
solution and is rewritten magical.
I think the big difference here is that AA's are safe where scope is
not. I agree with you, I like to use scope
On 2013-09-17 00:53, H. S. Teoh wrote:
Hmm. I find D arrays just fine the way they are, actually. (In fact, I
rather *liked* the way D arrays worked as compared with, say, C/C++.)
What's wrong with them?
I guess one can complain about some of the built-in
properties/functions, like sort.
On 09/17/13 00:53, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 10:59:10PM +0200, Artur Skawina wrote:
On 09/16/13 22:38, Namespace wrote:
[1] Obviously, not a practical short term option for the existing
D2 language. That's probably clear from the context, and the
question was meant to
On Sunday, 15 September 2013 at 18:31:40 UTC, simendsjo wrote:
On Sunday, 15 September 2013 at 17:34:06 UTC, matovitch wrote:
Hi everyone,
I read the documentation about user defined attributes, but I
don't see their uses. Ok, it'a a template expression you can
link to a declaration
On Monday, 16 September 2013 at 06:47:40 UTC, ilya-stromberg
wrote:
On Sunday, 15 September 2013 at 18:31:40 UTC, simendsjo wrote:
On Sunday, 15 September 2013 at 17:34:06 UTC, matovitch wrote:
Hi everyone,
I read the documentation about user defined attributes, but I
don't see their uses
All your examples are great, thank you ! Is there a way to omit
validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@nonNull C c) {
...
};
C c;
fun(c); //compilation error since C is null
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to omit
validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@nonNull C c) {
...
};
C c;
fun(c); //compilation error since
On Monday, 16 September 2013 at 10:36:16 UTC, Bienlein wrote:
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to
omit validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to omit
validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void fun(@nonNull C c) {
...
};
C c;
fun(c); //compilation error since
On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin wrote:
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to
omit validate such that the compiler would call it implicitly ?
For example :
class C {
...
}
void
On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg
wrote:
On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin wrote:
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank you ! Is there a way to
omit validate such that the compiler
On Monday, 16 September 2013 at 16:50:43 UTC, Namespace wrote:
On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg
wrote:
On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin
wrote:
On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
All your examples are great, thank
On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
Ideally structs should have default constructors (hello to
those who miss them - problem #2) which could initialize class
instance.
Do you know why D structs don't have default constructors? I
really miss.
On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
On Monday, 16 September 2013 at 16:50:43 UTC, Namespace wrote:
On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg
wrote:
On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin
wrote:
On Monday, 16 September 2013 at
On Monday, 16 September 2013 at 18:44:25 UTC, ilya-stromberg
wrote:
On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
Ideally structs should have default constructors (hello to
those who miss them - problem #2) which could initialize class
instance.
Do you know why D structs
C is null
As others have noted, the compiler cannot know what any of your
attributes mean.
But you can do this:
class C {
invariant() {
validate(this);
}
}
On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
[...]
I hate this NotNull struct hack. It is the same crap as the current
scope solution. BTW: I'm curious which built-in feature will be
removed next, maybe AA?
[...]
That wouldn't be a bad idea, actually. The current AA
Long time not heard from each other. ;)
On Monday, 16 September 2013 at 19:28:22 UTC, Andrei Alexandrescu
wrote:
On 9/16/13 11:56 AM, Namespace wrote:
I hate this NotNull struct hack. It is the same crap as the
current
scope solution.
Scoped variables in the language were a lot worse.
On 9/16/13 11:56 AM, Namespace wrote:
I hate this NotNull struct hack. It is the same crap as the current
scope solution.
Scoped variables in the language were a lot worse.
BTW: I'm curious which built-in feature will be removed
next, maybe AA?
If we're diligent and lucky, hopefully.
An
On Monday, 16 September 2013 at 19:28:22 UTC, Andrei Alexandrescu
wrote:
On 9/16/13 11:56 AM, Namespace wrote:
And I agree absolute, to disable default CTor's by struct's
was a huge
mistake. But D is full of those. ;)
They are not disabled. It seems many people are having trouble
with
On Mon, Sep 16, 2013 at 12:28:21PM -0700, Andrei Alexandrescu wrote:
On 9/16/13 11:56 AM, Namespace wrote:
I hate this NotNull struct hack. It is the same crap as the current
scope solution.
Scoped variables in the language were a lot worse.
One thing I'd *really* like to have is proper
On Monday, 16 September 2013 at 19:21:47 UTC, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
[...]
I hate this NotNull struct hack. It is the same crap as the
current
scope solution. BTW: I'm curious which built-in feature will be
removed next, maybe AA?
[...]
On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
Why should anyone switch to D if it is nothing else as a new
C++?
It's worth pointing out that the library AAs proposed here would
still have the same syntax as the built-in ones now.
int[string] a;
would just be magically
On Monday, 16 September 2013 at 20:15:26 UTC, Namespace wrote:
On Monday, 16 September 2013 at 20:09:53 UTC, Adam D. Ruppe
wrote:
On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
Why should anyone switch to D if it is nothing else as a new
C++?
It's worth pointing out that the
On Monday, 16 September 2013 at 20:09:53 UTC, Adam D. Ruppe wrote:
On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
Why should anyone switch to D if it is nothing else as a new
C++?
It's worth pointing out that the library AAs proposed here
would still have the same syntax as
On Monday, 16 September 2013 at 20:16:45 UTC, Namespace wrote:
And maybe also for delete: we need something to delete the
memory manually.
And we need built-in memory allocators, not only GC.
On 09/16/13 22:38, Namespace wrote:
[1] Obviously, not a practical short term option for the existing D2
language.
That's probably clear from the context, and the question was meant to be
rhetorical -- but it could actually be done and would make sense; it's
just
not a change
On Monday, 16 September 2013 at 21:11:00 UTC, Artur Skawina wrote:
On 09/16/13 22:52, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 10:38:58PM +0200, Namespace wrote:
D is not only about arrays.
It's a big plus. ;)
[1] Obviously, not a practical short term option for the
existing D2
language.
D is not only about arrays.
It's a big plus. ;)
[1] Obviously, not a practical short term option for the
existing D2 language.
That's probably clear from the context, and the question
was meant to be
rhetorical -- but it could actually be done and would make
sense; it's just
not
On 09/16/13 22:52, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 10:38:58PM +0200, Namespace wrote:
D is not only about arrays.
It's a big plus. ;)
[1] Obviously, not a practical short term option for the existing D2
language. That's probably clear from the context, and the question
was meant
On 09/16/13 21:58, Namespace wrote:
On Monday, 16 September 2013 at 19:21:47 UTC, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
[...]
I hate this NotNull struct hack. It is the same crap as the current
scope solution. BTW: I'm curious which built-in feature will
On Mon, Sep 16, 2013 at 10:38:58PM +0200, Namespace wrote:
D is not only about arrays.
It's a big plus. ;)
[1] Obviously, not a practical short term option for the existing D2
language. That's probably clear from the context, and the question
was meant to be rhetorical -- but it could
On Mon, Sep 16, 2013 at 10:59:10PM +0200, Artur Skawina wrote:
On 09/16/13 22:38, Namespace wrote:
[1] Obviously, not a practical short term option for the existing
D2 language. That's probably clear from the context, and the
question was meant to be rhetorical -- but it could
On Monday, 16 September 2013 at 19:21:47 UTC, H. S. Teoh wrote:
On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
[...]
I hate this NotNull struct hack. It is the same crap as the
current
scope solution. BTW: I'm curious which built-in feature will be
removed next, maybe AA?
[...]
Hi everyone,
I read the documentation about user defined attributes, but I
don't see their uses. Ok, it'a a template expression you can link
to a declaration, but what are they useful for ? (not sure about
the syntax ;-))
Can you declare a template constraint as a user defined attribute
On 2013-09-15 19:34, matovitch wrote:
Hi everyone,
I read the documentation about user defined attributes, but I don't see
their uses.
I'm using it in my serialization library:
struct Foo
{
int a;
@nonSerialized int b;
}
Indicates b will not be serialized.
struct Bar
{
int
On Sunday, 15 September 2013 at 17:34:06 UTC, matovitch wrote:
Hi everyone,
I read the documentation about user defined attributes, but I
don't see their uses. Ok, it'a a template expression you can
link to a declaration, but what are they useful for ? (not sure
about the syntax ;-))
Can
On 2013-08-02 03:02, JS wrote:
how can I get the UDA's of a type that I only know by name and only in a
CTFE.
I would like to loop over an array of names passed to a me(I don't know
their contents beforehand) and get the attributes.
I've tried to use a mixin but I can't get the mixin to work
how can I get the UDA's of a type that I only know by name and
only in a CTFE.
I would like to loop over an array of names passed to a me(I
don't know their contents beforehand) and get the attributes.
I've tried to use a mixin but I can't get the mixin to work on
the string name...
e.g
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 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
specifically, const, eg.
class A { void func() const { blah } }
std.traits.FunctionAttributes makes no mention of it
On Tuesday, June 04, 2013 19:03:47 Ellery Newcomer wrote:
specifically, const, eg.
class A { void func() const { blah } }
std.traits.FunctionAttributes makes no mention of it
is(typeof(A.func) == const)
- Jonathan M Davis
On 06/04/2013 07:19 PM, Jonathan M Davis wrote:
On Tuesday, June 04, 2013 19:03:47 Ellery Newcomer wrote:
specifically, const, eg.
class A { void func() const { blah } }
std.traits.FunctionAttributes makes no mention of it
is(typeof(A.func) == const)
- Jonathan M Davis
I think that is
On Tuesday, June 04, 2013 19:23:45 Ellery Newcomer wrote:
On 06/04/2013 07:19 PM, Jonathan M Davis wrote:
On Tuesday, June 04, 2013 19:03:47 Ellery Newcomer wrote:
specifically, const, eg.
class A { void func() const { blah } }
std.traits.FunctionAttributes makes no mention of it
On 06/04/2013 07:43 PM, Jonathan M Davis wrote:
On Tuesday, June 04, 2013 19:23:45 Ellery Newcomer wrote:
On 06/04/2013 07:19 PM, Jonathan M Davis wrote:
On Tuesday, June 04, 2013 19:03:47 Ellery Newcomer wrote:
specifically, const, eg.
class A { void func() const { blah } }
Ah, you're right. don't know how I screwed that up.
Yes I do. I was trying to use typeof(A.func)
On 06/04/2013 07:03 PM, Ellery Newcomer wrote:
specifically, const, eg.
class A { void func() const { blah } }
std.traits.FunctionAttributes makes no mention of it
Not that it adds more information over the spec, but I have finished the
translation of the is Expression chapter just
Hello.
I need a template for casting arrays to another type without
changing const and immutable attributes:
template ByteType(T) {
// some magic
}
const(int)[] ca;
immutable(short)[] is;
long[] ml;
static assert(is(ByteType!ca == const(byte)[]));
static assert(is(ByteType!is == immutable
On Wednesday, 22 May 2013 at 13:01:26 UTC, bearophile wrote:
I think that's essentially the right solution. I suggest to
generalize it a bit, removing the byte from its insides, and
making it a template argument. I think shared is missing.
Yes.
Finally http://dpaste.1azy.net/fc503331
Jack Applegame:
Finally http://dpaste.1azy.net/fc503331
I suggest to use indents composed by 4 spaces.
Generally in D we use template constraints, instead of static ifs
with a nice error message...
In such complex situations I also suggest to add braces.
Something like this:
auto
Quick question about attributes:
Is it intended that after the '@' can come any number of blanks?
Which means that '@property' is the same as '@ property'?
On 2013-04-02 15:40, Namespace wrote:
Quick question about attributes:
Is it intended that after the '@' can come any number of blanks?
Which means that '@property' is the same as '@ property'?
Hmm, I'm not sure. I mean, @property is not a single token, it's two.
In general you can
On Tuesday, 2 April 2013 at 14:17:19 UTC, Jacob Carlborg wrote:
On 2013-04-02 15:40, Namespace wrote:
Quick question about attributes:
Is it intended that after the '@' can come any number of
blanks?
Which means that '@property' is the same as '@
property'?
Hmm, I'm not sure. I mean
Before I open a new bug report, I would like to ask if anyone
knows why FunctionAttribute neither has const, immutable, shared
or inout?
Especially const and immutable were important to know.
are not function attributes but generic
type qualifiers. You can always do something like is(func ==
const).
You may check recently pulled update to fullyQualifiedName
(should be in next release) to see how it works for function
types. Not obvious part probably is delegate handling.
https://github.com/D
to know.
Well, technically, those are not function attributes but generic
type qualifiers.
In the spec they're listed as member function attributes.
, immutable,
shared or inout?
Especially const and immutable were important to know.
Well, technically, those are not function attributes but
generic
type qualifiers.
In the spec they're listed as member function attributes.
Which part? Probably it refers to delegates, because it has both
type
201 - 300 of 355 matches
Mail list logo
