View mode: basic / threaded / horizontal-split · Log in · Help
November 26, 2012
Re: Help!
On 26 November 2012 21:15, David Nadlinger <see@klickverbot.at> wrote:

> On Monday, 26 November 2012 at 17:18:28 UTC, Manu wrote:
>
>> the supplementary question is, how do I then
>> discover if bar[0] is a symbol or not? I can't see any traits to test for
>> builtin types...
>>
>
> Depends on your definition of symbol, but if you mean symbol as in "an
> alias parameter accepts it", the obvious solution is:
>
> ---
> template isSymbol(alias S) {
>   enum isSymbol = true;
> }
>
> template isSymbol(S) {
>   enum isSymbol = false;
> }
> ---
>
> David
>

struct S {}
isSymbol!S <- why isn't this ambiguous? both templates match that equally,
why would it prefer the alias one?
November 26, 2012
Re: Help!
On Monday, 26 November 2012 at 19:43:18 UTC, Manu wrote:
> struct S {}
> isSymbol!S <- why isn't this ambiguous? both templates match 
> that equally,
> why would it prefer the alias one?

I don't know OTOH if it's documented or not, but that's just how 
template resolution rules work. But anyway, Timon has just 
pointed out that Walter isn't opposed to the change anymore. It's 
now considered a bug:

http://d.puremagic.com/issues/show_bug.cgi?id=9029

David
November 26, 2012
Re: Help!
On 11/27/2012 6:43 AM, Manu wrote:
> struct S {}
> isSymbol!S <- why isn't this ambiguous? both templates match that
> equally, why would it prefer the alias one?

When two templates match an argument list, the compiler picks the most 
specialized match.
November 26, 2012
Re: Help!
On Monday, 26 November 2012 at 19:54:46 UTC, Walter Bright wrote:
> On 11/27/2012 6:43 AM, Manu wrote:
>> struct S {}
>> isSymbol!S <- why isn't this ambiguous? both templates match 
>> that
>> equally, why would it prefer the alias one?
>
> When two templates match an argument list, the compiler picks 
> the most specialized match.

Yes, but this requires that "alias T" and "T" are (totally) 
ordered, which is not clear, a priori.

David
November 26, 2012
Re: Help!
On 11/27/2012 5:52 AM, David Nadlinger wrote:
> I agree, and if I remember previous discussions on the subject
> correctly, it seems like only Walter is in favor of upholding the
> current restrictions of "alias" parameters to symbols. I simply do not
> see a point in pushing compiler implementation details on the user like
> that – for the programmer, a type is a type is a type…
>
> Walter, do you have an example of a situation where the alias parameter
> restriction would be beneficial?  (for the D code involved, I don't mean
> the few lines of code avoided in the compiler)

In any case, it will break a great deal of existing code to change  that 
behavior.
November 26, 2012
Re: Help!
On 11/26/2012 08:59 PM, Walter Bright wrote:
> On 11/27/2012 5:52 AM, David Nadlinger wrote:
>> I agree, and if I remember previous discussions on the subject
>> correctly, it seems like only Walter is in favor of upholding the
>> current restrictions of "alias" parameters to symbols. I simply do not
>> see a point in pushing compiler implementation details on the user like
>> that – for the programmer, a type is a type is a type…
>>
>> Walter, do you have an example of a situation where the alias parameter
>> restriction would be beneficial?  (for the D code involved, I don't mean
>> the few lines of code avoided in the compiler)
>
> In any case, it will break a great deal of existing code to change  that
> behavior.
>

Well, no, it wont. Why do you think it will?
November 26, 2012
Re: Help!
On 11/26/2012 08:58 PM, David Nadlinger wrote:
> On Monday, 26 November 2012 at 19:54:46 UTC, Walter Bright wrote:
>> On 11/27/2012 6:43 AM, Manu wrote:
>>> struct S {}
>>> isSymbol!S <- why isn't this ambiguous? both templates match that
>>> equally, why would it prefer the alias one?
>>
>> When two templates match an argument list, the compiler picks the most
>> specialized match.
>
> Yes, but this requires that "alias T" and "T" are (totally) ordered,
> which is not clear, a priori.
>
> David

