Re: This Week in D is back
On Wednesday, 19 December 2018 at 14:24:01 UTC, Adam D. Ruppe wrote: On Wednesday, 19 December 2018 at 14:17:53 UTC, bauss wrote: Thank you Adam for bringing it back. I enjoyed it back when it last ran. You might enjoy looking at the "home" page too: http://dpldocs.info/this-week-in-d/Blog.html links to the old ones, and to the Tip of the Week index from before to quickly skim! I also like the part where explain what you're currently working on. That's kinda interesting.
Re: This Week in D is back
On Monday, 17 December 2018 at 22:01:07 UTC, Adam D. Ruppe wrote: Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html Thanks Adam! I really loved the tips/tricks part in your old TWiD. I've learned quite a bit off of those so thanks again!
Re: Blog post: What D got wrong
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.
Re: Blog post: What D got wrong
On 12/19/18 2:58 PM, Neia Neutuladh wrote:
On Wed, 19 Dec 2018 17:28:01 +, 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
Re: Blog post: What D got wrong
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.
Re: Blog post: What D got wrong
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.
>
