On Wed, 14 Mar 2012 09:27:08 -0400, Martin Nowak wrote:
In essence, when @type is encountered the compiler looks at
TypeInfo_Struct (in object.di) for the equivalent xfuncname. Then uses
the attributes of that function pointer (and also the parameter
types/count) to compile the given meth
In essence, when @type is encountered the compiler looks at
TypeInfo_Struct (in object.di) for the equivalent xfuncname. Then uses
the attributes of that function pointer (and also the parameter
types/count) to compile the given method.
Why would you want to add explicit annotation for imp
On 14.03.2012 16:11, Steven Schveighoffer wrote:
On Mon, 12 Mar 2012 22:06:51 -0400, Walter Bright
wrote:
On 3/12/2012 6:40 PM, H. S. Teoh wrote:
And I'm not talking about doing just toHash, or just toString either.
Any of these functions have complex interdependencies with each other,
so it'
On Tue, 13 Mar 2012 19:23:25 -0400, Walter Bright
wrote:
On 3/13/2012 4:15 AM, Don Clugston wrote:
On 13/03/12 03:05, Walter Bright wrote:
On 3/12/2012 6:15 PM, Stewart Gordon wrote:
And what about toString?
Good question. What do you suggest?
Why can't we just kill that abomination?
On Mon, 12 Mar 2012 22:06:51 -0400, Walter Bright
wrote:
On 3/12/2012 6:40 PM, H. S. Teoh wrote:
And I'm not talking about doing just toHash, or just toString either.
Any of these functions have complex interdependencies with each other,
so it's either fix them ALL, or not at all.
Yup. It
On Tue, 13 Mar 2012 12:03:22 -0400, Alex Rønne Petersen
wrote:
Yes, and in some cases, it doesn't even work right; i.e. you can declare
certain opCmp and opEquals signatures that work fine for ==, >, <, etc
but don't get emitted to the TypeInfo metadata, and vice versa. It's a
mess.
Se
In general, for modules a and b, all of these should work:
dmd a b
dmd b a
dmd -c a
dmd -c b
For '-c' CTFE will already run semantic3 on the other module's functions.
But it would be very inefficient to do that for attributes.
On 14.03.2012 3:23, Walter Bright wrote:
On 3/13/2012 4:15 AM, Don Clugston wrote:
On 13/03/12 03:05, Walter Bright wrote:
On 3/12/2012 6:15 PM, Stewart Gordon wrote:
And what about toString?
Good question. What do you suggest?
Why can't we just kill that abomination?
Break a lot of exis
On 13 March 2012 04:15, H. S. Teoh wrote:
> On Mon, Mar 12, 2012 at 07:06:51PM -0700, Walter Bright wrote:
> > On 3/12/2012 6:40 PM, H. S. Teoh wrote:
> > >And I'm not talking about doing just toHash, or just toString either.
> > >Any of these functions have complex interdependencies with each
>
On 3/13/2012 4:50 AM, Martin Nowak wrote:
Yeah, you're right. It would easily create confusing behavior.
In general, for modules a and b, all of these should work:
dmd a b
dmd b a
dmd -c a
dmd -c b
On 3/13/12 5:39 PM, kennytm wrote:
Andrei Alexandrescu wrote:
Because in the general case functions call one another so there's no way
to figure which to look at first.
Andrei
That's no difference from template functions calling each others right?
int a()(int x) { return x==0?1:b(x-1);
Walter:
> Break a lot of existing code?
Invent a good deprecation strategy for toString?
The idea of modifying toString isn't new, we have discussed it more than on
time, and I agree with the general strategy Don appreciates. As far as I know
you didn't do much on it mostly because there were
On 03/13/2012 11:39 PM, kennytm wrote:
Andrei Alexandrescu wrote:
On 3/13/12 6:02 AM, Peter Alexander wrote:
On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
g
On 3/13/2012 4:15 AM, Don Clugston wrote:
On 13/03/12 03:05, Walter Bright wrote:
On 3/12/2012 6:15 PM, Stewart Gordon wrote:
And what about toString?
Good question. What do you suggest?
Why can't we just kill that abomination?
Break a lot of existing code?
Andrei Alexandrescu wrote:
> On 3/13/12 6:02 AM, Peter Alexander wrote:
>> On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
>>> On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
>>>
>>> A
On Tue, 13 Mar 2012 04:40:01 +0100, Andrei Alexandrescu
wrote:
I think the three others have a special regime because pointers to them
must be saved for the sake of associative arrays. toString is used only
generically,
Andrei
Adding a special case for AAs is not a good idea but
these
On Tue, Mar 13, 2012 at 11:06:00AM -0500, Andrei Alexandrescu wrote:
> On 3/13/12 10:47 AM, deadalnix wrote:
> >This problem is pretty close to garbage collection. Let's use pure as
> >example, but it work with other qualifier too.
> >
> >function are marked pure, impure, or pure given all function
Le 13/03/2012 17:06, Andrei Alexandrescu a écrit :
On 3/13/12 10:47 AM, deadalnix wrote:
This problem is pretty close to garbage collection. Let's use pure as
example, but it work with other qualifier too.
function are marked pure, impure, or pure given all function called are
pure (possibly pu
On 3/13/12 10:47 AM, deadalnix wrote:
This problem is pretty close to garbage collection. Let's use pure as
example, but it work with other qualifier too.
function are marked pure, impure, or pure given all function called are
pure (possibly pure). Then you go throw all possibly pure function an
On 13-03-2012 16:56, deadalnix wrote:
Le 13/03/2012 01:50, Walter Bright a écrit :
On 3/12/2012 4:11 AM, deadalnix wrote:
For struct, we have inference,
? No we don't.
Ok my mistake. So why not dig in that direction ?
so most of the time attributes will correct.
const pure nothrow @safe
Le 13/03/2012 01:50, Walter Bright a écrit :
On 3/12/2012 4:11 AM, deadalnix wrote:
For struct, we have inference,
? No we don't.
Ok my mistake. So why not dig in that direction ?
so most of the time attributes will correct.
const pure nothrow @safe are something we want, but is it someth
Le 13/03/2012 15:46, Andrei Alexandrescu a écrit :
On 3/13/12 6:02 AM, Peter Alexander wrote:
On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto
On 3/13/12 6:02 AM, Peter Alexander wrote:
On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto-inference is currently done for lambdas and templat
On Tue, 13 Mar 2012 01:40:08 +0100, Walter Bright
wrote:
On 3/12/2012 1:56 PM, Martin Nowak wrote:
It doesn't require all source code.
It just means that without source code nothing can be inferred and the
attributes fall back to what has been annotated by hand.
Hello endless bug reports o
On 13/03/12 03:05, Walter Bright wrote:
On 3/12/2012 6:15 PM, Stewart Gordon wrote:
And what about toString?
Good question. What do you suggest?
Why can't we just kill that abomination?
Le 13/03/2012 12:02, Peter Alexander a écrit :
On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto-inference is currently done for lambdas and tem
On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto-inference is currently done for lambdas and template
functions - why? - because the function'
On 2012-03-13 01:40, Walter Bright wrote:
On 3/12/2012 1:56 PM, Martin Nowak wrote:
It doesn't require all source code.
It just means that without source code nothing can be inferred and the
attributes fall back to what has been annotated by hand.
Hello endless bug reports of the form:
"It co
On Mon, Mar 12, 2012 at 10:58:18PM -0400, bearophile wrote:
> Walter:
>
> > Good question. What do you suggest?
>
> I suggest to follow a slow but reliable path, working bottom-up: turn
> to!string()/text()/format() into pure+nothrow functions, and then
> later require toString to be pure+nothrow
On 3/12/12 8:15 PM, Stewart Gordon wrote:
On 11/03/2012 23:54, Walter Bright wrote:
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyType
Walter:
> Good question. What do you suggest?
I suggest to follow a slow but reliable path, working bottom-up: turn
to!string()/text()/format() into pure+nothrow functions, and then later require
toString to be pure+nothrow and to have such annotations.
Bye,
bearophile
On 13-03-2012 03:15, H. S. Teoh wrote:
On Mon, Mar 12, 2012 at 07:06:51PM -0700, Walter Bright wrote:
On 3/12/2012 6:40 PM, H. S. Teoh wrote:
And I'm not talking about doing just toHash, or just toString either.
Any of these functions have complex interdependencies with each
other, so it's eith
On Mon, Mar 12, 2012 at 07:06:51PM -0700, Walter Bright wrote:
> On 3/12/2012 6:40 PM, H. S. Teoh wrote:
> >And I'm not talking about doing just toHash, or just toString either.
> >Any of these functions have complex interdependencies with each
> >other, so it's either fix them ALL, or not at all.
On 3/12/2012 6:15 PM, Stewart Gordon wrote:
And what about toString?
Good question. What do you suggest?
On 3/12/2012 6:40 PM, H. S. Teoh wrote:
And I'm not talking about doing just toHash, or just toString either.
Any of these functions have complex interdependencies with each other,
so it's either fix them ALL, or not at all.
Yup. It also seems very hard to figure out a transitional path to it.
On 13-03-2012 02:28, bearophile wrote:
Stewart Gordon:
And what about toString?
Often in toString I use format() or text(), or to!string(), that currently
aren't pure nor nothrow.
But in this thread I have seen no answers regarding deprecating the need of
opCmp() for hashability.
Bye,
bea
On Mon, Mar 12, 2012 at 09:27:41PM -0400, Jonathan M Davis wrote:
> On Tuesday, March 13, 2012 01:15:59 Stewart Gordon wrote:
> > On 11/03/2012 23:54, Walter Bright wrote:
> > > Consider the toHash() function for struct key types:
> > >
> > > http://dlang.org/hash-map.html
> > >
> > > And of cour
Stewart Gordon:
> And what about toString?
Often in toString I use format() or text(), or to!string(), that currently
aren't pure nor nothrow.
But in this thread I have seen no answers regarding deprecating the need of
opCmp() for hashability.
Bye,
bearophile
On Tuesday, March 13, 2012 01:15:59 Stewart Gordon wrote:
> On 11/03/2012 23:54, Walter Bright wrote:
> > Consider the toHash() function for struct key types:
> >
> > http://dlang.org/hash-map.html
> >
> > And of course the others:
> >
> > const hash_t toHash();
> > const bool opEquals(ref const
On 11/03/2012 23:54, Walter Bright wrote:
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyType s);
And what about toString?
Stewart.
On 3/12/2012 11:10 AM, Jonathan M Davis wrote:
I believe that Walter likes to say that it takes away your excuse _not_ to
write them because of how easy it is to write unit tests in D.
It can be remarkable how much more use something gets if you just make it a bit
more convenient.
On 3/12/2012 4:11 AM, deadalnix wrote:
For struct, we have inference,
? No we don't.
so most of the time attributes will correct.
const pure nothrow @safe are something we want, but is it something we want to
enforce ?
Yes, because they are referred to by TypeInfo, and that's fairly useless
On 3/12/2012 1:56 PM, Martin Nowak wrote:
It doesn't require all source code.
It just means that without source code nothing can be inferred and the
attributes fall back to what has been annotated by hand.
Hello endless bug reports of the form:
"It compiles when I send the arguments to dmd thi
On 03/12/2012 09:46 PM, Jonathan M Davis wrote:
On Monday, March 12, 2012 21:36:21 Martin Nowak wrote:
That could be solved with a @ctfe attribute or something, no? Like, if
the function has @ctfe, go through all possible CTFE paths (excluding
!__ctfe paths of course) and make sure they are CTFE
Because that requires having all of the source code. The fact that we
have .di
files prevents that.
It doesn't require all source code.
It just means that without source code nothing can be inferred and the
attributes fall back to what has been annotated by hand.
It could be used to annotated f
On Monday, March 12, 2012 11:25:41 H. S. Teoh wrote:
> On Mon, Mar 12, 2012 at 02:10:23PM -0400, Jonathan M Davis wrote:
> > On Monday, March 12, 2012 11:04:54 H. S. Teoh wrote:
> > > Tangential note: writing unit tests may be tedious, but D's inline
> > > unittest syntax has alleviated a large par
On Monday, March 12, 2012 21:36:21 Martin Nowak wrote:
> > That could be solved with a @ctfe attribute or something, no? Like, if
> > the function has @ctfe, go through all possible CTFE paths (excluding
> > !__ctfe paths of course) and make sure they are CTFEable.
>
> Everything that's pure shoul
That could be solved with a @ctfe attribute or something, no? Like, if
the function has @ctfe, go through all possible CTFE paths (excluding
!__ctfe paths of course) and make sure they are CTFEable.
Everything that's pure should be CTFEable which doesn't imply that you
can turn every CTFEabl
On 2012-03-12 19:41, Alex Rønne Petersen wrote:
I stopped writing inline unit tests in larger code bases. If I do that,
I have to maintain a separate build configuration just for test
execution, which is not practical. Furthermore, I want to test my code
in debug and release mode, which... goes a
On 12-03-2012 20:08, H. S. Teoh wrote:
On Mon, Mar 12, 2012 at 07:41:39PM +0100, Alex Rønne Petersen wrote:
On 12-03-2012 19:04, H. S. Teoh wrote:
[...]
Tangential note: writing unit tests may be tedious, but D's inline
unittest syntax has alleviated a large part of that tedium. So much
so tha
On 3/12/2012 11:04 AM, H. S. Teoh wrote:
Tangential note: writing unit tests may be tedious, but D's inline
unittest syntax has alleviated a large part of that tedium. So much so
that I find myself writing as much code in unittests as real code.
Which is a good thing, because in the past I'd alwa
On Mon, Mar 12, 2012 at 07:41:39PM +0100, Alex Rønne Petersen wrote:
> On 12-03-2012 19:04, H. S. Teoh wrote:
[...]
> >Tangential note: writing unit tests may be tedious, but D's inline
> >unittest syntax has alleviated a large part of that tedium. So much
> >so that I find myself writing as much c
On 12-03-2012 18:55, Jonathan M Davis wrote:
On Monday, March 12, 2012 18:44:06 Alex Rønne Petersen wrote:
Now, that _does_ introduce the possibility of a template being to be pure
and then not being able to be pure thanks to a change that's made to it
or something that it uses, and that makes i
On 12-03-2012 19:04, H. S. Teoh wrote:
On Mon, Mar 12, 2012 at 01:55:33PM -0400, Jonathan M Davis wrote:
[...]
So, no, I don't think that @ctfe would really work. And while I agree
that the situation isn't exactly ideal, I don't really see a way
around it. Unit tests _do_ catch it for you though
On Mon, Mar 12, 2012 at 02:10:23PM -0400, Jonathan M Davis wrote:
> On Monday, March 12, 2012 11:04:54 H. S. Teoh wrote:
> > Tangential note: writing unit tests may be tedious, but D's inline
> > unittest syntax has alleviated a large part of that tedium. So much so
> > that I find myself writing a
On Monday, March 12, 2012 11:04:54 H. S. Teoh wrote:
> Tangential note: writing unit tests may be tedious, but D's inline
> unittest syntax has alleviated a large part of that tedium. So much so
> that I find myself writing as much code in unittests as real code.
> Which is a good thing, because in
On Mon, Mar 12, 2012 at 01:55:33PM -0400, Jonathan M Davis wrote:
[...]
> So, no, I don't think that @ctfe would really work. And while I agree
> that the situation isn't exactly ideal, I don't really see a way
> around it. Unit tests _do_ catch it for you though. The only thing
> that they can't c
On Monday, March 12, 2012 18:44:06 Alex Rønne Petersen wrote:
> > Now, that _does_ introduce the possibility of a template being to be pure
> > and then not being able to be pure thanks to a change that's made to it
> > or something that it uses, and that makes impossible for any code using
> > it
On 12-03-2012 18:38, Jonathan M Davis wrote:
On Monday, March 12, 2012 14:23:28 Alex Rønne Petersen wrote:
On 12-03-2012 14:16, deadalnix wrote:
Le 12/03/2012 13:51, Alex Rønne Petersen a écrit :
On 12-03-2012 10:40, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong
On Monday, March 12, 2012 14:23:28 Alex Rønne Petersen wrote:
> On 12-03-2012 14:16, deadalnix wrote:
> > Le 12/03/2012 13:51, Alex Rønne Petersen a écrit :
> >> On 12-03-2012 10:40, Walter Bright wrote:
> >>> On 3/12/2012 1:08 AM, Martin Nowak wrote:
> What's wrong with auto-inference. Inferr
On Monday, March 12, 2012 09:14:17 Martin Nowak wrote:
> > So I propose instead a bit of a hack. toHash, opEquals, and opCmp as
> > struct members be automatically annotated with pure, nothrow, and @safe
> > (if not already marked as @trusted).
>
> How about complete inference instead of a hack?
Walter:
toHash, opEquals, and opCmp as struct members be automatically
annotated with pure, nothrow, and @safe (if not already marked
as @trusted).
I have read the other answers of this thread, and I don't like
some of them.
In this case I think this programmer convenience doesn't justify
On Mon, 12 Mar 2012 10:40:16 +0100, Walter Bright
wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto-inference is currently done for lambdas and template functions -
why? - because the function'
On 12-03-2012 14:16, deadalnix wrote:
Le 12/03/2012 13:51, Alex Rønne Petersen a écrit :
On 12-03-2012 10:40, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto-inference is currently do
On Sun, 11 Mar 2012 19:54:09 -0400, Walter Bright
wrote:
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyType s);
They need to be, as
Le 12/03/2012 13:51, Alex Rønne Petersen a écrit :
On 12-03-2012 10:40, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto-inference is currently done for lambdas and template functions -
On 12-03-2012 10:40, Walter Bright wrote:
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.
Auto-inference is currently done for lambdas and template functions -
why? - because the function's implementation is gua
On 12/03/12 00:55, Alex Rønne Petersen wrote:
On 12-03-2012 00:54, Walter Bright wrote:
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyT
Le 12/03/2012 00:54, Walter Bright a écrit :
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyType s);
They need to be, as well as const,
> That sounds intentionally.
>
> Say you have a struct with a getHash method.
>
> struct Key
> {
> hash_t getHash() /* inferred pure */
> {
> }
> }
>
> Say you have an Set that requires a pure opHash.
>
> void insert(Key key) pure
> {
> immutable hash = key.toHash();
> }
>
> Now if you
One problem I can think of is relying on the auto-inference can create
fragile code. You make a change in one place without concentrating and
suddenly a completely different part of your code breaks, because it's
expecting pure, or @safe code and you have done something to prevent
the inference. I
On 3/12/2012 1:08 AM, Martin Nowak wrote:
What's wrong with auto-inference. Inferred attributes are only strengthening
guarantees.
Auto-inference is currently done for lambdas and template functions - why? -
because the function's implementation is guaranteed to be visible to the
compiler. Fo
Am Mon, 12 Mar 2012 07:06:33 +0100
schrieb Alex Rønne Petersen :
> I should point out that I *do* think the idea is good (i.e. if you want
> the "bad" things, that's what you have to declare), but it's just too
> late now. Also, there might be issues with const and the likes - should
> the syst
So I propose instead a bit of a hack. toHash, opEquals, and opCmp as
struct members be automatically annotated with pure, nothrow, and @safe
(if not already marked as @trusted).
How about complete inference instead of a hack?
On 12 March 2012 21:08, Martin Nowak wrote:
> On Mon, 12 Mar 2012 07:04:52 +0100, Alex Rønne Petersen
> wrote:
>
>> Or, as a compromise, perhaps the compiler can auto-infer most of the
>> attributes without any further effort from the user.
>> No, that has API design issues. You can silently bre
On Mon, 12 Mar 2012 07:04:52 +0100, Alex Rønne Petersen
wrote:
Or, as a compromise, perhaps the compiler can auto-infer most of the
attributes without any further effort from the user.
No, that has API design issues. You can silently break a guarantee you
made previously.
What's wrong wi
On Monday, 12 March 2012 at 07:18:06 UTC, so wrote:
A pattern is emerging. Why not analyze it a bit and somehow try
to find a common ground? Then we can generalize it to a single
annotation.
@mask(wat) const|pure|nothrow|safe
@wat hash_t toHash()
@wat bool opEquals(ref const KeyType s)
@wat
On Sunday, 11 March 2012 at 23:54:10 UTC, Walter Bright wrote:
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyType s);
They need to be,
On 12-03-2012 07:04, Alex Rønne Petersen wrote:
On 12-03-2012 06:43, H. S. Teoh wrote:
On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote:
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const boo
On 12-03-2012 06:43, H. S. Teoh wrote:
On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote:
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(
On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote:
> Consider the toHash() function for struct key types:
>
> http://dlang.org/hash-map.html
>
> And of course the others:
>
> const hash_t toHash();
> const bool opEquals(ref const KeyType s);
> const int opCmp(ref const KeyType s);
>
Kapps:
> Agreed. Those are already special, so I don't think it hurts to
> make this change. But I may be missing some implications.
At risk of sounding like a troll, I hope from now on Walter will not use this
kind of strategy to solve all the MANY breaking changes D/DMD will need to face
:-)
On Sunday, 11 March 2012 at 23:55:34 UTC, Alex Rønne Petersen
wrote:
It may be a hack, but you know, those have special
semantics/meanings in the first place, so is it really that
bad? Consider also that contract blocks are now implicitly
const, etc.
Agreed. Those are already special, so I do
Walter:
> So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct
> members be automatically annotated with pure, nothrow, and @safe (if not
> already
> marked as @trusted).
Recently I have suggested to deprecate and later remove the need of opCmp for
the built-in AAs.
Re
On 12-03-2012 00:54, Walter Bright wrote:
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyType s);
They need to be, as well as const, pur
Consider the toHash() function for struct key types:
http://dlang.org/hash-map.html
And of course the others:
const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyType s);
They need to be, as well as const, pure nothrow @safe.
The problem is:
1. a lot
86 matches
Mail list logo
