Re: toHash => pure, nothrow, const, @safe
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 method. Why would you want to add explicit annotation for implicit TypeInfo_Struct methods? Because right now, it's a guessing game of whether you wanted an operation to be part of the typeinfo's interface. And many times, the compiler guesses wrong. I've seen countless posts on d.learn saying "why won't AA's call my opEquals or opHash function?" With explicit annotation, you have instructed the compiler "I expect this to be in TypeInfo," so it can take the appropriate actions if it doesn't match. I think @type is a very interesting idea if combined with a string->method lookup in TypeInfo_Struct, but this wouldn't allow for static type checking. Yes it would. It has access to TypeInfo_Struct in object.di, so it can figure out what the signature should be. -Steve
Re: toHash => pure, nothrow, const, @safe
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 implicit TypeInfo_Struct methods? I think @type is a very interesting idea if combined with a string->method lookup in TypeInfo_Struct, but this wouldn't allow for static type checking. If you wanted static type checking then @type could probably refer to Interfaces.
Re: toHash => pure, nothrow, const, @safe
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's either fix them ALL, or not at all. Yup. It also seems very hard to figure out a transitional path to it. It seems most people have ignored my post in this thread, so I'll say it again: What about an annotation (I suggested @type, it could be anything, but I'll use that as my strawman) that says to the compiler "this is part of the TypeInfo_Struct interface." 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. It does two things: 1. It provides an indicator a user can use when he *wants* to include that function as part of the typeinfo. Right now, you have to guess, and pray to the compiler gods that your function signature is deemed worthy. 2. It takes all sorts of burden off the compiler to know which functions are "special", and to make assumptions about them. We can implement it now *without* making those function pointers pure/safe/nothrow/whatever, and people can then experiment with changing it without having to muck with the compiler. As a bonus, it also allows people to experiment with adding more interface methods to structs without having to muck with the compiler. The only drawback is what to do with existing code that *doesn't* have @type on it's functions that go into TypeInfo_Struct. There are ways to handle this. My suggestion is to simply treat the current methods as special and assume @type is on those methods. But I would suggest removing that "hack" in the future, with some way to easily tell you where you need to put @type annotations. For one, I'm sold on it. And the proposed magic hack can work right now, then it'll just get deprecated in favor of explicit @type. -- Dmitry Olshansky
Re: toHash => pure, nothrow, const, @safe
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? Break a lot of existing code? I'm unaware of much code that uses TypeInfo.xtostring to print anything. write[f][ln] doesn't, and I don't think std.conv.to does either. In other words, killing the "specialness" of toString doesn't mean killing toString methods in all structs. What this does is allow us to not worry about what you annotate your toString methods with, it just becomes a regular method. -Steve
Re: toHash => pure, nothrow, const, @safe
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 also seems very hard to figure out a transitional path to it. It seems most people have ignored my post in this thread, so I'll say it again: What about an annotation (I suggested @type, it could be anything, but I'll use that as my strawman) that says to the compiler "this is part of the TypeInfo_Struct interface." 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. It does two things: 1. It provides an indicator a user can use when he *wants* to include that function as part of the typeinfo. Right now, you have to guess, and pray to the compiler gods that your function signature is deemed worthy. 2. It takes all sorts of burden off the compiler to know which functions are "special", and to make assumptions about them. We can implement it now *without* making those function pointers pure/safe/nothrow/whatever, and people can then experiment with changing it without having to muck with the compiler. As a bonus, it also allows people to experiment with adding more interface methods to structs without having to muck with the compiler. The only drawback is what to do with existing code that *doesn't* have @type on it's functions that go into TypeInfo_Struct. There are ways to handle this. My suggestion is to simply treat the current methods as special and assume @type is on those methods. But I would suggest removing that "hack" in the future, with some way to easily tell you where you need to put @type annotations. -Steve
Re: toHash => pure, nothrow, const, @safe
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. See my post in this thread. It fixes this problem. -Steve
Re: toHash => pure, nothrow, const, @safe
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.
Re: toHash => pure, nothrow, const, @safe
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 existing code? And gain efficiency. BTW transition paths were suggested, need to just dig up DIP9 discussions. -- Dmitry Olshansky
Re: toHash => pure, nothrow, const, @safe
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 > > >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. > > Perhaps we just need to bite the bullet and do it all in one shot and > check it into master, then deal with the aftermath later. :-) Otherwise > it will simply never get off the ground. > MMMmmm, now we're talking! I've always preferred this approach :P
Re: toHash => pure, nothrow, const, @safe
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
Re: toHash => pure, nothrow, const, @safe
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); }
int b()(int x) { return x==0?1:a(x-1); }
There is. Templates are guaranteed to have the body available. Walter
uses a recursive on-demand approach instead of a worklist approach for
inferring attributes (worklists have an issue I forgot about).
Andrei
Re: toHash => pure, nothrow, const, @safe
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 other more important things to do, like fixing important bugs, not because people thought the situation was good enough. Maybe now it's a good moment to slow down bug fixing and look for things more important than bugs (where "important" means "can't be done much later"). Bye, bearophile
Re: toHash => pure, nothrow, const, @safe
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
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. For other functions, not so, and so the
attributes must be part of the function signature.
Dumb question:
Why not auto-infer when the function body is available, and put the
inferred attributes into the automatically generated .di file?
Apologies if I've missed something completely obvious.
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); }
int b()(int x) { return x==0?1:a(x-1); }
http://d.puremagic.com/issues/show_bug.cgi?id=7205
The non-trivial issue is what to do with compile-time reflection in the
function body. I think during reflection, the function should appear
non-annotated to itself and all functions with inferred attributes it
calls transitively through other functions with inferred attributes
regardless of whether or not they are later inferred. (currently
inference fails spectacularly for anything inside a typeof expression
anyway, therefore it is not yet that much of an issue.)
pragma(msg, typeof({writeln("hello world");})); // "void function() pure
@safe"
Re: toHash => pure, nothrow, const, @safe
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?
Re: toHash => pure, nothrow, const, @safe
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.
>>>
>>> Auto-inference is currently done for lambdas and template functions -
>>> why? - because the function's implementation is guaranteed to be
>>> visible to the compiler. For other functions, not so, and so the
>>> attributes must be part of the function signature.
>>
>> Dumb question:
>>
>> Why not auto-infer when the function body is available, and put the
>> inferred attributes into the automatically generated .di file?
>>
>> Apologies if I've missed something completely obvious.
>
> 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); }
int b()(int x) { return x==0?1:a(x-1); }
Re: toHash => pure, nothrow, const, @safe
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 operators are indeed special and should have a defined behavior. Requiring pureness for comparison for example is good for all kind of generic algorithms.
Re: toHash => pure, nothrow, const, @safe
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 called > >are pure (possibly pure). Then you go throw all possibly pure > >function and if it call an impure function, they mark it impure. When > >you don't mark any function as impure on a loop, you can mark all > >remaining possibly pure functions as pure. > > Certain analyses can be done using the so-called worklist approach. > The analysis can be pessimistic (initially marking all functions as > not carrying the property analyzed and gradually proving some do carry > it) or optimistic (the other way around). The algorithm ends when the > worklist is empty. This approach is well-studied and probably ought > more coverage in compiler books. I learned about it in a graduate > compiler class. [...] I have an idea. Instead of making potentially risky changes to the compiler, or changes with unknown long-term consequences, what about an external tool (or a new compiler option) that performs this analysis and saves it into a file, say in json format or something? So we run the analysis on druntime, and it tells us exactly which functions can be marked pure, const, whatever, then we can (1) look through the list to see if functions that *should* be pure aren't, then investigate why and (possibly) fix the problem; (2) annotate all functions in druntime just by going through the list, without needing to manually fix one function, find out it breaks 5 other functions, fix those functions, find another 25 broken, etc.. We can also run this on phobos, cleanup whatever functions aren't marked pure, and then go through the list and annotate everything in one shot. Now that I think of it, it seems quite silly that we should be agonizing over the amount of manual work needed to annotate druntime and phobos, when the compiler already has all the necessary information to automate most of the tedious work. T -- It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford
Re: toHash => pure, nothrow, const, @safe
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 pure). Then you go throw all possibly pure function and if it call an impure function, they mark it impure. When you don't mark any function as impure on a loop, you can mark all remaining possibly pure functions as pure. Certain analyses can be done using the so-called worklist approach. The analysis can be pessimistic (initially marking all functions as not carrying the property analyzed and gradually proving some do carry it) or optimistic (the other way around). The algorithm ends when the worklist is empty. This approach is well-studied and probably ought more coverage in compiler books. I learned about it in a graduate compiler class. However, the discussion was about availability of the body. A worklist-based approach would need all functions that call one another regardless of module. That makes the analysis interprocedural, i.e. difficult on large codebases. Andrei I expect the function we are talking about here not to call almost all the codebase. It would be scary.
Re: toHash => pure, nothrow, const, @safe
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 and if it call an impure function, they mark it impure. When you don't mark any function as impure on a loop, you can mark all remaining possibly pure functions as pure. Certain analyses can be done using the so-called worklist approach. The analysis can be pessimistic (initially marking all functions as not carrying the property analyzed and gradually proving some do carry it) or optimistic (the other way around). The algorithm ends when the worklist is empty. This approach is well-studied and probably ought more coverage in compiler books. I learned about it in a graduate compiler class. However, the discussion was about availability of the body. A worklist-based approach would need all functions that call one another regardless of module. That makes the analysis interprocedural, i.e. difficult on large codebases. Andrei
Re: toHash => pure, nothrow, const, @safe
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 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 if it isn't const etc. I always though that TypeInfo is a poor substitute for metaprograming and compile time reflexion. 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. -- - Alex
Re: toHash => pure, nothrow, const, @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 something we want to enforce ? Yes, because they are referred to by TypeInfo, and that's fairly useless if it isn't const etc. I always though that TypeInfo is a poor substitute for metaprograming and compile time reflexion.
Re: toHash => pure, nothrow, const, @safe
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-inference is currently done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Dumb question: Why not auto-infer when the function body is available, and put the inferred attributes into the automatically generated .di file? Apologies if I've missed something completely obvious. Because in the general case functions call one another so there's no way to figure which to look at first. Andrei 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 and if it call an impure function, they mark it impure. When you don't mark any function as impure on a loop, you can mark all remaining possibly pure functions as pure.
Re: toHash => pure, nothrow, const, @safe
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 template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Dumb question: Why not auto-infer when the function body is available, and put the inferred attributes into the automatically generated .di file? Apologies if I've missed something completely obvious. Because in the general case functions call one another so there's no way to figure which to look at first. Andrei
Re: toHash => pure, nothrow, const, @safe
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 of the form: "It compiles when I send the arguments to dmd this way but not that way. dmd is broken. D sux." Yeah, you're right. It would easily create confusing behavior.
Re: toHash => pure, nothrow, const, @safe
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?
Re: toHash => pure, nothrow, const, @safe
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 template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Dumb question: Why not auto-infer when the function body is available, and put the inferred attributes into the automatically generated .di file? Apologies if I've missed something completely obvious. That is exactly what I was thinking about.
Re: toHash => pure, nothrow, const, @safe
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's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Dumb question: Why not auto-infer when the function body is available, and put the inferred attributes into the automatically generated .di file? Apologies if I've missed something completely obvious.
Re: toHash => pure, nothrow, const, @safe
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 compiles when I send the arguments to dmd this way but not that way. dmd is broken. D sux." We already have that, sometimes :( -- /Jacob Carlborg
Re: toHash => pure, nothrow, const, @safe
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 and to have such > annotations. [...] The problem is that there may not *be* a bottom to start from. These functions are all interlinked to each other in various places (spread across a myriad of different overrides of them). I've tried to find one function that I can annotate without needing hundreds of other changes, but alas, they all depend on each other at some level, and every time I end up annotating almost every other function in druntime and the change just gets bigger and bigger. T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Re: toHash => pure, nothrow, const, @safe
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 s); And what about toString? 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
Re: toHash => pure, nothrow, const, @safe
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
Re: toHash => pure, nothrow, const, @safe
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 either fix them ALL, or not at all. Yup. It also seems very hard to figure out a transitional path to it. Perhaps we just need to bite the bullet and do it all in one shot and check it into master, then deal with the aftermath later. :-) Otherwise it will simply never get off the ground. T I have to say this seems like the most sensible approach right now. -- - Alex
Re: toHash => pure, nothrow, const, @safe
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. > > Yup. It also seems very hard to figure out a transitional path to it. Perhaps we just need to bite the bullet and do it all in one shot and check it into master, then deal with the aftermath later. :-) Otherwise it will simply never get off the ground. T -- Two wrongs don't make a right; but three rights do make a left...
Re: toHash => pure, nothrow, const, @safe
On 3/12/2012 6:15 PM, Stewart Gordon wrote: And what about toString? Good question. What do you suggest?
Re: toHash => pure, nothrow, const, @safe
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.
Re: toHash => pure, nothrow, const, @safe
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, bearophile I fully support that. -- - Alex
Re: toHash => pure, nothrow, const, @safe
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 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? > > That really should be too, but work is probably going to have to be done to > make sure that format and std.conv.to can be pure, since they're pretty much > required in most toString functions. This is not going to be a choice, because some overrides of toHash calls toString. > I believe that changes to toUTF8, toUTF16, and toUTF32 were made > recently which are at least a major step in that direction for > std.conv.to (since it uses them) and may outright make it so that it > can be pure now (I'm not sure if anything else is preventing them from > being pure). But I have no idea what the current state of format is > with regards to purity, and if the changes to toUTFx weren't enough to > make std.conv.to pure for strings, then more will need to be done > there as well. [...] Looks like we need a massive one-shot overhaul of almost all of druntime and a potentially large part of phobos in order to get this pure/@safe/nothrow thing off the ground. There are just too many interdependencies everywhere that there's practically no way to do it incrementally. I tried the incremental approach several times and have given up, 'cos every small change inevitably propagates to functions all over druntime and then some. 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. T -- Obviously, some things aren't very obvious.
Re: toHash => pure, nothrow, const, @safe
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
Re: toHash => pure, nothrow, const, @safe
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 KeyType s); > > const int opCmp(ref const KeyType s); > > > > And what about toString? That really should be too, but work is probably going to have to be done to make sure that format and std.conv.to can be pure, since they're pretty much required in most toString functions. I believe that changes to toUTF8, toUTF16, and toUTF32 were made recently which are at least a major step in that direction for std.conv.to (since it uses them) and may outright make it so that it can be pure now (I'm not sure if anything else is preventing them from being pure). But I have no idea what the current state of format is with regards to purity, and if the changes to toUTFx weren't enough to make std.conv.to pure for strings, then more will need to be done there as well. - Jonathan M Davis
Re: toHash => pure, nothrow, const, @safe
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.
Re: toHash => pure, nothrow, const, @safe
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.
Re: toHash => pure, nothrow, const, @safe
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 if it isn't const etc.
Re: toHash => pure, nothrow, const, @safe
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 this way but not that way. dmd is broken. D sux."
Re: toHash => pure, nothrow, const, @safe
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 CTFEable. Everything that's pure should be CTFEable which doesn't imply that you can turn every CTFEable function into a pure one. I don't think that that's quite true. pure doesn't imply @safe, so you could do pointer arithmetic and stuff and the like - which I'm pretty sure CTFE won't allow. And, of course, if you mark a C function as pure or subvert pure through casts, then pure _definitely_ doesn't imply CTFEability. - Jonathan M Davis CTFE allows quite some pointer arithmetic, but makes sure it is actually safe.
Re: toHash => pure, nothrow, const, @safe
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 functions at the API level and have the compiler check that transitively. It should behave like implicit conversion to "pure nothrow ..." if the compiler hasn't found them inapplicable. On the downside it has some implications for the compilation model because functions would need to be analyzed transitively. But then again we already do this for CTFE.
Re: toHash => pure, nothrow, const, @safe
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 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 always been too lazy to > > > write any unittests at all. > > > > D doesn't make writing unit tests easy, since there's an intrinsic > > amount of effort required to write them, just like there is with any > > code, but it takes away all of the extraneous effort in having to set > > up a unit test framework and the like. And by removing pretty much > > anything from the effort which is not actually required, it makes > > writing unit testing about as easy as it can be. > > I would argue that D *does* make unit tests easier to write, in that you > can write them in straight D code inline (as opposed to some testing > frameworks that require external stuff like Expect, Python, intermixed > with native code), so you don't need to put what you're writing on hold > while you go off and write unittests. You can just insert a unittest > block after the function/class/etc immediately while the code is still > fresh in your mind. I often find myself writing unittests simultaneously > with real code, since while writing the code I see a possible boundary > condition to test for, and immediately put that in a unittest to ensure > I don't forget about it later. This improves the quality of both the > code and the unittests. I didn't say that D doesn't make writing unit tests easier. I just said that it doesn't make them _easy_. They're as much work as writing any code is. But by making them easier, D makes them about as easy to write as they can be. Regardless, built-in unit testing is a fantastic feature. - Jonathan m Davis
Re: toHash => pure, nothrow, const, @safe
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 should be CTFEable which doesn't imply that you > can turn every CTFEable function into a pure one. I don't think that that's quite true. pure doesn't imply @safe, so you could do pointer arithmetic and stuff and the like - which I'm pretty sure CTFE won't allow. And, of course, if you mark a C function as pure or subvert pure through casts, then pure _definitely_ doesn't imply CTFEability. - Jonathan M Davis
Re: toHash => pure, nothrow, const, @safe
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 CTFEable function into a pure one.
Re: toHash => pure, nothrow, const, @safe
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 against having a test configuration. I don't inline my unit test either. So, I've ended up moving all unit tests to a separate executable that links in all my libraries and runs their tests in debug/release mode. Works much better. I don't feel that unittest in D was really thought through properly for large projects targeting actual end users... I agree. I've also started to do more high level testing of some of my command line tools using Cucumber and Aruba. But these test are written in Ruby because of Cucumber and Aruba. http://cukes.info/ https://github.com/cucumber/aruba -- /Jacob Carlborg
Re: toHash => pure, nothrow, const, @safe
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 that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. [...] 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 against having a test configuration. [...] Hmm. Sounds like what you want is not really unittests, but global program startup self-checks. In my mind, unittests is for running specific checks against specific functions, classes/structs inside a That's what I do. I simply moved my unittest blocks to a separate executable. module. I frequently write lots of unittests that instantiates all sorts of templates never used by the real program, contrived data objects, etc., that may potentially have long running times, or creates files in the working directory or other stuff like that. IOW, stuff that are not You never know if some code that seems to work fine in debug mode breaks in release mode then (until your user runs into a bug). This is why I want full coverage in all configurations. suitable to be used for release builds at all. It's really more of a way of forcing the program to refuse to start during development when a code change breaks the system, so that the developer notices the breakage immediately. Definitely not for the end-user. Right. That's why my tests are in a separate executable from the actual program. If I wanted release-build self-consistency checking, then yeah, I'd use a different framework than unittests. IMHO unittest works fine for both debug and release, just not inline. As for build configuration, I've given up on make a decade ago for something saner, which can handle complicated build options properly. But that belongs to another topic. I used to use Make for this project, then switched to Waf. It's an amazing build tool. T -- - Alex
Re: toHash => pure, nothrow, const, @safe
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 always been too lazy to write any unittests at all. That's exactly how it was intended! It seems like such a small feature, really just a syntactic convenience, but what a difference it makes.
Re: toHash => pure, nothrow, const, @safe
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 code in unittests as real code. > >Which is a good thing, because in the past I'd always been too lazy > >to write any unittests at all. [...] > 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 against having a test > configuration. [...] Hmm. Sounds like what you want is not really unittests, but global program startup self-checks. In my mind, unittests is for running specific checks against specific functions, classes/structs inside a module. I frequently write lots of unittests that instantiates all sorts of templates never used by the real program, contrived data objects, etc., that may potentially have long running times, or creates files in the working directory or other stuff like that. IOW, stuff that are not suitable to be used for release builds at all. It's really more of a way of forcing the program to refuse to start during development when a code change breaks the system, so that the developer notices the breakage immediately. Definitely not for the end-user. If I wanted release-build self-consistency checking, then yeah, I'd use a different framework than unittests. As for build configuration, I've given up on make a decade ago for something saner, which can handle complicated build options properly. But that belongs to another topic. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: toHash => pure, nothrow, const, @safe
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 impossible for any code using it to be pure. CTFE has the same problem. It's fairly easy to have a function which is CTFEable cease to be CTFEable thanks to a change to it, and no one notices. We've had issues with this in the past. 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. 1. That goes completely against how CTFE was designed in that part of the idea was that you _wouldn't_ have to annotate it. Though, rarely, functions written with runtime execution in mind actually Just Work in CTFE. You usually have to change code or special-case things for it to work. In my experience, anyway... 2. I don't really know how feasible that would be. At minimum, the fact that CTFE works with classes now would probably render it completely infeasible for classes, since they're polymorphic, and the compiler can't possibly know all of the possible types that could be passed to the function. Templates would screw it over too for the exact same reasons that they can have issues with pure, @safe, and nothrow. It may or may not be feasible without classes or templates being involved. I hadn't thought of classes at all. In practice, it's impossible then. 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 catch is whether the template is going to be pure, nothrow, @safe, and/or CTFEable with _your_ arguments to it, but as long as it's pure, nothrow, @safe, and/or CTFEable with _a_ set of arguments, it will generally be the fault of the arguments when such a function fails to be pure, nothrow, @safe, and/or CTFEable as expected. If the unit tests don't hit all of the possible static if-else blocks and all of the possible code paths for CTFE, it could still be a problem, but that just means that the unit tests aren't thorough enough, and more thorough unit tests will fix the problem, as tedious as it may be to do that. - Jonathan M Davis -- - Alex
Re: toHash => pure, nothrow, const, @safe
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. The only thing that they can't catch is whether the template is going to be pure, nothrow, @safe, and/or CTFEable with _your_ arguments to it, but as long as it's pure, nothrow, @safe, and/or CTFEable with _a_ set of arguments, it will generally be the fault of the arguments when such a function fails to be pure, nothrow, @safe, and/or CTFEable as expected. If the unit tests don't hit all of the possible static if-else blocks and all of the possible code paths for CTFE, it could still be a problem, but that just means that the unit tests aren't thorough enough, and more thorough unit tests will fix the problem, as tedious as it may be to do that. [...] 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 always been too lazy to write any unittests at all. T 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 against having a test configuration. So, I've ended up moving all unit tests to a separate executable that links in all my libraries and runs their tests in debug/release mode. Works much better. I don't feel that unittest in D was really thought through properly for large projects targeting actual end users... -- - Alex
Re: toHash => pure, nothrow, const, @safe
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 as much code in unittests as real code. > > Which is a good thing, because in the past I'd always been too lazy to > > write any unittests at all. > > D doesn't make writing unit tests easy, since there's an intrinsic > amount of effort required to write them, just like there is with any > code, but it takes away all of the extraneous effort in having to set > up a unit test framework and the like. And by removing pretty much > anything from the effort which is not actually required, it makes > writing unit testing about as easy as it can be. I would argue that D *does* make unit tests easier to write, in that you can write them in straight D code inline (as opposed to some testing frameworks that require external stuff like Expect, Python, intermixed with native code), so you don't need to put what you're writing on hold while you go off and write unittests. You can just insert a unittest block after the function/class/etc immediately while the code is still fresh in your mind. I often find myself writing unittests simultaneously with real code, since while writing the code I see a possible boundary condition to test for, and immediately put that in a unittest to ensure I don't forget about it later. This improves the quality of both the code and the unittests. > 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. [...] Yep. They're so easy to write in D that I'd be embarrassed to *not* write them. T -- Famous last words: I *think* this will work...
Re: toHash => pure, nothrow, const, @safe
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 the past I'd always been too lazy to > write any unittests at all. D doesn't make writing unit tests easy, since there's an intrinsic amount of effort required to write them, just like there is with any code, but it takes away all of the extraneous effort in having to set up a unit test framework and the like. And by removing pretty much anything from the effort which is not actually required, it makes writing unit testing about as easy as it can be. 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. - Jonathan M Davis
Re: toHash => pure, nothrow, const, @safe
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 catch is whether the template is going to be pure, > nothrow, @safe, and/or CTFEable with _your_ arguments to it, but as > long as it's pure, nothrow, @safe, and/or CTFEable with _a_ set of > arguments, it will generally be the fault of the arguments when such a > function fails to be pure, nothrow, @safe, and/or CTFEable as > expected. If the unit tests don't hit all of the possible static > if-else blocks and all of the possible code paths for CTFE, it could > still be a problem, but that just means that the unit tests aren't > thorough enough, and more thorough unit tests will fix the problem, as > tedious as it may be to do that. [...] 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 always been too lazy to write any unittests at all. T -- Ruby is essentially Perl minus Wall.
Re: toHash => pure, nothrow, const, @safe
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 to be pure. CTFE has the same problem. It's fairly easy to have a > > function which is CTFEable cease to be CTFEable thanks to a change to it, > > and no one notices. We've had issues with this in the past. > > 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. 1. That goes completely against how CTFE was designed in that part of the idea was that you _wouldn't_ have to annotate it. 2. I don't really know how feasible that would be. At minimum, the fact that CTFE works with classes now would probably render it completely infeasible for classes, since they're polymorphic, and the compiler can't possibly know all of the possible types that could be passed to the function. Templates would screw it over too for the exact same reasons that they can have issues with pure, @safe, and nothrow. It may or may not be feasible without classes or templates being involved. 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 catch is whether the template is going to be pure, nothrow, @safe, and/or CTFEable with _your_ arguments to it, but as long as it's pure, nothrow, @safe, and/or CTFEable with _a_ set of arguments, it will generally be the fault of the arguments when such a function fails to be pure, nothrow, @safe, and/or CTFEable as expected. If the unit tests don't hit all of the possible static if-else blocks and all of the possible code paths for CTFE, it could still be a problem, but that just means that the unit tests aren't thorough enough, and more thorough unit tests will fix the problem, as tedious as it may be to do that. - Jonathan M Davis
Re: toHash => pure, nothrow, const, @safe
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 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. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? As long as you can explicitly specify that too, and that you get a compile time error when you fail to provide what is explicitly stated, this isn't a problem. But people might be relying on your API that just so happens to be pure, but then suddenly isn't! True, but without out, pure, @safe, and nothrow are essentially useless with templates, because far too many templates depend on their arguments for whether they can be pure, @safe, and/or nothrow or not. It's attribute inference for templates that made it possible to use something stuff like std.range and std.algorithm in pure functions. Without that, it couldn't be done (at least not without some nasty casting). Attribute inference is necessary for templates. 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 to be pure. CTFE has the same problem. It's fairly easy to have a function which is CTFEable cease to be CTFEable thanks to a change to it, and no one notices. We've had issues with this in the past. 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. In both cases, I believe that the best solution that we have is to unit test stuff to show that it _can_ be pure, @safe, nothrow, and/or CTFEable if the arguments support it, and then those tests can guarantee that it stays that way in spite of any code changes, since they'll fail if the changes break that. - Jonathan M Davis -- - Alex
Re: toHash => pure, nothrow, const, @safe
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. 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. For other functions, not so, and so the attributes must > >>> be part of the function signature. > >> > >> Isn't auto-inference for templates a Bad Thing (TM) since it may give > >> API guarantees that you can end up silently breaking? > > > > As long as you can explicitly specify that too, and that you get a > > compile time error when you fail to provide what is explicitly stated, > > this isn't a problem. > > But people might be relying on your API that just so happens to be pure, > but then suddenly isn't! True, but without out, pure, @safe, and nothrow are essentially useless with templates, because far too many templates depend on their arguments for whether they can be pure, @safe, and/or nothrow or not. It's attribute inference for templates that made it possible to use something stuff like std.range and std.algorithm in pure functions. Without that, it couldn't be done (at least not without some nasty casting). Attribute inference is necessary for templates. 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 to be pure. CTFE has the same problem. It's fairly easy to have a function which is CTFEable cease to be CTFEable thanks to a change to it, and no one notices. We've had issues with this in the past. In both cases, I believe that the best solution that we have is to unit test stuff to show that it _can_ be pure, @safe, nothrow, and/or CTFEable if the arguments support it, and then those tests can guarantee that it stays that way in spite of any code changes, since they'll fail if the changes break that. - Jonathan M Davis
Re: toHash => pure, nothrow, const, @safe
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? Because that requires having all of the source code. The fact that we have .di files prevents that. You'd have to be able to guarantee that you can always see the whole source (including the source of anything that the functions call) in order for attribute inferrence to work. The only reason that we can do it with templates is because we _do_ always have their source, and the fact that non- templated functions must have the attributes in their signatures makes it so that the templated functions don't need their source in order to determine their own attributes. The fact that we can't guarantee that all of the source is available when compiling a particular module seriously hampers any attempts at general attribute inference. - Jonathan M Davis
Re: toHash => pure, nothrow, const, @safe
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 adding one more special case to D purity. So for me it's a -1. Bye, bearophile
Re: toHash => pure, nothrow, const, @safe
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's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. A "@safe pure nothrow const" might be used as "@system". That means someone using a declaration may have a different view than someone providing the implementation. Those interface boundaries are also a good place for by-hand annotations to provide explicit API guarantees and enforce a correct implementation. Though another issue with inference is that it would require a depth-first-order for the semantic passes. I also hope we still don't mangle inferred attributes.
Re: toHash => pure, nothrow, const, @safe
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 done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? As long as you can explicitly specify that too, and that you get a compile time error when you fail to provide what is explicitly stated, this isn't a problem. But people might be relying on your API that just so happens to be pure, but then suddenly isn't! -- - Alex
Re: toHash => pure, nothrow, const, @safe
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 well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. 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). What about a new attribute @type (or better name?) that means "this function is part of the TypeInfo interface, and has an equivalent xFuncname in TypeInfo_Struct". Then it implicitly inherits all the attributes of that xFuncname (not necessarily defined by the compiler). Then, we can have several benefits: 1. This triggers the compiler to complain if we don't correctly define the function (as specified in TypeInfo_Struct). In other words, it allows the developer to specify "I want this function to go into TypeInfo". 2. It potentially allows additional interface hooks without compiler modification. For example, you could add xfoo in TypeInfo_Struct, and then every struct you define @type foo() would get a hook there. 3. As you wanted, it eliminates having to duplicate all the attributes. The one large drawback is, you need to annotate all existing functions. We could potentially assume that @type is specified on the functions that currently enjoy automatic inclusion in the TypeInfo_Struct instance. I'd recommend at some point eliminating this hack though. -Steve
Re: toHash => pure, nothrow, const, @safe
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 - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? As long as you can explicitly specify that too, and that you get a compile time error when you fail to provide what is explicitly stated, this isn't a problem.
Re: toHash => pure, nothrow, const, @safe
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 guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? -- - Alex
Re: toHash => pure, nothrow, const, @safe
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 KeyType s); They need to be, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted A 2. it's just plain annoying to annotate them Maybe we need @nice or something, to mean pure nothrow @safe. It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and That was sounding reasonable, but... @safe (if not already marked as @trusted). ...this part is a bit scary. It sounds as though the semantics are a bit fuzzy. There is no way to make a function as 'impure' or 'does_throw'. But you can annotate with @system. It may be a hack, but you know, those have special semantics/meanings in the first place, so is it really that bad? Agreed, they are in some sense virtual functions. But how would you declare those functions. With "pure nothrow @safe", or with "pure nothrow @trusted" ? Consider also that contract blocks are now implicitly const, etc. But the clutter problem isn't restricted to those specific functions. One issue with pure, nothrow is that they have no inverse, so you cannot simply write pure: nothrow: at the top of the file and use 'pure nothrow' by default. The underlying problem is that, when spelt out in full, those annotations uglify the code.
Re: toHash => pure, nothrow, const, @safe
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, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. 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). I don't really see the point. For Objects, we inherit from Object, which can define theses. For struct, we have inference, so most of the time attributes will correct. const pure nothrow @safe are something we want, but is it something we want to enforce ?
Re: toHash => pure, nothrow, const, @safe
> 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 change the implementation of Key.getHash
> then maybe it can no longer be inserted into that Set.
> If OTOH your set.insert were inferred pure itself, then
> the impureness would escalate to the set.insert(key) caller.
>
> It's about the same logic that would makes nothrow more useful.
> You can omit it most of the times but always have the
> possibility to enforce it, e.g. at a much higher level.
My point was more about distant code breaking. Its more to do with
unexpected behavior than code correctness in this case. As i said, I
could be worrying about nothing though.
--
James Miller
Re: toHash => pure, nothrow, const, @safe
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 don't know how much of a problem that could be, but
its one I can think of.
--
James Miller
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 change the implementation of Key.getHash
then maybe it can no longer be inserted into that Set.
If OTOH your set.insert were inferred pure itself, then
the impureness would escalate to the set.insert(key) caller.
It's about the same logic that would makes nothrow more useful.
You can omit it most of the times but always have the
possibility to enforce it, e.g. at a much higher level.
Re: toHash => pure, nothrow, const, @safe
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. For other functions, not so, and so the attributes must be part of the function signature.
Re: toHash => pure, nothrow, const, @safe
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 system assume const or immutable or inout or...? "@safe pure nothrow" as default could have worked better than manually setting it, I agree. @safe can be set at module level, so it is less of an issue to make it the default in your code. The problem with those attributes is not that pure is used more often than impure or nothrow more often than throws, but that they need to be set transitive in function calls. And even though the attributes do no harm to the user of the function (unlike immutable) they can easily be forgotten or left away, because it is tedious to type them. -- Marco
Re: toHash => pure, nothrow, const, @safe
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?
Re: toHash => pure, nothrow, const, @safe
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 break a guarantee you >> made previously. > > > What's wrong with auto-inference. Inferred attributes are only strengthening > guarantees. 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 don't know how much of a problem that could be, but its one I can think of. -- James Miller
Re: toHash => pure, nothrow, const, @safe
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 with auto-inference. Inferred attributes are only strengthening guarantees.
Re: toHash => pure, nothrow, const, @safe
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 int opCmp(ref const KeyType s)
Re: toHash => pure, nothrow, const, @safe
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, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. 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). 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.
Re: toHash => pure, nothrow, const, @safe
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 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 of code must be retrofitted 2. it's just plain annoying to annotate them Ah, I see the "just add a new attribute" thing is coming back to bite you. ;-) It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. 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). I'm wary of the idea of automatically-imposed attributes on a "special" set of functions... seems a bit arbitrary, and arbitrary things don't tend to stand the test of time. OTOH I can see the value of this. Forcing all toHash's to be pure nothrow @safe makes is much easier to, for example, implement AA's purely in object_.d (which I'm trying to do :-P). You don't have to worry about somebody defining a toHash that does strange things. Same thing with opEquals, etc.. It also lets you freely annotate stuff that calls these functions as pure, nothrow, @safe, etc., without having to dig through every function in druntime and phobos to mark all of them. Here's an alternative (and perhaps totally insane) idea: what if, instead of needing to mark functions as pure, nothrow, etc., etc., we ASSUME all functions are pure, nothrow, and @safe unless they're explicitly declared otherwise? IOW, let all D code be pure, nothrow, and @safe by default, and if you want non-pure, or throwing code, or unsafe code, then you annotate the function as impure, throwing, or @system. It goes along with D's general philosophy of safe-by-default, unsafe-if-you-want-to. No. Too late in the design process. I have 20k+ lines of code that rely on the opposite behavior. 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 system assume const or immutable or inout or...? 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. T -- - Alex
Re: toHash => pure, nothrow, const, @safe
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(ref const KeyType s); They need to be, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them Ah, I see the "just add a new attribute" thing is coming back to bite you. ;-) It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. 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). I'm wary of the idea of automatically-imposed attributes on a "special" set of functions... seems a bit arbitrary, and arbitrary things don't tend to stand the test of time. OTOH I can see the value of this. Forcing all toHash's to be pure nothrow @safe makes is much easier to, for example, implement AA's purely in object_.d (which I'm trying to do :-P). You don't have to worry about somebody defining a toHash that does strange things. Same thing with opEquals, etc.. It also lets you freely annotate stuff that calls these functions as pure, nothrow, @safe, etc., without having to dig through every function in druntime and phobos to mark all of them. Here's an alternative (and perhaps totally insane) idea: what if, instead of needing to mark functions as pure, nothrow, etc., etc., we ASSUME all functions are pure, nothrow, and @safe unless they're explicitly declared otherwise? IOW, let all D code be pure, nothrow, and @safe by default, and if you want non-pure, or throwing code, or unsafe code, then you annotate the function as impure, throwing, or @system. It goes along with D's general philosophy of safe-by-default, unsafe-if-you-want-to. No. Too late in the design process. I have 20k+ lines of code that rely on the opposite behavior. 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. T -- - Alex
Re: toHash => pure, nothrow, const, @safe
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); > > They need to be, as well as const, pure nothrow @safe. > > The problem is: > 1. a lot of code must be retrofitted > 2. it's just plain annoying to annotate them Ah, I see the "just add a new attribute" thing is coming back to bite you. ;-) > It's the same problem as for Object.toHash(). That was addressed by > making those attributes inheritable, but that won't work for struct > ones. > > 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). I'm wary of the idea of automatically-imposed attributes on a "special" set of functions... seems a bit arbitrary, and arbitrary things don't tend to stand the test of time. OTOH I can see the value of this. Forcing all toHash's to be pure nothrow @safe makes is much easier to, for example, implement AA's purely in object_.d (which I'm trying to do :-P). You don't have to worry about somebody defining a toHash that does strange things. Same thing with opEquals, etc.. It also lets you freely annotate stuff that calls these functions as pure, nothrow, @safe, etc., without having to dig through every function in druntime and phobos to mark all of them. Here's an alternative (and perhaps totally insane) idea: what if, instead of needing to mark functions as pure, nothrow, etc., etc., we ASSUME all functions are pure, nothrow, and @safe unless they're explicitly declared otherwise? IOW, let all D code be pure, nothrow, and @safe by default, and if you want non-pure, or throwing code, or unsafe code, then you annotate the function as impure, throwing, or @system. It goes along with D's general philosophy of safe-by-default, unsafe-if-you-want-to. Or, as a compromise, perhaps the compiler can auto-infer most of the attributes without any further effort from the user. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Re: toHash => pure, nothrow, const, @safe
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 :-) Bye, bearophile
Re: toHash => pure, nothrow, const, @safe
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 don't think it hurts to make this change. But I may be missing some implications.
Re: toHash => pure, nothrow, const, @safe
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. Regarding this hack proposal of yours, I don't fully understand its consequences yet. What are the negative sides of this idea? Bye, bearophile
Re: toHash => pure, nothrow, const, @safe
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, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. 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). 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. -- - Alex
toHash => pure, nothrow, const, @safe
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 of code must be retrofitted 2. it's just plain annoying to annotate them It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. 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).
