[OT] What are D's values? (page 8)

October 08, 2021

Re: [OT] What are D's values?

Posted by Steven Schveighoffer
in reply to H. S. Teoh

Permalink

Steven Schveighoffer

Posted in reply to H. S. Teoh

Permalink

On 10/7/21 1:35 PM, H. S. Teoh wrote:

On Wed, Oct 06, 2021 at 11:59:46AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
[...]

There is one place where I have struggled though, and D might be able to do
better. And that is with optional parentheses and taking the address. When a
property can be either an accessor or a field, then obj.prop can work the
same. However, &obj.prop is not the same.

I have solved it by using this stupid function:

auto ref eval(T)(auto ref T t) { return t; }

// instead of &obj.prop
auto ptr = &eval(obj.prop);

IMO, taking the address of something is a low-level operation that
doesn't really belong in higher-level logic. Unsurprisingly, therefore,
it doesn't lend itself well to the malleability that generally applies
in D code.

The fact of taking the address of something imposes the implicit
assumption that that object has an address to be taken in the first
place. Meaning that once you use such an operation, the target object
is no longer Liskov-substitutable with anything else that may not have
an address (e.g. an accessor function). So this imposes limitations on
what kinds of refactoring the code will be amenable to.

To give more context, it is solely for this little function:

auto firstElem(R)(R r) if (hasLvalueElements!R)
{
    if(r.empty)
        return null;
    return &(eval(r.front));
}

Why do I need this function? Because Phobos doesn't give me nice access to things from find. Instead, it gives me a range. Which is useful for some cases, but for others, I just want to get reference access of the element I was looking for.

So compare the two possibilities:

auto result = someRange.find(elem);
if(!result.empty) {
   if(result.front.x > 5)
       result.front.x -= 5;
}

// vs.

if(auto v = someRange.find(elem).firstElem) {
   if(v.x > 5)
       v.x -= 5;
}

For some things, pointers are the best interface.

Sure, I could wrap this up in a type, but it still would need to store a pointer internally (or the range itself), plus a pointer is already doing exactly what I need it to do.

The main issue is that obj.method means different things depending on context.

As kind of another similar story, A long time ago, an eponymous template allowed some access to things inside the template, and did not always map directly to the eponymous member in some situations. While this allowed greater flexibility, it produced odd behavior. Eventually, all access of the internals of an eponymous template were removed, and it always always just means the eponymous member. This removed some expressiveness, but the result is much much cleaner.

I would like to see something similar for property methods.

[...]

While it's nice D has a mechanism to work around this difference, I
find having to use such shims a bit awkward. And it's a direct
consequence of hiding the implementation of a field/property behind
the same syntax. You can find other cases where D can be awkward (such
as typeof(obj.prop) or checking types regardless of mutability).

What is the "better" answer though? I don't know.
[...]

Not necessarily a better answer: static if to discover whether something
is a field or an accessor, and extract the address appropriately,
possibly encapsulated in a utility function? Not much different from
your .eval hack, though.

This would be horrid. Basically, your code starts looking like:

static if(isAccessor!(obj.foo)) // have fun writing this, there's lots of traps.
   return &obj.foo();
else
   return &obj.foo;

The eval hack is much much cleaner. It means "this is an expression, not a symbol". Maybe the answer is to do this with some syntax feature, so I can avoid calling silly hack functions.

The C++ answer is to allow overloading of unary &. However, that opens
up a whole 'nother can o' worms that I would not recommend.

Nope, I would never want that. I want a pointer when I ask for a pointer.

-Steve

On 10/8/21 2:53 AM, Arjan wrote: > From my experience: > > Use case: replacing 2 executables with one written in D in a system > consisting of multiple executables all written in C++ using various > libraries and a proprietary bus system originally designed and build in > 2004. Are you sure it worked? Because Bjarne thinks "it doesn't work". ;) https://youtu.be/ae6nFZn3auQ?t=2228 Ali P.S. More interesting bits from the video: After praising C++'s Core Guidelines (which contains 400+ rules by my last count) for years (and introducing it with a bang along with Herb Sutter at a C++ conference, reference of which I can't find anymore), he contradicts himself by saying "humans are not actually very good at following rules": https://youtu.be/ae6nFZn3auQ?t=2039 Of course, ultimate blame for C++ bugs goes to "static analysis community": https://youtu.be/ae6nFZn3auQ?t=2345 So, perhaps I misunderstood the guidelines: They were not for humans to begin with? Nah! They were and are for humans. I followed similar C++ rules personally for about 20 years. Despite Bjarne's understanding the value of fat pointers (D's slices): https://youtu.be/ae6nFZn3auQ?t=2145 ... he does not think "the solution is necessarily another language": https://youtu.be/ae6nFZn3auQ?t=1758 I watched the video only between minutes 29 and 42, so there may be more gems in there.

Forums