October 05, 2008
On Sat, 04 Oct 2008 23:50:47 -0500, Andrei Alexandrescu wrote:

> Alexander Pánek wrote:
>> Andrei Alexandrescu wrote:
[..]
> I believe the clear distinction is not only unnecessary, but undesirable. We should actively fight against it.
> 
> Andrei

I also believe the distinction is unnecessary.


About the exclamation mark vs dot.
I believe the dot would be worse:

- code completion in IDEs get confused

- '!' may be an unary operator, but '.' is also some kind of operator that is often used otherwise.

- changing the syntax always hurts, even if it might be easy to do so.
  The justification should be strong.

October 05, 2008
Christopher Wright wrote:
> Derek Parnell wrote:
>> On Sun, 05 Oct 2008 00:12:06 -0500, Andrei Alexandrescu wrote:
>>
>>> Word followed by exclamation mark. Our brains are wired to interpret that as an exclamation. If it's frequent enough in code, it becomes really jarring.
>>
>> I too find the form ...
>>
>>    Template!(arg1, arg2, arg3)
>>
>> a bit uncomfortable.
>>
>> If we need to visually distinguish templates (compile-time constructs) from
>> run-time constructs, I would advocate a totally different style all
>> together. Maybe something more along the lines of the DDoc style ...
>>
>>   @(Template arg1 arg2 arg3)
>>
>> Nested it would look like ...
>>
>>   @(This @(That @(TheOther crap)))
>>
>> But I'm being too left-field, I suspect.
>>
> 
> It's actually a lot quicker to type @( than !( -- it's reasonable for me to use the same shift key for the @ and the (. So I wouldn't much complain about this, except for the ugliness. And !( is also ugly.

Since I only use the left shift key, it’s equally quick to type for me. I don’t see much point in basing syntax on how fast you can type. Also, on German keyboard layouts (and I think lots of other non-us based, European layouts), the @ is at Compose + q, which is pretty uncomfortable.
October 05, 2008
Steven Schveighoffer wrote:
> If this change is implemented, Walter is going to have a hard time arguing that it's not worth changing invariant to immutable...

Speaking of which... guess what he just did :o).

Andrei
October 05, 2008
On Sun, 05 Oct 2008 17:31:14 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Steven Schveighoffer wrote:
>> If this change is implemented, Walter is going to have a hard time arguing that it's not worth changing invariant to immutable...
>
> Speaking of which... guess what he just did :o).
>
> Andrei


Oh, come on... did he? :D
October 05, 2008
Christopher Wright wrote:
> Andrei Alexandrescu wrote:
>> Christopher Wright wrote:
>>> Andrei Alexandrescu wrote:
>>>> The problem I see with "!" as a template instantiation is not technical. I write a fair amount of templated code and over years the "!" did not grow on me at all. I was time and again consoled by Walter than one day that will happen, but it never did. I also realized that Walter didn't see a problem with it because he writes only little template code.
>>>>
>>>> I didn't have much beef with other oddities unique to D. For example, I found no problem accommodating binary "~" and I was wondering what makes "!" different. I was just looking at a page full of templates and it looked like crap.
>>>>
>>>> One morning I woke up with the sudden realization of what the problem was: the shouting.
>>>
>>> Not only that, but typing it is annoying. First you need to put the right pinky on the shift key, which is a long reach; then you need to put the left pinky on the 1 key, which is a long reach. Then you need to move your left pinky all the way back to the left shift key, which is a short reach, and move your right ring finger up to the 9 key.
>>>
>>> It's a lot of reaching and back and forth.
>>>
>>> But I don't favor '.' since it's already used.
>>
>> I don't favor "." any more than the next guy, but I am glad there is awareness of how unfit a choice "!" is. If you have any ideas, please post them! Ah! I! Exclaimed! Again!
>>
>> Andrei!
> 
> I agree with Mr. Martin II: colon might be an unambiguous option, and for qwerty keyboards, you don't have to switch shift keys. (I use dvorak, so it'd be slightly more awkward, but still a fair bit more easier than a bang.)
> 
> Also, colon's taller than dot, so it's easier to see.

How to distinguish a label from a template then? Should I print X or Y in the following code?

import std.stdio;

class X {
	static void print () {
		writeln("Y");
	}
}

template T (x) {
	void print () {
		writeln("X");
	}
}

void main () {
	T:(X).print();
}
October 05, 2008
Sean Kelly wrote:
> Andrei Alexandrescu wrote:
>> I believe the clear distinction is not only unnecessary, but undesirable. We should actively fight against it.
> 
> Why is it undesirable?  I like the idea of static parameters as described at the conference last year, but I don't think that has any bearing on this particular issue.

Time and again, both Walter and myself have met people who experience a mental block whenever templates come within a mile. The fact that they come with the sign Here! This! Is! A! Template! doesn't help any.

Andrei
October 05, 2008
Sean Kelly wrote:
> I like the use of '!' specifically for its linguistic connotation.  It communicates to me that what's happening isn't normal run-time stuff.

But I'm sure you don't have a beef with function template argument deduction, and normal run-time stuff that ain't.

