November 14, 2012
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright wrote:
> On 11/13/2012 12:56 PM, Walter Bright wrote:
>> An insightful talk by Guy Steele on what makes a language successful.
>>
>> http://www.youtube.com/watch?v=_ahvzDzKdB0
>
> Guy says something interesting in there that's applicable to one of our current discussions.
>
> Particularly, should we allow:
>
>    @identifier
>
> as a user-defined attribute, in potential conflict with future reserved attribute words, or not?
>
> Guy makes the argument that users need to be able to extend the vocabulary of a language and have those new words look like built-in ones. We have that today, of course, with the ability of defining new types. There is no special syntax that says "this is a user-defined type, not a keyword."
>
> I think this is a compelling argument, and tips the scales in its favor. Probably we've been excessively worried about the problems of adding a new builtin attribute type.

I think an example to watch is how Java has been evolving.

Since attributes were added to the language, new features tend to be introduced via new attributes (e.g. @Overload, @NotNull, ...) to avoid collisions with existing code.

While it makes sense from the backwards compatibility point of view, and Python3 is a good example people don't like rewriting legacy code, it leads to attribute definition explosion.

--
Paulo

November 14, 2012
On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:
> On 2012-43-14 11:11, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 11/14/2012 1:49 AM, renoX wrote:
>>> That's not strictly true: type inference works better for built-in types than
>>> for user-defined types, with "auto x = 1;" x is an int, how do I have the same
>>> type of syntax for MyInt?
>>
>> You can have user-defined literals in D:
>>
>>     auto x = MyInt(1);
>>
>
> But the syntax for built-in types is better, in that you don't need to
> write:
>
> auto x = int(1);
>

If you're going to argue that D should have some facility to create user-defined literals that are arbitrary sequences of arbitrary characters, I think you're taking Guy's advice way beyond the breaking point.

This is pretty much true about every "principle" of language design. If you use that principle to blindly override everything else, you do not get anything useful.

All design is a compromise of competing goals.
November 14, 2012
On 11/14/2012 3:18 AM, Timon Gehr wrote:
> template Foo(alias a){ }
> struct S{}
>
> alias S X;     // ok
> alias int Y;   // ok
> mixin Foo!S;   // ok
> mixin Foo!int; // not ok
>
> Please fix that. (Everything should be ok.)

Please file a bugzilla for that.

November 15, 2012
On 11/14/2012 11:24 PM, Walter Bright wrote:
> On 11/14/2012 3:18 AM, Timon Gehr wrote:
>> template Foo(alias a){ }
>> struct S{}
>>
>> alias S X;     // ok
>> alias int Y;   // ok
>> mixin Foo!S;   // ok
>> mixin Foo!int; // not ok
>>
>> Please fix that. (Everything should be ok.)
>
> Please file a bugzilla for that.
>

http://d.puremagic.com/issues/show_bug.cgi?id=9029
November 15, 2012
On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:
> But the syntax for built-in types is better, in that you don't need to
> write:
>
> auto x = int(1);

.... suppose I want a size_t?

November 15, 2012
On 11/15/2012 2:24 AM, Joseph Rushton Wakeling wrote:
> On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:
>> But the syntax for built-in types is better, in that you don't need to
>> write:
>>
>> auto x = int(1);
>
> .... suppose I want a size_t?
>

size_t x = 1;
November 15, 2012
On Wednesday, 14 November 2012 at 22:23:17 UTC, Walter Bright wrote:
> On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:
>> But the syntax for built-in types is better, in that you don't need to write:
>>
>> auto x = int(1);
>>
>
> If you're going to argue that D should have some facility to create user-defined literals that are arbitrary sequences of arbitrary characters, I think you're taking Guy's advice way beyond the breaking point.

 Hmmm... Correct me if I'm wrong, but you can create/use opAssign, correct? Although that doesn't work during initialization...

struct MyInt
{
  int i;
  ref MyInt opAssign(int rhs) {
    i = rhs;
    return this;
  }
}

MyInt x = MyInt(10);
MyInt y; // = 15; //cannot implicity convert
y = 15;

writeln(x);
writeln(y);

November 15, 2012
On 2012-11-15 20:32, Era Scarecrow wrote:

>   Hmmm... Correct me if I'm wrong, but you can create/use opAssign,
> correct? Although that doesn't work during initialization...
>
> struct MyInt
> {
>    int i;
>    ref MyInt opAssign(int rhs) {
>      i = rhs;
>      return this;
>    }
> }
>
> MyInt x = MyInt(10);
> MyInt y; // = 15; //cannot implicity convert
> y = 15;

That's what a construtor is for:

struct MyInt
{
    int i;

    this (int i)
    {
        this.i = i;
    }

    ref MyInt opAssign(int rhs) {
        i = rhs;
        return this;
    }
}

void main()
{
    MyInt i = 3;
}

-- 
/Jacob Carlborg
November 15, 2012
On 11/15/2012 11:54 AM, Walter Bright wrote:
> size_t x = 1;

Complete misunderstanding there -- I'd interpreted Simen's remark as saying that e.g. auto x = 1; would automatically assign the correct type where builtins were concerned, and I was pointing out that this wouldn't cover all builtins.  Though I guess auto x = 1UL; would work.

I wasn't asking how to create a size_t per se, which I do know how to do ... :-)

I once came an awful cropper due to lack of UL in an integer assignment.  I'd got a bit of C(++) code like this:

     size_t p = 1 << m;

where m was chosen such that p would be the largest power of 2 on the system that could (i) be multiplied by 2 without integer wraparound and (ii) was within the range of the uniform integer random number generator in use.

And that worked fine ... until I installed a 64-bit OS, and suddenly, all the numbers were coming out different.

They shouldn't have been, because the RNG in use was still based around int32_t and so the same constraints on m and p should have been in place ... and then I discovered what was happening: 1 << m; wasn't taking a size_t (unsigned long) and bitshifting it by m places, it was taking a regular int and bitshifting it by m places ... which given the value of m, was causing integer wraparound, the result of which was then converted to a size_t.

It just so happened that on 32-bit this was taking the value back to where it was supposed to be anyway.  But on 64-bit the wraparound made 1 << m a negative number which in turn corresponded to a far too _large_ value when converted into a size_t.

And so I learned that I had to use 1UL << m; instead ... :-P
November 16, 2012
On 2012-11-15 22:08, Joseph Rushton Wakeling wrote:

> Complete misunderstanding there -- I'd interpreted Simen's remark as
> saying that e.g. auto x = 1; would automatically assign the correct type
> where builtins were concerned, and I was pointing out that this wouldn't
> cover all builtins.  Though I guess auto x = 1UL; would work.

Should this give you an unsigned long regardless of architecture? "size_t" is unsigned int on 32bit platforms and unsigned long on 64bit platforms.

-- 
/Jacob Carlborg