View mode: basic / threaded / horizontal-split · Log in · Help
October 14, 2012
Making TypeInfo.next() return a const(TypeInfo) was a bad idea
Because you are now no longer able to do stuff like this:

void log(...)
{
  auto t = _arguments[0];
  while(some condition)
  {
    t = t.next();
  }
}

To be actually able to use TypeInfo.next you will now need the ConstRef 
(hack) from phobos. Afaik there is no such thing in druntime which makes 
working with TypeInfo.next within druntime a real pita.

Any suggestions?

Kind Regards
Benjamin Thaut
October 15, 2012
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
On 14-10-2012 12:19, Benjamin Thaut wrote:
> Because you are now no longer able to do stuff like this:
>
> void log(...)
> {
>    auto t = _arguments[0];
>    while(some condition)
>    {
>      t = t.next();
>    }
> }
>
> To be actually able to use TypeInfo.next you will now need the ConstRef
> (hack) from phobos. Afaik there is no such thing in druntime which makes
> working with TypeInfo.next within druntime a real pita.
>
> Any suggestions?
>
> Kind Regards
> Benjamin Thaut

None, to be honest. I can only recommend going with a cast hack or 
something similar for now.

But this is a problem we *must* solve. It is something I also ran into 
often while hacking on druntime.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
October 15, 2012
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
On 10/14/2012 12:19 PM, Benjamin Thaut wrote:
> Because you are now no longer able to do stuff like this:
>
> void log(...)
> {
>    auto t = _arguments[0];
>    while(some condition)
>    {
>      t = t.next();
>    }
> }
>
> To be actually able to use TypeInfo.next you will now need the ConstRef
> (hack) from phobos. Afaik there is no such thing in druntime which makes
> working with TypeInfo.next within druntime a real pita.

That's the general problem of non-rebindable const references which is a 
real pita. There has been a pull request to implement it 
(https://github.com/D-Programming-Language/dmd/pull/3) but unfortunately 
it never made it into the compiler.

>
> Any suggestions?

You could create a recursive function hoping for 
tail-recursion-optimization and inlining:

void log(...)
{
   static const(TypeInfo) drillInto(const(TypeInfo) t)
   {
      if(some condition)
        return drillInto(t.next());
      return t;
   }
   auto t = drillInto(_arguments[0]);
}
October 15, 2012
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
On Monday, October 15, 2012 02:20:23 Alex Rønne Petersen wrote:
> But this is a problem we *must* solve. It is something I also ran into
> often while hacking on druntime.

If we really need Rebindable in druntime, then we can simply move it to an 
appropriate place in druntime and alias std.typecons.Rebindable to it.

core.time exists specifically because druntime needed some of the datetime stuff 
(most particularly the duration stuff). Otherwise, everything in it would be in 
std.datetime (where it was when originally proposed).

We can do the same with other constructs if we really need to. We just don't 
want to be moving them to druntime if we don't actually need to.

- Jonathan M Davis
October 15, 2012
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
http://stackoverflow.com/questions/12506338
October 15, 2012
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
On Monday, October 15, 2012 08:44:51 Mehrdad wrote:
> http://stackoverflow.com/questions/12506338

Yes. The problem is that he's trying to do something in druntime, and 
Rebindable is declared in Phobos.

- Jonathan M Davis
Top | Discussion index | About this forum | D home