Menu
Search

Forums

Forum Index

May 03, 2022
Gravatar of ElfstonePosted by Elfstone
in reply to Loara		Reply
Elfstone
Gravatar of Elfstone
Posted in reply to Loara


Reply

On Monday, 2 May 2022 at 16:29:05 UTC, Loara wrote:

>

On Sunday, 1 May 2022 at 03:57:12 UTC, Elfstone wrote:

>

[...]

Template deduction for aliased function parameter is a very tricky argument and it's not so simple to handle in certain cases. Consider for example this code:

    template MyAlias(T){
      alias MyAlias = int;
    }

    T simp(T)(MyAlias!T val){
      return T.init;
    }

    int main(){
      simp(3);//Impossible to deduce T
      simp( cast(MyAlias!string) 4);//Also invalid since MyAlias!string is exactly int
      simp!string(4);//Ok, no parameter deduction
    }

Instead to use aliases it's better (both in D and in C++) to use constraints/concepts.

Yeah, I understand some cases are impossible, and to be avoided. I believe your example is also impossible in C++, but it's better the compiler do its job when it's totally possible - needless to say, C++ compilers can deduce my dot.
Constraints/Concepts are useful, but what's needed here is a literal alias. There's no ambiguity, no extra template parameters introduced in the declaration.

May 03, 2022
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to Elfstone		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to Elfstone


Reply

On Tuesday, 3 May 2022 at 06:20:53 UTC, Elfstone wrote:

>

Yeah, I understand some cases are impossible, and to be avoided. I believe your example is also impossible in C++, but it's better the compiler do its job when it's totally possible - needless to say, C++ compilers can deduce my dot.
Constraints/Concepts are useful, but what's needed here is a literal alias. There's no ambiguity, no extra template parameters introduced in the declaration.

I haven't read all of the posts in this thread, but D in general doesn't do proper type unification so template composition in D is not as useful as in C++. It is discussed here:

https://forum.dlang.org/post/rt26mu$2c6q$1@digitalmars.com

As you see, someone will have to write a DIP to fix this bug, as the language authors don't consider it a bug, but an enhancement.

I've never got around to do it myself, but if you or someone else write the DIP, then I would like to help out with the wording if needed.

May 03, 2022
Gravatar of LoaraPosted by Loara
in reply to JG		Reply
Loara
Gravatar of Loara
Posted in reply to JG


Reply

On Monday, 2 May 2022 at 17:21:53 UTC, JG wrote:

>

On Monday, 2 May 2022 at 16:29:05 UTC, Loara wrote:

>

On Sunday, 1 May 2022 at 03:57:12 UTC, Elfstone wrote:

>

[...]

Template deduction for aliased function parameter is a very tricky argument and it's not so simple to handle in certain cases. Consider for example this code:

    template MyAlias(T){
      alias MyAlias = int;
    }

    T simp(T)(MyAlias!T val){
      return T.init;
    }

    int main(){
      simp(3);//Impossible to deduce T
      simp( cast(MyAlias!string) 4);//Also invalid since MyAlias!string is exactly int
      simp!string(4);//Ok, no parameter deduction
    }

I don't really see what your example is trying to show. This also doesn't work,
and in my mind should be equivalent:

T simp(T)(int val) {
    return T.init;
}

int main() {
    simp(3);//Impossible to deduce T
}

Yeah I know, but I'm trying to show that allowing aliased templated function parameters will bring many bugs in user code, especially with aliases that alias another aliased declarations. I think using typedefs and template constraints is simpler and make your code more readable too.

May 03, 2022
Gravatar of LoaraPosted by Loara
in reply to Stanislav Blinov		Reply
Loara
Gravatar of Loara
Posted in reply to Stanislav Blinov


Reply

On Monday, 2 May 2022 at 19:17:19 UTC, Stanislav Blinov wrote:

>

On Monday, 2 May 2022 at 16:29:05 UTC, Loara wrote:

>

Template deduction for aliased function parameter is a very tricky argument and it's not so simple to handle in certain cases. Consider for example this code:

    template MyAlias(T){
      alias MyAlias = int;
    }

    T simp(T)(MyAlias!T val){
      return T.init;
    }

    int main(){
      simp(3);//Impossible to deduce T

Why? That's the issue. It is very possible to deduce T here. Compiler just isn't trying. The function takes an int. Doesn't take a rocket scientist to figure that one out.

No, an alias is not a type and it'll be immediately substitutedwith the aliased symbol. You should use typedefs in order to create a different type.

May 03, 2022
Gravatar of Ali ÇehreliPosted by Ali Çehreli
in reply to Stanislav Blinov		Reply
Ali Çehreli
Gravatar of Ali Çehreli
Posted in reply to Stanislav Blinov


Reply
	On 5/2/22 13:36, Stanislav Blinov wrote:

>> That's fine because D does not promise to solve such problems. It
>> follows simple deduction rules.
>
> Words, dear guru. Words have a meaning. It is very possible to deduce
> here (note the premise). D just isn't trying. That's what I said. You
> can say "it doesn't promise". Doesn't exactly change the meaning, does
> it? :)

