Reply to Walter,

> How could I do partial ordering if one constraint expression accepts
> only "odd" integers? 

you wouldn't, but rather ignore that clause and mine the constraints that you would use out of the expression (see my post for details)

Reply to Aarti_pl,

> template(T if typeof(T.init + T.init) == T)

who ever said T + T == T? What if that is not needed?

aarti_pl wrote:
> Walter Bright pisze:
>> aarti_pl wrote:
>>> How would you do currently in D?
>>
>> template (T) if (T.init + T.init)
>> {
>> }
> 
> in D1.0
> 
> template(T if typeof(T.init + T.init) == T)

D1 is closed to such enhancements, in any case, the ==T part is wrong. byte+byte==int, for example.


> or in D2.0
> 
> template(T if __traits(compiles, T.init + T.init))
> 
> I could mess something in above examples, but as you can see, getting it to work is not a problem of my syntax for templates.

Ok, but it's hard to see why it is better.

BCS wrote:
> Reply to Walter,
> 
>> How could I do partial ordering if one constraint expression accepts
>> only "odd" integers? 
> 
> you wouldn't, but rather ignore that clause and mine the constraints that you would use out of the expression (see my post for details)

Then aren't things getting just as, or even more, complicated?

My big beef with Concepts is it was 40 pages of specification. D's constraints are a couple lines of specification. To replace them, it needs to be significantly simpler, not just different.

BLS wrote:
> Thanks for taking the time to answer ; But the question remains the same : _Why_ ? Constraints /have/ to use a completely different approach ?
> 
> ("more intuitive than" is not ..ahem.. is not a good enough reason)

I think it is a very good reason. Of course, we can argue about if it is actually intuitive or not.

BCS pisze:
> Reply to Aarti_pl,
> 
>> template(T if typeof(T.init + T.init) == T)
> 
> who ever said T + T == T? What if that is not needed?

That is the only way to do it in D1 AFAIK. In D2 you have __traits(compile, ).

But before you get into discussion, please read my point made to Walter:  possibility to get such a functionality is not and SHOULD NOT be connected with template instantiations, but rather with proper compile time reflection.

BR
Marcin Kuszczak
(aarti_pl)

Reply to Walter,

> BCS wrote:
> 
>> Reply to Walter,
>> 
>>> How could I do partial ordering if one constraint expression accepts
>>> only "odd" integers?
>>> 
>> you wouldn't, but rather ignore that clause and mine the constraints
>> that you would use out of the expression (see my post for details)
>> 
> Then aren't things getting just as, or even more, complicated?
> 

99% of the time nobody needs to worry about how exactly partial ordering works. 90% of the time* people don't need to worry about putting constraints in the if clause or in the argument list.

I'd much rather have more complexity on the thing I need 1% of the time than the thing I need 10%. And the the rules I proposed are arguably simpler than the partial ordering bit that it inherits wholesale from the current solution so it might not even be the hard part.

On top of that, they may also alow for fewer cases wher the partial ordering even comes into play.

*87.6% of statistics are made up on the spot.

Walter Bright pisze:
> aarti_pl wrote:
>> Walter Bright pisze:
>>> aarti_pl wrote:
>>>> How would you do currently in D?
>>>
>>> template (T) if (T.init + T.init)
>>> {
>>> }
>>
>> in D1.0
>>
>> template(T if typeof(T.init + T.init) == T)
> 
> D1 is closed to such enhancements, in any case, the ==T part is wrong. byte+byte==int, for example.

I don't want to dive into it. It has nothing to do with origins of this discussion. You asked - I answered :-)

> 
>> or in D2.0
>>
>> template(T if __traits(compiles, T.init + T.init))
>>
>> I could mess something in above examples, but as you can see, getting it to work is not a problem of my syntax for templates.
> 
> Ok, but it's hard to see why it is better.

So you suggest that advantage of "if constraint" is possibility to get compile time information about types?

In my opinion they are completely different concepts and they should be separated. In most cases messing two concepts together is wrong.

Advantages of my syntax are enumerated in my proposal. I will not repeat them here again.

BR
Marcin Kuszczak
(aarti_pl)

Walter Bright wrote:
> BLS wrote:
>> Thanks for taking the time to answer ; But the question remains the same : _Why_ ? Constraints /have/ to use a completely different approach ?
>>
>> ("more intuitive than" is not ..ahem.. is not a good enough reason)
> 
> I think it is a very good reason. Of course, we can argue about if it is actually intuitive or not.

ok. but that's only  eye candy, no ?

The more I think about what constraints could do, the more I think we should have a third and forth look on 'em.

I think with constraints we hold the key for meta/meta programming in our hands.... otherwise I would not insist like I do now.

BLS:
> >> bearophile brings in several times Scala/OCAML like pattern matching. Why not using that for constraints ?
> > 
> > I have no idea how that works, though Bartosz has been looking into it.
> 
> O well, I am pretty sure that bearophile is willing to give you any information you need  :)

Pattern matching is handy and it can be powerful, for example I've seen OCaML code that uses it to implement a AVL search tree in about 15 lines of code. But probably it also adds lot of complexity to a language like D, so there are more important things to add to D2 now (like good concurrency).

Bye,
bearophile