IFTI, value types, and top-level const

Jonathan M Davis jmdavisProg at gmx.com
Sun Jun 9 04:15:45 PDT 2013


On Sunday, June 09, 2013 12:59:33 monarch_dodra wrote:
> On Sunday, 9 June 2013 at 10:49:17 UTC, Jonathan M Davis wrote:
> > On Sunday, June 09, 2013 12:33:39 Peter Alexander wrote:
> >> It looks like the core issue here is that it's simply not
> >> possible to create a mutable copy of a const object with
> > 
> >> indirection:
> > Part of my point here (that you seem to have missed) is that
> > there is a cost
> > to making it so that const is stripped from the type even if
> > you can do so. It
> > _forces_ a copy if the value being passed in isn't mutable,
> > whereas if the
> > constness were the same, then the value being passed in could
> > potentially be
> > moved rather than copied. As such, I don't know if we even want
> > to strip the
> > constness even if we can.
> > 
> > - Jonathan M Davis
> 
> Well, these are primitives we are talking about. I'm not sure
> passing an int by value instead of by ref is much more expansive.
> We already do the same for slices/pointers, so really, all we are
> doing is making things consistent.
> 
> I agree with your point for structs though. Given any struct,
> even if POD without indirections, const means const.
> 
> But for built-in primitives, I don't think it is a problem.

It probably would be fine for primitives, but it's nowhere near as clearcut for 
structs, and it would arguably make things _less_ consistent if IFTI took the 
tail-const version of all primitives but not for structs. So, I don't know if 
it's a good idea or not for IFTI to take the tail-const type for all primitive 
types.

- Jonathan M Davis


More information about the Digitalmars-d mailing list