On Tuesday, 1 May 2012 at 02:40:34 UTC, Walter Bright wrote:
> On 4/28/2012 1:32 PM, Timon Gehr wrote:
>> […]
>> class C{
>> int x;
>> mixin X; // picks up local 'x'
>
> Makes it a mixin template.

Why not just require mixin templates to be declared using »mixin template« then?

David

On 05/01/12 02:25, H. S. Teoh wrote:
> On Tue, May 01, 2012 at 02:14:42AM +0200, bearophile wrote:
>> Timon Gehr:
>>
>>> * I agree on supporting deducing length for static arrays. (there
>>> is a
>>>  int[$] arr = [1,2,3]; proposal.)
>>
>> Someone in Bugzilla ha just proposed an alternative idea, that despite not looking very nice, is not overall bad (here with a small change):
>>
>> auto arr = [1, 2, 3]f;
>>
>> That trailing f denotes a fixed-side array/string literal. So it's usable for other situations too.
> [...]
> 
> I don't like it. An f prefix already means float in another context; overloading it to also mean static array is a bad idea. D already has too much overloaded syntax (like static meaning all sorts of diverse things depending on context). I much prefer the int[$] proposal, because $ already means "length of array" in D, and so would fit right in.

Since one of the most characteristic D features is overloading "static" whenever possible, this would fit right in:

   auto arr = static [1, 2, 3];

artur

On 2012-04-30 21:56, Alex Rønne Petersen wrote:
> On 30-04-2012 21:43, Jacob Carlborg wrote:
>> On 2012-04-30 17:27, Alex Rønne Petersen wrote:
>>> On 30-04-2012 09:58, Jacob Carlborg wrote:
>>
>>>> I would rather have @property on instance variables be a syntax sugar
>>>> for implementing property functions. Basically virtual instance
>>>> variables.
>>>>
>>>
>>> Then there better be a way to mark them final too. ;)
>>>
>>
>> Then what's the point of having a method? Just use a public instance
>> variable.
>>
>
> Encapsulation. I want contracts in my properties.
>

Aha, didn't thin of that. Sure, why not.

-- 
/Jacob Carlborg

On 2012-04-30 22:03, Alex Rønne Petersen wrote:
> On 30-04-2012 21:42, Jacob Carlborg wrote:

>> When is r"" a better use than ``? We already have the regular "".
>>
>
> You don't have escape sequences inside r"", so they can be useful if you
> have backslashes in your string.

`` can be used for that. ` is good because it's a different delimiter compared to r"" or "".

-- 
/Jacob Carlborg

On 2012-05-01 11:50, Artur Skawina wrote:

> Since one of the most characteristic D features is overloading "static"
> whenever possible, this would fit right in:
>
>     auto arr = static [1, 2, 3];
>
> artur

Meaning this would need to be allowed:

static arr = static [1, 2, 3];

That looks a bit confusing.

-- 
/Jacob Carlborg

Le 30/04/2012 14:44, Don Clugston a écrit :
>
> It's not a bug, it's a design flaw. The buggy behaviour is explicitly
> tested in the test suite.
> The problem is that the C promotion rules also apply, just as for >> and
> <<. But they are fundamentally incompatible with unsigned shift.
> So short and byte get promoted to int *by sign extension*,
> then the int gets an unsigned shift.
> Which means that the short or byte gets a signed shift instead of an
> unsigned one.

Thanks for pointing that out.
Sadly, it makes some sense with the C integer promotion rules.

On 04/30/2012 02:44 PM, Don Clugston wrote:
>
> (cast(ulong)x) >> 3 is safer than x >>> 3, unfortunately.

In what way is it safer?

void main() {
    short x = -1;
    assert((cast(ulong)x) >> 3 == cast(long)x >>> 3);
}

On 01-05-2012 13:22, Jacob Carlborg wrote:
> On 2012-04-30 22:03, Alex Rønne Petersen wrote:
>> On 30-04-2012 21:42, Jacob Carlborg wrote:
>
>>> When is r"" a better use than ``? We already have the regular "".
>>>
>>
>> You don't have escape sequences inside r"", so they can be useful if you
>> have backslashes in your string.
>
> `` can be used for that. ` is good because it's a different delimiter
> compared to r"" or "".
>

It *can*, but it's annoying on non-US keyboards, which was my original point.

-- 
- Alex

On 01-05-2012 06:44, SomeDude wrote:
> On Tuesday, 1 May 2012 at 02:26:53 UTC, Alex Rønne Petersen wrote:
>> On 01-05-2012 03:41, Jesse Phillips wrote:
>>>
>>> Complexity of the operation. in on an array is not nearly the same as
>>> with an associative array.
>>
>> I know, but it's very intuitive still; see Python.
>
> And that's why it's somewhat dangerous. Because it's so easy to use,
> someone that doesn't pay enough attention may overlook the fact that he
> is not using the right data structure. If he often has to do that more
> than once, he is using the wrong tool for the job. I agree it would be
> syntaxically nice, but I worry giving this syntactic sugar for what's a
> for loop with lots of comparisons isn't such a good idea. And the
> comparisons themselves are subject to caution. If for instance it's an
> array of floats, or some custom objects, it's very unlikely that you are
> going to compare bit by bit. So basically, this would be useful only for
> integers and chars.

1) So because some people might use a feature incorrectly due to lack of knowledge in algorithms and data structures, we should cripple the language?
2) The same holds true for AAs keyed by floats.

-- 
- Alex

On 2012-05-01 16:28, Alex Rønne Petersen wrote:

> It *can*, but it's annoying on non-US keyboards, which was my original
> point.
>

Well, I don't agree.


-- 
/Jacob Carlborg