What I mean is, problem solving the way you expect is not in D's charter.

>> > The function takes an int.
>>
>> How would the solution be? Wouldn't the compiler have to parse all
>> accessible template bodies to figure out which ones fit?
>
> Err... yes? That's what it *is* doing already, for all templates.

No, the compiler does not parse all templates. Only the ones that needs instantiation.

>> Imagine the following two other templates:
>>
>> template YourAlias(T) {
>>   alias YourAlias = int;  // Is it this one?
>> }
>>
>> template HerAlias(T) {
>>   // ...
>>   alias HerAlias = HisAlias!SomeNameInThisScope;  // Or thi?
>> }
>
> No. HerAlias and YourAlias are different symbols.

You are right. I confused myself there but it is not that different when we stay with MyAlias alone. I am changing 'int' to YourAlias!T:

  template MyAlias(T){
    alias MyAlias = YourAlias!T;
  }

Do you still expect the compiler to dig into YourAlias and solve a problem to see whether YourAlias can be the same as aliasing 'int'? Would that enough trying by the compiler? If not, where should the compiler stop? In any case, that is not what D is. That's what I meant.

Not being even a junior guru, I don't know what categories of programming languages do that. Declarative? Logic? All I know is D is not among them.

>> The compiler would have to solve this problem by digging into
>> HisAlias's SomeNameInThisScope instantiation as well. As far as know,
>> the D language does not work that way. Prolog and friends perhaps?
>
> Nope. MyAlias is an alias. A template alias, but an alias nonetheless.
> It should be resolved prior to trying the overloads.

Not going to happen.

>> > Doesn't take a rocket
>> > scientist to figure that one out.
>>
>> I think this is one of those cases where it is easier for a human.
>> Although, I think I would have difficulty if there were more than one
>> template parameter.
>
> That's what we have compilers for.

We also have NP-completeness.

>> > I might as well forego the templates and
>> > just write explicit overloads. At which point I would
>> question why use
>> > templates at all.
>>
>> Templates allow single implementations to work for many types,
>> manifest constants, aliases, etc. I wouldn't want to write (or
>> mix-in?) sort() for MyType. Templates are wonderful and their
>> implementation in D is refreshing.
>
> It is, until is isn't. Question du jeour is one of those.

No, the question is whether D is in a category of programming languages that it isn't.

Ali
May 03, 2022
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to Ali Çehreli		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to Ali Çehreli


Reply

On Tuesday, 3 May 2022 at 15:41:08 UTC, Ali Çehreli wrote:

>

We also have NP-completeness.

Ok, so C++ has similar limitations when you have a template with an unknown parameter in a function parameter, but is this because it would be NPC? Also, do we know that it cannot be resolved for the typical case in reasonable time? Maybe one can add constraints and heuristics that keeps it reasonable?

>

No, the question is whether D is in a category of programming languages that it isn't.

Fair enough, but type unification needs to be done differently anyway, just to support aliases being recognized in function calls. Why not look at what is possible before going there? Certainly, having something more expressive than C++ would not be a bad thing?

May 04, 2022
Gravatar of baussPosted by bauss
in reply to Ola Fosheim Grøstad		Reply
bauss
Gravatar of bauss
Posted in reply to Ola Fosheim Grøstad


Reply

On Tuesday, 3 May 2022 at 07:11:48 UTC, Ola Fosheim Grøstad wrote:

>

As you see, someone will have to write a DIP to fix this bug, as the language authors don't consider it a bug, but an enhancement.

I don't believe those two words are mutually exclusive.

It can be a bug and an enhancement.

But to deny that this is a bug is just being lazy.

May 04, 2022
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to bauss		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to bauss


Reply

On Wednesday, 4 May 2022 at 10:15:18 UTC, bauss wrote:

>

It can be a bug and an enhancement.

Alright, but we need a DIP to get the enhancement which can be in. :-) I don't think anything will improve without one.

I would assume that C++ template resolution is O(N), so I am not as pessimistic as Ali, but I could be wrong.

« First   ‹ Prev
1 2 3
Next ›   Last »