Safe navigation operator

[Chad J]

On 02/19/2012 09:50 PM, Alex Rønne Petersen wrote:
> On 20-02-2012 03:35, Chad J wrote:
>> On 02/19/2012 08:00 PM, Bernard Helyer wrote:
>>> On Monday, 20 February 2012 at 00:55:15 UTC, Alex Rønne Petersen wrote:
>>>> Hi,
>>>>
>>>> http://groovy.codehaus.org/Operators#Operators-SafeNavigationOperator
>>>>
>>>> What do you folks think about this? Would it be useful to have in D?
>>>> It would make navigating large object graphs with possible null values
>>>> much easier.
>>>
>>> The traditional counter point to this is that it encourages bad/lazy
>>> design. I don't really agree, but I don't ache for it either.
>>
>> I wonder then, if this argument has been made:
>>
>> I think non-nullable types would be /far/ more helpful for this.
>>
>> As far as I can tell, the intend of having a "better" design would be to
>> find undesired nulls as close to their origination point as possible. I
>> really think there have to be more methodical ways to do this (ex:
>> non-nullable types) that don't rely on fallable human whim. After all,
>> if I need the ?. and don't have it, I'll just write an if-statement
>> instead. It'll be the same poor design, and it will be more difficult to
>> read too.
>>
>> Or maybe... in debug mode references could be fat pointers that have
>> both the data ptr and a second integer that points to information about
>> where the last assignment took place.
>>
>> struct PhatRef(T)
>> {
>> T* data;
>> AssignmentEntry* lastAssignment;
>> }
>>
>> struct AssignmentEntry
>> {
>> string fileName;
>> size_t lineNumber;
>> }
>>
>>
>> Then this:
>>
>> void main()
>> {
>> Foo foo;
>> }
>>
>> Gets lowered by the compiler into this:
>>
>> void main()
>> {
>> Foo foo;
>> foo.lastAssignment.fileName = "main.d";
>> foo.lastAssignment.lineNumber = 2;
>> }
>>
>> When the null foo is referenced, the crash handler/debugger/whatever can
>> traverse the AssignmentEntry structure and display the debugging info.
>> This would save soooooo much time!
>
> I'd personally have to object to this. My virtual machine code heavily
> relies on references being plain pointers. That being said, the idea is
> not bad at all! (It would be easily realizable in a managed language.)
>
> It would be nice if D had language-integrated non-nullable types a la
> Spec#.
>

Yeah, I figured the fat pointer would have to be configurable somehow 
just because of exactly this sort of thing.

I still wonder what code that breaks with this would look like exactly. 
  Maybe there is a way to make it work in more possible situations.