On Monday, 1 July 2013 at 16:33:56 UTC, Ary Borenszweig wrote:
>
> I'll give you an example:
>
> # var can be an Int or String
> def foo(var)
>   var = var.to_s
>   # do something with var, which is now guaranteed to be a string
> end
>
> I can call it like this:
>
> foo(1)
> foo("hello")
>
> If I had to put types, I would end up doing of of these:
>
> 1.
>
> void foo(int var) {
>   foo(to!string(var))
> }
>
> void foo(string var) {
>   // do something with var
> }
>
> 2.
>
> void foo(T)(T var) {
>   string myVar;
>   static if (is(T == string)) {
>     myVar = var;
>   } else if (is(T == int)) {
>     myVar = to!string(var)
>   } else {
>     static assert(false);
>   }
>   // do something with myVar
> }
>

Why not this?
void foo(T)(T var)
{
    auto myVar = var.to!string;
    //do something with myVar string
}

On 7/1/13 1:45 PM, John Colvin wrote:
> T)(T var)
> {
>      auto myVar = var.to!string;
>      //do something with myVar string
> }

Ah, that's also ok. But then you have to remember to use myVar instead of var.

On Monday, 1 July 2013 at 16:15:04 UTC, Walter Bright wrote:
> On 7/1/2013 6:39 AM, Ary Borenszweig wrote:
>>> This is not what I am talking about and it seems quite dangerous to have
>>> one variable name masquerade as multiple variables.
>>
>> Why dangerous?
>
> D already disallows:
>
>     int x;
>     {   float x;
>     }
>
> as an error-prone construct, so why should it allow:
>
>     int x;
>     float x;
>
> ?
>
I'm not "proposing" this. There is only one variable.

I think there is big confusion in what I'm "suggesting"(it's not a proposal because I don't expect anyone to take the time to prove its validity... and you can't know how useful it could be if you don't have any way to test it out).

It's two distinctly different concepts when you allow a "multi-variable" and one that can be "up-typed" by inference(the compiler automatically "up-types").



>> I've been programming in Ruby for quite a time and never found it
>> to be a problem, but an advantage.
>
> What advantage? Does Ruby have a shortage of names for variables? (Early versions of BASIC only allowed variable names with one letter, leading to some pretty awful workarounds.)
>
>
>> Show me an example where this is dangerous (the pointer example gave by Walter
>> is not valid anymore since it has a fix).
>
> I'm actually rather sure that one can come up with rule after rule to 'fix' each issue, but good luck with trying to fit all those rules into some sort of comprehensible framework. Consider what happened to C++ when they tried to fit new things into the overloading rules - the rules now span multiple pages of pretty arbitrary rules, and practically nobody understands the whole. What people do is randomly try things until it seems to do the right thing for them, and then they move on.
>
> And all this for what - nobody has come up with a significant reason to support this proposal. I see post after post in this thread trying to make it work, and nothing about what problem it solves.

I'm more interested in a true counterexample where my concept(which I've not seen in any language before) results in an invalid context.... and not a naive example that uses a half baked implementation of the algorithm(which I've already outlined). Just because someone comes up with an example and says "this will produce a non-termination" doesn't mean it will except in the most naive implementations.

The problem is when such a "idea" is present you get people who are automatically against it for various irrational fears and they won't take any serious look at it to see if it has any merit...  If you jump to the conclusion that something is useless without any real thought on it then it obviously is... but the same type of mentality has been used to "prove" just about anything was useless at one time or another. (and if that mentality ruled we'd still be using 640k of memory)


I have a very basic question for you and would like a simple answer:

In some programming languages, one can do the following type of code:

var x; // x is some type of variable that holds data. It's type is not statically defined and can change at run time.
x = 3; // x holds some type of number... usually an integer but the language may store all numbers as doubles or even strings.

now, suppose we have a program that contains essentially the following:

var x;
x = 3;

Is it possible that the compiler can optimize such code to find the least amount of data to represent x without issue? Yes or no? Is this a good thing? Yes or no? (I don't need and don't want any explanation)

(the above example is at the heart of the matter... regardless if it is probably a valid semantic in D or easily to implement(since no one knows and most don't care because they think it won't benefit them(just like how bill gates thought all everyone needed was 640k)))

On 7/1/2013 9:46 AM, Ary Borenszweig wrote:
> On 7/1/13 1:45 PM, John Colvin wrote:
>> T)(T var)
>> {
>>      auto myVar = var.to!string;
>>      //do something with myVar string
>> }
>
> Ah, that's also ok. But then you have to remember to use myVar instead of var.

