Thread overview | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 12, 2014 It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
This happens to me all the time. I write a function, stick the aforementioned attributes on as a default then let the compiler tell me when I can't. That happens a lot more often than I thought it would. Pretty much anytime I call a Phobos function I have to remove at least one of them but usually all three. Is it similar for everyone else? Is it considered a problem? The other thing is I frequently have to "unconstify" my variables to get them accepted by Phobos functions as well. I should've kept examples but I didn't, this is all from what I remember happening in the last week or so. Atila |
September 12, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | Atila Neves: > Is it similar for everyone else? Yes, it's common. > Is it considered a problem? It's a moderately small problem, and it's being worked on since lot of time. Originally D didn't have those attributes, so Phobos was not designed for them. So adding them to Phobos (and D) is a work in progress, and there are also some blocking problems (Like: http://forum.dlang.org/thread/stlslhjndgugecvmbowd@forum.dlang.org ). In some cases some functions can't just have all attributes, because they need to throw, or they are not designed to be pure, etc. Bye, bearophile |
September 12, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On Friday, 12 September 2014 at 09:53:45 UTC, Atila Neves wrote: > This happens to me all the time. I write a function, stick the aforementioned attributes on as a default then let the compiler tell me when I can't. > > That happens a lot more often than I thought it would. Pretty much anytime I call a Phobos function I have to remove at least one of them but usually all three. > > Is it similar for everyone else? Is it considered a problem? Phobos still hasn't been fully annotated since these attributes were introduced, but we are making progress. For one, I believe we got @safe std.stdio recently, which should be a big boost for @safe adoption in general. It is slowly getting better. Pull requests are welcome. > The other thing is I frequently have to "unconstify" my variables to get them accepted by Phobos functions as well. D's const is very different from C++'s const. It's tempting to use in the same situations because of superficial similarities, but D's const should only be used when immutable is in the picture. D simply doesn't have the equivalent of C++'s const (which is intentional), despite their similar names. That said, there are fundamental issues with const and immutable that have yet to be resolved - for example, given an immutable container or a const reference to a container, it's not possible to get a head-mutable range over it for iteration. This is different from in-built slices which are conveniently convertible from const(T[]) to const(T)[], something that is not expressible with user-defined types at the moment. Further, `inout` does not support considering callback parameters to be "out parameters": struct S { int* p; inout(int)* foo() inout { return p; } // OK void bar(void delegate(inout int*) dg) inout { // Not supported dg(p); } } Both of these issues have been discussed before and IIRC, consensus seemed to be that we do want to do something about them. |
September 12, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | I know about the differences between C++ const and D const. I'm not talking about head-const, tail-const or logical const.
If I'm not mistaken, the last thing that happened to me was storing the captures from a regex into a const variable, then I couldn't index it.
I didn't look at the implementation, but it's very weird to me that getting an element can't be done on a const object. And yes, I'll look into doing a PR for it.
I'm using stdx.data.json a bit now as well, and will have to give feedback there. I can't make anything const, it seems.
I wasn't aware of @safe stdio, it always annoyed me that @safe functions can't call writeln, that never made any sense to me.
Atila
On Friday, 12 September 2014 at 10:19:27 UTC, Jakob Ovrum wrote:
> On Friday, 12 September 2014 at 09:53:45 UTC, Atila Neves wrote:
>> This happens to me all the time. I write a function, stick the aforementioned attributes on as a default then let the compiler tell me when I can't.
>>
>> That happens a lot more often than I thought it would. Pretty much anytime I call a Phobos function I have to remove at least one of them but usually all three.
>>
>> Is it similar for everyone else? Is it considered a problem?
>
> Phobos still hasn't been fully annotated since these attributes were introduced, but we are making progress. For one, I believe we got @safe std.stdio recently, which should be a big boost for @safe adoption in general.
>
> It is slowly getting better. Pull requests are welcome.
>
>> The other thing is I frequently have to "unconstify" my variables to get them accepted by Phobos functions as well.
>
> D's const is very different from C++'s const. It's tempting to use in the same situations because of superficial similarities, but D's const should only be used when immutable is in the picture. D simply doesn't have the equivalent of C++'s const (which is intentional), despite their similar names.
>
> That said, there are fundamental issues with const and immutable that have yet to be resolved - for example, given an immutable container or a const reference to a container, it's not possible to get a head-mutable range over it for iteration. This is different from in-built slices which are conveniently convertible from const(T[]) to const(T)[], something that is not expressible with user-defined types at the moment.
>
> Further, `inout` does not support considering callback parameters to be "out parameters":
>
> struct S
> {
> int* p;
>
> inout(int)* foo() inout { return p; } // OK
>
> void bar(void delegate(inout int*) dg) inout { // Not supported
> dg(p);
> }
> }
>
> Both of these issues have been discussed before and IIRC, consensus seemed to be that we do want to do something about them.
|
September 12, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | On Friday, 12 September 2014 at 10:19:27 UTC, Jakob Ovrum wrote: > Further, `inout` does not support considering callback parameters to be "out parameters": > > struct S > { > int* p; > > inout(int)* foo() inout { return p; } // OK > > void bar(void delegate(inout int*) dg) inout { // Not supported > dg(p); > } > } Looks like it works: http://dpaste.dzfl.pl/04a33be05658 |
September 12, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 12-Sep-2014 16:43, Atila Neves пишет: > I know about the differences between C++ const and D const. I'm not > talking about head-const, tail-const or logical const. > If I'm not mistaken, the last thing that happened to me was storing the > captures from a regex into a const variable, then I couldn't index it. > I didn't look at the implementation, but it's very weird to me that > getting an element can't be done on a const object. And yes, I'll look > into doing a PR for it. My problem with const is that people try to use it as often as logical const in C++ (everywhere), it DOESN'T HAVE to be as used as often. Being binary-wise immutable is harsh requirement on implementation, and forbids many techniques (like COW and ref-counting). That's one reason we might never have const Captures in std.regex. > > I'm using stdx.data.json a bit now as well, and will have to give > feedback there. I can't make anything const, it seems. > > I wasn't aware of @safe stdio, it always annoyed me that @safe functions > can't call writeln, that never made any sense to me. > > Atila > > On Friday, 12 September 2014 at 10:19:27 UTC, Jakob Ovrum wrote: >> On Friday, 12 September 2014 at 09:53:45 UTC, Atila Neves wrote: >>> This happens to me all the time. I write a function, stick the >>> aforementioned attributes on as a default then let the compiler tell >>> me when I can't. >>> >>> That happens a lot more often than I thought it would. Pretty much >>> anytime I call a Phobos function I have to remove at least one of >>> them but usually all three. >>> >>> Is it similar for everyone else? Is it considered a problem? >> >> Phobos still hasn't been fully annotated since these attributes were >> introduced, but we are making progress. For one, I believe we got >> @safe std.stdio recently, which should be a big boost for @safe >> adoption in general. >> >> It is slowly getting better. Pull requests are welcome. >> >>> The other thing is I frequently have to "unconstify" my variables to >>> get them accepted by Phobos functions as well. >> >> D's const is very different from C++'s const. It's tempting to use in >> the same situations because of superficial similarities, but D's const >> should only be used when immutable is in the picture. D simply doesn't >> have the equivalent of C++'s const (which is intentional), despite >> their similar names. >> >> That said, there are fundamental issues with const and immutable that >> have yet to be resolved - for example, given an immutable container or >> a const reference to a container, it's not possible to get a >> head-mutable range over it for iteration. This is different from >> in-built slices which are conveniently convertible from const(T[]) to >> const(T)[], something that is not expressible with user-defined types >> at the moment. >> >> Further, `inout` does not support considering callback parameters to >> be "out parameters": >> >> struct S >> { >> int* p; >> >> inout(int)* foo() inout { return p; } // OK >> >> void bar(void delegate(inout int*) dg) inout { // Not supported >> dg(p); >> } >> } >> >> Both of these issues have been discussed before and IIRC, consensus >> seemed to be that we do want to do something about them. > -- Dmitry Olshansky |
September 12, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On Fri, Sep 12, 2014 at 09:53:44AM +0000, Atila Neves via Digitalmars-d wrote: > This happens to me all the time. I write a function, stick the aforementioned attributes on as a default then let the compiler tell me when I can't. > > That happens a lot more often than I thought it would. Pretty much anytime I call a Phobos function I have to remove at least one of them but usually all three. Yeah, I run into that a lot. Unfortunately, it just makes me give up and not use those attributes. > Is it similar for everyone else? Is it considered a problem? Well, we've been getting a steady stream of Phobos PR's to annotate Phobos functions so that they have maximal attributes. It's slow work, but it's progressing. Not long ago, for example, std.format was made pure and @safe, so now it is CTFE-able, which is a big boon for compile-time metaprogramming. Additional help in this area would be greatly appreciated! > The other thing is I frequently have to "unconstify" my variables to get them accepted by Phobos functions as well. > > I should've kept examples but I didn't, this is all from what I remember happening in the last week or so. [...] Keep in mind that D's const is much stronger than C++'s const, it imposes *binary* const-ness, not just logical const-ness like in C++. This means you can't do logically const operations like lazy class object loading, caching, updating reference counts, etc.. Which in turn means that there are less places where you can use const in D, than in C++. There are some rough corners, though, like iterating over a const container. If the container is a linked-list, say, and you pass in a const container, then all pointers in the container will be const as well, by transitivity. However, that means you can't iterate over the pointers, because, being const, they cannot be modified, so it's illegal to update your iteration pointer! There are ways to work around this without breaking the type system, but it does require extra work. T -- Public parking: euphemism for paid parking. -- Flora |
September 13, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Friday, 12 September 2014 at 13:11:19 UTC, Kagamin wrote: > On Friday, 12 September 2014 at 10:19:27 UTC, Jakob Ovrum wrote: >> Further, `inout` does not support considering callback parameters to be "out parameters": >> >> struct S >> { >> int* p; >> >> inout(int)* foo() inout { return p; } // OK >> >> void bar(void delegate(inout int*) dg) inout { // Not supported >> dg(p); >> } >> } > > Looks like it works: http://dpaste.dzfl.pl/04a33be05658 Now try calling it: http://dpaste.dzfl.pl/bbd02a4d61df |
September 13, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | On Saturday, 13 September 2014 at 01:37:59 UTC, Jakob Ovrum wrote:
> Now try calling it: http://dpaste.dzfl.pl/bbd02a4d61df
That way it shouldn't work as it would break the type system, that code is equivalent to:
struct S
{
int* p;
inout(int)* foo() inout { return p; } // OK
void bar(void delegate(const int*) dg) const {
dg(p);
}
}
void main()
{
import std.stdio;
S s;
writeln(s.foo());
immutable(S) s2;
s2.bar((const int* p) => writeln(p));
s.bar((const int* p) => writeln(p));
}
Is there a reason, why you would need inout there?
|
September 13, 2014 Re: It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 09/13/2014 06:44 PM, Kagamin wrote:
>
> Is there a reason, why you would need inout there?
s.bar((int* p){ ++*p; });
|
Copyright © 1999-2021 by the D Language Foundation