class A
{
     auto n;

     void foo(auto x) { ... }
}

int main()
{
    scope a = new A;
    scope b = new A;

    a.foo(1); // this means A has a member function "void foo(int
x) {...}"
    a.foo(1.1); // this means A has another member function "void
foo(double x) {...}"
    // compiler will automatically build two versions of function
"foo"

    b.foo("Hello"); // this means A has a third "foo" member function with parameter "string []"

    a.n = 1.3; // class A(type 1), which has a data member double n;
    b.n = 1 // class A(type 2), which has a data member int n;

    /*
    So there are two class type A1 and A2

    class A1
   {
       double n;

        void foo(int x) { ... }
   }

    class A2
   {
       int n;

        void foo(double x) { ... }
   }

   */

}

>
> The trouble with this is that sometimes people will use a type without an identifier in order to indicate that the parameter is not used:
>
> auto Foo(int, unsigned x)
>
> But also note that for lambdas, D does allow the form you suggest, as there weren't backwards compatibility issues with it.

I know there is no perfect things in the world, But I hope that D can approach the perfect,
Because I really love this language!

Thanks for inventing this beautiful language:)

I've brought this up on here awhile ago, and many people seemed to be against it. Which I don't agree with, since the ambiguities it creates are easily addressed (from a design perspective at least) and only exist so that C-style code is usable within D. It could work like:

   auto func(a, b)     // auto func(A, B)(A a, B b)
   auto func(int a, b) // auto func(B)(int a, B b)
   auto func(int ?)    // C-style: auto func(int)

Or...

   auto func(auto a, auto b) // like C++14

I mean honestly, who's hand-writing a bunch of functions with nameless params in real D code? Sure it's used for linking to C, which is semi-common, but I think having the much cleaner syntax available to "actual" D code makes more sense that not having it solely for linking-to-C-in-familiar-C-style reasons.

On 2013-08-03 00:51:19 +0000, F i L said:

> I've brought this up on here awhile ago, and many people seemed to be against it. Which I don't agree with, since the ambiguities it creates are easily addressed (from a design perspective at least) and only exist so that C-style code is usable within D. It could work like:
> 
>     auto func(a, b)     // auto func(A, B)(A a, B b)
>     auto func(int a, b) // auto func(B)(int a, B b)
>     auto func(int ?)    // C-style: auto func(int)
> 
> Or...
> 
>     auto func(auto a, auto b) // like C++14
> 
> I mean honestly, who's hand-writing a bunch of functions with nameless params in real D code? Sure it's used for linking to C, which is semi-common, but I think having the much cleaner syntax available to "actual" D code makes more sense that not having it solely for linking-to-C-in-familiar-C-style reasons.

The converse question is who's hand-writing a bunch of functions that don't need their arguments' types in any way (for constraints or otherwise). There are very few functions that really apply to all types. It's possible that by allowing auto parameter types we encourage a sloppy style.

Andrei

> I've brought this up on here awhile ago, and many people seemed to be against it. Which I don't agree with, since the ambiguities it creates are easily addressed (from a design perspective at least) and only exist so that C-style code is usable within D. It could work like:
>
>    auto func(a, b)     // auto func(A, B)(A a, B b)
>    auto func(int a, b) // auto func(B)(int a, B b)
>    auto func(int ?)    // C-style: auto func(int)

 I like it!

On Saturday, 3 August 2013 at 00:51:21 UTC, F i L wrote:
> I've brought this up on here awhile ago, and many people seemed to be against it. Which I don't agree with, since the ambiguities it creates are easily addressed (from a design perspective at least) and only exist so that C-style code is usable within D. It could work like:
>
>    auto func(a, b)     // auto func(A, B)(A a, B b)
>    auto func(int a, b) // auto func(B)(int a, B b)
>    auto func(int ?)    // C-style: auto func(int)

Regardless of the existing merits, that would be a (massive) breaking change, and as mentioned, it brings nothing we couldn't do before...

> Or...
>
>    auto func(auto a, auto b) // like C++14
>
> I mean honestly, who's hand-writing a bunch of functions with nameless params in real D code? Sure it's used for linking to C, which is semi-common, but I think having the much cleaner syntax available to "actual" D code makes more sense that not having it solely for linking-to-C-in-familiar-C-style reasons.