Heck, why bother with different variable names at all? We can just use x for all variables, t for all types, and f for all functions!

t f(t x)
{   t x;

    t x = x & 0xFF;
    if (x == x)
        x = 0;
    else if ((x & 0xFFFD00) == 0x0F3800)
        x = x[(x >> 8) & 0xFF];
    else if ((x & 0xFF00) == 0x0F00)
        x = x[x];
    else
        x = x[x];
    return x & x;
}

Sorry for the sarcasm, but I just don't get the notion that it's a burden to use a different name for a variable that has a different type and a different purpose. I'd go further and say it is a bad practice to use the same name for such.

On Monday, 1 July 2013 at 16:46:57 UTC, Ary Borenszweig wrote:
> On 7/1/13 1:45 PM, John Colvin wrote:
>> T)(T var)
>> {
>>     auto myVar = var.to!string;
>>     //do something with myVar string
>> }
>
> Ah, that's also ok. But then you have to remember to use myVar instead of var.

Personally I like the explicit use of a new variable. If you're changing the type of a variable then you want it to be explicit. I spend far too many hours a month chasing down accidental type changes in python.

A "convenience" feature is only a feature if it helps *stop* you shooting yourself in the foot, not if it actively encourages it.

auto a;

//loads of code, with function calls to all sorts of unfamiliar libraries

//do something with a.

How do I know what type a is to work with? I have to either read and understand all the code in between, try and write something generic, or put a pragma(msg,  ...) in to show it for me. Either way I have to pray that nobody changes it.

On 07/01/2013 06:15 PM, Walter Bright wrote:
> On 7/1/2013 6:39 AM, Ary Borenszweig wrote:
>>> This is not what I am talking about and it seems quite dangerous to have
>>> one variable name masquerade as multiple variables.
>>
>> Why dangerous?
>
> D already disallows:
>
>      int x;
>      {   float x;
>      }
>
> as an error-prone construct, ...

module b;
int x;

module a;

void main(){
    int x;
    {
        import b;
        x = 2;
    }
    import std.stdio;
    writeln(x); // prints 0
}

On Monday, 1 July 2013 at 16:46:57 UTC, Ary Borenszweig wrote:
> Ah, that's also ok. But then you have to remember to use myVar instead of var.

I have wanted to remove a variable from scope before. I think it would be kinda cool if we could do something like __undefine(x), and subsequent uses of it would be an error. (It could also prohibit redeclaration of it if we wanted.)

D doesn't have that, but we can get reasonably close using other functions when we change param types (just forward it to the other overload) and functions and/or scopes for local variables:

void foo() {
   { int a; /* use a */ }
   // a is now gone, so you don't accidentally use it later in the function
}

Don't feed the troll.

On 7/1/2013 9:57 AM, JS wrote:
> The problem is when such a "idea" is present you get people who are
> automatically against it for various irrational fears and they won't take any
> serious look at it to see if it has any merit...  If you jump to the conclusion
> that something is useless without any real thought on it then it obviously is...
> but the same type of mentality has been used to "prove" just about anything was
> useless at one time or another.

It's up to you to demonstrate your idea has merit. Throwing ideas out and asking others to find the merit for you is not going to work. It's even worse when you insult them for not finding the merit that you didn't find.

Once you demonstrate merit then go about finding ways to make it work. Not the other way around.

There are famous cases in business history where a solution was found before anyone identified a problem - 3M's not-very-sticky adhesive that was eventually turned into the hugely profitable postit notes is an example - but it languished for nearly a decade before someone thought of a use for it. And 3M certainly didn't productize it before the problem was discovered.

On Monday, 1 July 2013 at 16:57:53 UTC, JS wrote:
> (the above example is at the heart of the matter... regardless if it is probably a valid semantic in D or easily to implement(since no one knows and most don't care because they think it won't benefit them(just like how bill gates thought all everyone needed was 640k)))

For the record, this quote is plain wrong : https://groups.google.com/forum/#!msg/alt.folklore.computers/mpjS-h4jpD8/9DW_VQVLzpkJ

But if you one very stupid one, I declared in the late 90s that a phone with a tactile screen on its whole surface was a stupid idea and that it would never work.

I you look hard enough, I guess we all said the most stupid thing at some point. We got to admit it and not repeat the mistake.