December 20, 2018 Re: Blog post: What D got wrong | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe wrote:
> The attribute spam is almost longer than the function itself.
I often wished for something like
----
module foo.bar;
default(@safe, pure);
function foo() { } // is annotated with @safe & pure
@deny(pure) // or pure(false) as I suggested a long time ago
function bar() { } // is annotated only with @safe
----
That would IMO lighten the burden.
|
December 20, 2018 Re: Blog post: What D got wrong | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dgame Attachments:
| default(attributes..) is no needed. You can already do this by: pure @safe: // your code But what is needed is some way to disable those attributes. As you mentioned one way could be done by allowing this: pure(false) or pure!false or @disable(pure,@nogc...) >From implementation point of view it is not hard. I have already implemented this before. I have even write some old DIP. But there is new DIP process so someone need to write a new one and need to be able to get it throw new DIP process. And I do not feel I have enough strength to do this right now. čt 20. 12. 2018 8:50 odesílatel Dgame via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> napsal: > On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe wrote: > > The attribute spam is almost longer than the function itself. > > I often wished for something like > > ---- > module foo.bar; > > default(@safe, pure); > > function foo() { } // is annotated with @safe & pure > > @deny(pure) // or pure(false) as I suggested a long time ago > function bar() { } // is annotated only with @safe > ---- > > That would IMO lighten the burden. > |
December 20, 2018 Re: Blog post: What D got wrong | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rubn | On Wednesday, 19 December 2018 at 23:10:34 UTC, Rubn wrote:
> On Wednesday, 19 December 2018 at 19:58:53 UTC, Neia Neutuladh wrote:
>> [...]
>
> To be fair even in c++ this won't be a reference.
>
> int& foo();
> auto a = foo(); // a == int
> auto& a = foo(); // a == int&
>
> So it shouldn't be that surprising.
decltype(auto) a = foo(); // a == int&
And you can explicitly declare `auto&` in C++, which you can't do in D.
|
December 20, 2018 Re: Blog post: What D got wrong | ||||
---|---|---|---|---|
| ||||
Posted in reply to Neia Neutuladh | On 12/19/18 2:58 PM, Neia Neutuladh wrote:
> On Wed, 19 Dec 2018 17:28:01 +0000, Vijay Nayar wrote:
>> Could you please elaborate a little bit more on this? In the linked
>> program, I had expected that "ref" would return a reference to "a" that
>> would behave similar to a pointer.
>
> They work like pointers that automatically dereference when assigning to
> the base type.
>
> Only three things in D can be ref:
> * A function parameter
> * A function return value
> * A foreach variable (since that's either going to be a function return
> value, a function parameter, or a pointer, depending on what you're
> iterating over)
>
> So when the compiler sees something like:
>
> ref int foo();
> auto a = foo();
>
> It sees that the type of 'a' has to be the same as the return type of
> 'foo'. Except that's not possible, so it uses the nearest equivalent type:
> int.
I would say it a little bit differently -- the return *type* of foo is int. In D, ref is not part of the type at all.
For example, even when it *could* use ref, it doesn't:
int x;
ref int foo() { return x; }
void bar(Args...)(Args args)
{
pragma(msg, __traits(isRef, args[0]));
}
bar(foo()); // outputs false at compile time
The storage class is completely separate from the type. Which is different from C++, where it's like a storage class but is really a type constructor, hence Walter's post.
-Steve
|
December 20, 2018 Re: Blog post: What D got wrong | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Kozak | On Thu, 20 Dec 2018 14:19:33 +0100, Daniel Kozak wrote:
> default(attributes..) is no needed. You can already do this by:
>
> pure @safe:
> // your code
That doesn't work if you have any member functions, and Walter says it's unlikely that that will ever change, even with a DIP.
default(pure) would be new syntax with no existing code broken.
|
Copyright © 1999-2021 by the D Language Foundation