Anytime I write the body of a function that doesn't use one of its args, I keep the  arg name empty. This implicitly documents that the arg is unused. Many people do this in C++ too, since msvc will flag you for not doing it anyways. So your answer your question: "who's hand-writing a bunch of functions with  nameless params in real D code": Lot's of people, including in Phobos.

monarch_dodra wrote:
> Regardless of the existing merits, that would be a (massive) breaking change, and as mentioned, it brings nothing we couldn't do before...

Sure, but not if you do it like my second example:

   auto func(auto a, auto b) // like C++14

That doesn't break anything, right?


> Anytime I write the body of a function that doesn't use one of its args, I keep the  arg name empty. This implicitly documents that the arg is unused. Many people do this in C++ too, since msvc will flag you for not doing it anyways. So your answer your question: "who's hand-writing a bunch of functions with  nameless params in real D code": Lot's of people, including in Phobos.

Fair enough. However, using 'auto' like above would allow cleaner syntax without getting in your way I think.

On Saturday, 3 August 2013 at 08:59:41 UTC, F i L wrote:
> monarch_dodra wrote:
>> Regardless of the existing merits, that would be a (massive) breaking change, and as mentioned, it brings nothing we couldn't do before...
>
> Sure, but not if you do it like my second example:
>
>    auto func(auto a, auto b) // like C++14
>
> That doesn't break anything, right?

I'm not sure auto is the best choice of keywords, given potential clashes with auto ref:

What if you want to pass a by ref?
auto func(auto ref a, auto ref b) ?
auto func(ref auto a, ref auto b) ?

What if you want to pass them by *auto* ref?
auto func(auto auto ref a, auto auto ref b) ?
auto func(auto ref auto a, auto ref auto b) ?

At this point, I'd really prefer just seeing classic template syntax...

On Friday, 2 August 2013 at 20:34:04 UTC, SteveGuo wrote:
> I'm not an expert on programming language, if I made a naive issue, just forgive me:p
>
> Can we declare a template function like this?
>
> auto Add(a, b) // Note a, b do not have type, that means a and b use template type
> {
>     return a + b;
> }
>
> auto Sub(a, int b) // a uses template type, b is fixed to int
> {
>     return a - b;
> }
>
> When we call the function,
>
> Add(1, 2); // deduced to be Add(int, int);
> Add(1.5, 2.3); // deduced to be Add(double, double);
> Add(1.5, "Hello"); // compiler error!
>
> Sub(1.5, 1); // deduced to be Add(double, int);
> Sub(1, 1.1); // deduced to be Add(int, int); compiler error, double can not converted to int automatically

I prefer the current template syntax, it's nice to want to reduce the number of keywords/syntax, but generally to understand the code it's better for productivity to have something really explicit.

When you read an old code or something written by someone else it's really important to see at the first sight what the code is intended to do.

auto keyword hide too much how variables are used, is it ref? const?,...

On Saturday, 3 August 2013 at 01:15:48 UTC, Andrei Alexandrescu wrote:
> On 2013-08-03 00:51:19 +0000, F i L said:
>
>> I've brought this up on here awhile ago, and many people seemed to be against it. Which I don't agree with, since the ambiguities it creates are easily addressed (from a design perspective at least) and only exist so that C-style code is usable within D. It could work like:
>> 
>>    auto func(a, b)     // auto func(A, B)(A a, B b)
>>    auto func(int a, b) // auto func(B)(int a, B b)
>>    auto func(int ?)    // C-style: auto func(int)
>> 
>> Or...
>> 
>>    auto func(auto a, auto b) // like C++14
>> 
>> I mean honestly, who's hand-writing a bunch of functions with nameless params in real D code? Sure it's used for linking to C, which is semi-common, but I think having the much cleaner syntax available to "actual" D code makes more sense that not having it solely for linking-to-C-in-familiar-C-style reasons.
>
> The converse question is who's hand-writing a bunch of functions that don't need their arguments' types in any way (for constraints or otherwise). There are very few functions that really apply to all types. It's possible that by allowing auto parameter types we encourage a sloppy style.
>
> Andrei

The existence of template restrictions and the swathes of different things in std.traits and elsewhere really persuaded me to think about the requirements of my templates. Having to spell it out a bit is a good thing.
In short: I agree.