Yes, not every alias argument is a valid type, so why would the alias be 
considered more specialized?
November 27, 2012
Re: Help!
On 11/27/2012 7:09 AM, Timon Gehr wrote:
>> In any case, it will break a great deal of existing code to change  that
>> behavior.
> Well, no, it wont. Why do you think it will?

Because (as this thread shows) a lot of template code has been built 
around subtle things like this.
November 27, 2012
Re: Help!
On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:
> On 11/27/2012 5:52 AM, David Nadlinger wrote:
>> I agree, and if I remember previous discussions on the subject
>> correctly, it seems like only Walter is in favor of upholding 
>> the
>> current restrictions of "alias" parameters to symbols. I 
>> simply do not
>> see a point in pushing compiler implementation details on the 
>> user like
>> that – for the programmer, a type is a type is a type…
>>
>> Walter, do you have an example of a situation where the alias 
>> parameter
>> restriction would be beneficial?  (for the D code involved, I 
>> don't mean
>> the few lines of code avoided in the compiler)
>
> In any case, it will break a great deal of existing code to 
> change  that behavior.

The discussed issue is one of those inconsistencies that make 
people struggle when using D. D's main selling point is rich 
metaprogramming. Others are rapidly catching up in the field of 
expressive native languages. If we set these early design 
decisions in stone, it means we will not be able to compete with 
them. And besides, are there many big proprietary D2 codebases 
that you afraid? I doubt there are. And Manu actually represents 
people who are willing to work on one, but are held off by these 
issues. Open source projects however will be easily fixable, and 
people using D will actually welcome these positive changes.
November 27, 2012
Re: Help!
On 27 November 2012 19:47, Eldar Insafutdinov <e.insafutdinov@gmail.com>wrote:

> On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:
>
>> On 11/27/2012 5:52 AM, David Nadlinger wrote:
>>
>>> I agree, and if I remember previous discussions on the subject
>>> correctly, it seems like only Walter is in favor of upholding the
>>> current restrictions of "alias" parameters to symbols. I simply do not
>>> see a point in pushing compiler implementation details on the user like
>>> that – for the programmer, a type is a type is a type…
>>>
>>> Walter, do you have an example of a situation where the alias parameter
>>> restriction would be beneficial?  (for the D code involved, I don't mean
>>> the few lines of code avoided in the compiler)
>>>
>>
>> In any case, it will break a great deal of existing code to change  that
>> behavior.
>>
>
> The discussed issue is one of those inconsistencies that make people
> struggle when using D. D's main selling point is rich metaprogramming.
> Others are rapidly catching up in the field of expressive native languages.
> If we set these early design decisions in stone, it means we will not be
> able to compete with them. And besides, are there many big proprietary D2
> codebases that you afraid? I doubt there are. And Manu actually represents
> people who are willing to work on one, but are held off by these issues.
> Open source projects however will be easily fixable, and people using D
> will actually welcome these positive changes.
>

I feel this sentiment every day.
I'm more than happy to receive breaking changes that make the language
tidier and more consistent. I'll happily take the time to keep our codebase
up to date.
As a commercial entity, I'd rather see the language assert breaking changes
that make the language feel more solid/robust than to continue implementing
ugly hacks/workarounds for sake of not breaking our codebase.
Surely it's better to sweep the foundations while users range in the 4-5
digits, than the 6-7 digits (which is surely the hope here)?

There is a lot of nasty clutter/mess in the lowest level of D (and the
useful parts should generally be wrapped up in std.traits anyway) ;)
Just look through std.traits at some of the wild approaches required to
discover certain properties about things. Our code is equally riddled with
stuff like that, though it's gotten a lot better in the past 2 months!
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home