Why do we still need the "Address Of" syntax?

Why do we still need the "Address Of" syntax?

• Big Kahuna

  >Isn't what is currently supported just as ambiguous.
  
  No, the examples you provide are resolved by normal scoping rules. In Main X refers to the local variable, and in Print to the parameter, since they are more local than the function X.
  
  In the situation Alex describes, you bind to the same function. But you can't tell if you want to call the function or create a delegate for it. In C# this isn't ambiguous since you need parentheses for a method call. Since they are optional in VB you need the AddressOf syntax to disambiguate.
  
  
  
  

• J-Thread

  "That's all part of the nature of VB - descriptiveness rather than conciseness".  Yes, but the "address of" operater is actually shorthand for the following C#.
  
  I'm changing the callback function to AddFive instead of the initial Add25
  
  Function AddFive(byval param as integer) as integer
    return param + 5
  end function
  
  'VB
  DoItTwice(10, address of AddFive)
  
  'C# 1.0
  DoItTwice(10, new Funk<int>(AddFive));
  
  'C# 2.0
  DoItTwice(10, delegate(int param) {return param + 5}));
  
  'C# 3.0
  DoItTwice(10, param => param + 5);
  
  Notice how C# continues to evolve the way it deals with functions   Why does VB insist on sticking with the VB6 era "address of" operater   These are just questions we as the VB community should be asking the shepards of the language.
  
  

• DGPunkt

  Also, without addressof, you can have situations where you wouldn't be able to disambiguate between the function's address and the function's return.
  For example:
  
  Delegate function Test() as Test
  
  Function ActualTest as Test
  
  sub TakesDelegate(arg as Test)
  end sub
  
  TakesDelegate(ActualTest)
  
  
  In this situation, some people might assume the return of the function would be used, others the function signature - whatever way you'd code the compiler, a relatively large group of people are likely to introduce bugs on their code.
  
  Even worse, now imagine you also have a function defined as:
  Function ActualTest2(of integer) as Test
  
  and you call:
  TakesDelegate(ActualTest2(5))
  
  It's fairly obvious that this should also work, which means that we either have a fairly complex resolution scheme (take the function method unless it's an incokation, in that case try to get the return value or something like that).
  
  In my opinion, not having the addressof operator would make the language more prone to hard to find bugs.

  
  
  

• GhostGT

  That's all part of the nature of VB - descriptiveness rather than conciseness.
  
  For example, why 'Dim' or why 'End Function' or why 'Then'   The compiler would be able to infer these (and dozens of other redundant statements).
  
  VB is good at reminding you what's going on.  If you want conciseness, you'll have to look at other languages, such as C# (which isn't so great at descriptiveness).
  
  David Anton
  www.tangiblesoftwaresolutions.com
  Instant C#: VB.NET to C# Converter
  Instant VB: C# to VB.NET Converter
  Instant C++: C# to C++ Converter
  Instant J#: VB.NET to J# Converter
  Clear VB: Cleans up VB.NET code
  
  

• Rajesh Chandrashekaran

  I guess i'm trying to understand why VB continues to treat functions different from variables.  Isn't what is currently supported just as ambiguous.
  
  Function X() as integer
    return 5
  end function
  
  Sub Main
    dim X as integer
    X = 10
    Print(X)  'X variable or X function  
  end sub
  
  Sub Print(X as integer)
    Console.Writeline(X)
  end sub
  
  I guess i'm arguing that they are in fact identical.  The local variable is a very simple function that returns the value 10 no different from the declared function that returns 5.

  
  
  
• Why do we still need the "Address Of" syntax?