Feature request: Force default result on calls without one.

[norbertjurkiewicz84]

Often times my D functions call other functions and .NET methods that do not return anything. This happens often with WPF calls. I often fall back to executing a statement within a nested guarded expression or covering the (.NET) call in a Tfn to force a result. An I-Beam or another language feature to do the same would be a nice shortcut.

      test←{
     ⎕USING←'System' 'System.Windows,WPF/PresentationFramework.dll'

     ⍝ Option 0. Execute and get out
     w←⎕NEW Window
   ⍝ w.Show
     ⍝ ...

     ⍝ Option 1. Fails with a VALUE ERROR
     w←⎕NEW Window
     ok←w.Show

     ⍝ Option 2. This works but needs extra encapsulation.
     w←⎕NEW Window
     ok←{6::0 ⋄ _←⍵.Show}w

     ⍝ Option 3. Use a TradFn for the call
     exec←'Z←ShowCover window' 'window.Show' 'Z←0'
     _←⎕FX exec
     w←⎕NEW Window
     ok←ShowCover w

     ⍝ ...
     ⍝ do other stuff ...
     ⍝ ...
     0
 }

My thought is maybe something along these lines.

Code: Select all

     ⍝ ok ← (?⌶)w.Show
     ⍝ ok = 0
     ⍝ ok ← 1(?⌶)w.Show
     ⍝ ok = 1


[JohnS|Dyalog]

I think a function derived from I-beam might be a problem because the VALUE ERROR would occur before we got to it. However a system operator (⎕something) might fit the bill. See http://dfns.dyalog.com/n_do.htm for a model.

PS: I like your idea of optionally passing the preferred result as left argument.

[norbertjurkiewicz84]

I think a function derived from I-beam might be a problem because the VALUE ERROR would occur before we got to it. However, a system operator (⎕something) might fit the bill. See http://dfns.dyalog.com/n_do.htm for a model.

PS: I like your idea of optionally passing the preferred result as the left argument.

I think I used that technique a while back but it has the same issue as the above. You need to create it in your namespace or reference a full path to a utility.