>> The one way to figure whether you'd aesthetically like something or not is to try it on some code. Unfortunately, that's not yet possible until the next release (Walter was kind enough to send me an alpha for a test drive). So my only request is kindly please hold off judgment until you can play with the notation and see how you feel.
> 
> Will do.  It's easy enough to search-replace '!' with '.'

You'll need a sed expression to not catch unary ! and != as well.


Andrei

October 05, 2008
Sean Kelly wrote:
> hehe... how about we swap '!' for '.' and in exchange we get to use something other than 'enum' for manifest constants ;-)

You know what, I believe "." is such an improvement, I'd join the movement.

Andrei

October 05, 2008
Janderson wrote:
> Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> (Background: Walter has kindly allowed ".()" as an alternative to the ugly "!()" for template argument specifications.)
>>
>> Just a quick question - I am feeling an increasing desire to add a template called Positive to std.typecons. Then Positive.(real) would restrict its values to only positive real numbers etc.
>>
>> The implementation would accept conversion from its base type, e.g. Positive.(real) can be constructed from a real. The constructor enforces dynamically the condition. Also, Positive.(real) accepts implicit conversion to real (no checking necessary).
>>
>> There are many places in which Positive can be useful, most notably specifications of interfaces. For example:
>>
>> Positive.(real) sqrt(Positive.(real) x);
>>
>> These specifications are also efficient because checking for positivity is done outside sqrt; if you had a Positive.(real) to start with, there is no cascading checking necessary so there's one test less to do.
>>
>> However, there is also the risk that Positive has the same fate the many SafeInt implementation have had in C++: many defined them, nobody used them. What do you think? If you had Positive in std and felt like crunching some numbers, would you use it?
>>
>> In order to get things really started, there's already been an exchange with Walter on the matter. His reply was (I haven't asked for permission, but I'm pretty sure he'd agree making it public):
>>
>> ==============
>> Honestly, I wouldn't use it. I'd rather have an in contract for sqrt that asserts the argument is positive. Also, this opens the door to Negative, NegativeOrZero, ZeroOrInfinity, Odd, Even, Prime, SixOrFifteen, etc.
>> ==============
>>
>> My answer to that was:
>>
>> ==============
>> About contracts: Let me explain how I think that's inferior to Positive in two ways.
>>
>> 1. Enough functions are defined on positive numbers only, to justify factoring that contract out of the functions themselves.
>>
>> 2. The efficiency perk is that when using several such functions together, there's only one check; once in Positive-land, no more checks are necessary.
>>
>> About proliferation of types: I don't think that follows at all. Math found positive numbers special enough to dedicate them a special notation (|R with subscript "+"). There's also a special notation for nonzero real numbers (|R with superscript "*"). There is no special notation for any of the sets you mentioned. That is bound to mean something.
>> ==============
>>
>> I'm interesting in further arguments. This feature is a numbers issue (pun not intended), meaning it will be any good only if enough people find it useful enough to actually use it in their own code and libraries, therefore building momentum behind it.
>>
>>
>> Andrei
> 
> As others have mentioned.
> 
> Why a second class form of range restriction?  Why not a first class implementation like ADA's with ranges and subranges as specific typedefs?  I know it would be more work for the compiler writer to implement (if it can't be done in templates) however I prefer more generic solutions then having many once-off solutions that crudely fit together.
> 
> Being able to simply pick a type that is within the range needed would save having to write contracts and static contracts all over the place.  It also a great form of documentation.  I would find that useful, particularly when working with algorithms that traverse arrays in specific sequences such as spacial data structures but need to maintain certain constraints.

Making ufloat, udouble, ureal as instantiations of Bounded.(low, high) is a great idea!

Andrei
October 05, 2008
Michel Fortin wrote:
> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
> 
>> I don't favor "." any more than the next guy, but I am glad there is awareness of how unfit a choice "!" is. If you have any ideas, please post them! Ah! I! Exclaimed! Again!
> 
> Hum, I don't think we have much choice, it'll have to be something in this lot:
> 
>     Positive!(real)(joke);
>     Positive.(real)(joke);
>     Positive#(real)(joke);
>     Positive@(real)(joke);
>     Positive&(real)(joke);
>     Positive`(real)(joke);
>     Positive´(real)(joke);
>     Positive^(real)(joke);
>     Positive¨(real)(joke);
>     Positive\(real)(joke);
> 
> Anything else I forgot?
> 
> Or we could use special delimiter characters:
> 
>     Positive<real>(joke);
>     Positive“real”(joke);
>     Positive«real»(joke);
>     Positive#real@(joke);
> 
> Each having its own problem though.
> 
> My preference still goes to "!(".

There was also Positive{real}(joke), with which I couldn't find an ambiguity.

> - - -
> 
> The ".(" syntax makes me think more of something like this:
> 
>     void func(T, alias methodOfT, A...)(T obj, A args)
>     {
>         obj.(methodOfT)(args);
>     }
> 
> which I which I could do. If methodOfT was a string, I suppose I could use string mixins, but it pushes diagnostics about misnamed methods further in the template and requires adding quotes to the template parameter when instanciating.

Given that methodOfT is an alias, there is no need for the parens.


Andrei