Safe navigation operator

[Alex Rønne Petersen]

On 20-02-2012 06:53, Chad J wrote:
> 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.

Well, in my case, I'm emitting raw machine code that simply uses 
references as pointers. I could adjust it to work with fat pointers, but 
then that means I have to special-case code generation when using the D 
runtime's GC versus any of the built-in GCs, which would be annoying. :/

-- 
- Alex