On 30-04-2012 00:08, Timon Gehr wrote:
> On 04/29/2012 10:59 PM, Alex Rønne Petersen wrote:
>> On 29-04-2012 14:26, David Nadlinger wrote:
>>> - Unsigned right shift, but I can see how it can be useful (simply
>>> underused?).
>>
>> It's clear that arithmetic right shift is what the programmer usually
>> wants, and yet, we use >> to denote what they don't want. It's
>> completely counter-intuitive.
>>
>> So, +1.
>>
>
> '>>' is arithmetic right shift.

Sorry, I managed to get myself confused here. What I meant to say was that I think >> should do an arithmetic shift if the operands are signed; unsigned shift otherwise.

>
>>>
>>> - shared: TLS by default is great, but only __gshared is really usable
>>> right now. IMHO, shared had better been reserved for a comprehensive
>>> take on the subject, rather than the half-baked implementation we have
>>> right now.
>>>
>>> David
>>
>> It's clear that shared is biased towards heavily templatized code.
>> It's not useful in non-templatized code because such code can't accept
>> both
>> shared and non-shared values.
>
> Just cast it away if you do eg. locking. There is nothing wrong with it.
> Code that operates on both (actually) shared and unshared data should be
> uncommon anyway.

The problem is that shared is supposed to insert memory barriers (I know it doesn't, but that's the goal/idea).

>
>>
>> shared looks neat in theory, but is a fallacy in practice.
>>
>
> unshared is what is important. There is no unshared if there is no shared.

I think this statement went over my head...

-- 
- Alex

On Sunday, 29 April 2012 at 21:06:10 UTC, Alex Rønne Petersen wrote:
> On 29-04-2012 22:24, SomeDude wrote:
>> Ah ok. But I'm not sure what's wrong with the package protection level
>> either, actually.
>
> Yes, me neither. And I have found many cases in my code where using it actually makes sense and helps encapsulation.

See the Java discussion on »superpackages« – quite often, you want to share stuff in mylibrary.subpackage with the rest of mylibrary, but not the world.

David

Walter:

> What's your list?

This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter & Andrei?

Bye,
bearophile

On 29/04/2012 19:08, Manu wrote:
> current module/package

http://dlang.org/phobos/std_traits#packageName

http://dlang.org/phobos/std_traits#moduleName

-- 
Robert
http://octarineparrot.com/

On Sunday, 29 April 2012 at 15:07:26 UTC, David Nadlinger wrote:
> On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
>> foreach ([1, 2, 3, 4], (i)  { writeln(i); });
>>
>> The above already works today. If we can a bit syntax sugar for delegates and inlinable delegates we could have this:
>>
>> foreach ([1, 2, 3, 4] ; i) {
>>    writeln(i);
>> }
>
> We'd still need a solution for continue and break, though.

 A thought coming to mind regarding this, is a special exception. If the compiler recognizes it's part of a foreach (or other loop) then continue gets converted to return, and and break throws an exception (caught by the foreach of course)

 But that involves more compiler magic.

On 30-04-2012 01:54, Era Scarecrow wrote:
> On Sunday, 29 April 2012 at 15:07:26 UTC, David Nadlinger wrote:
>> On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
>>> foreach ([1, 2, 3, 4], (i) { writeln(i); });
>>>
>>> The above already works today. If we can a bit syntax sugar for
>>> delegates and inlinable delegates we could have this:
>>>
>>> foreach ([1, 2, 3, 4] ; i) {
>>> writeln(i);
>>> }
>>
>> We'd still need a solution for continue and break, though.
>
> A thought coming to mind regarding this, is a special exception. If the
> compiler recognizes it's part of a foreach (or other loop) then continue
> gets converted to return, and and break throws an exception (caught by
> the foreach of course)
>
> But that involves more compiler magic.
>

And forced EH which is unacceptable in e.g. a kernel.

-- 
- Alex

On Sat, 28 Apr 2012 22:40:10 +0200, Artur Skawina <art.08.09@gmail.com> wrote:

> On 04/28/12 22:02, Walter Bright wrote:
>> On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
>>> Also there's mixin templates. What exactly is the difference between
>>> mixin templates and regular templates?
>>
>> A mixin template is instantiated in context of the instantiation point, while a regular template is instantiated in the context of the template definition point.
>>
>> This becomes relevant when looking up symbols that are not defined within the template.
>
> Yeah, but this was actually the only suggestion so far in this thread that
> i could agree with... The issue is
>
>    template t1() { int a = b; }
>    int main() { int b; mixin t1; return a; }
>
> which is currently accepted - and would enforcing the mixin annotation
> really help anything?
>
> artur

At least some of us want mixin templates to be marked mixin at declaration
point, and usable without 'mixin':

mixin template A( ) {
    int n;
}

struct S {
    A!();
}

On 28/04/2012 20:22, Dmitry Olshansky wrote:
> 3. with statement (?). I kind of like it but bleh it's too boggy and it
> doesn't seem to pull its weight. (pointers? class references? a lot of
> stuff to go wrong) Fluent interfaces solve a good portion of its
> benefits to be specific.

My primary use case for the with() statement is with final switch:

final switch(something) with(MyEnumWithAPrettyLongName)
{
    case A: // Save repeating myself everywhere
        break;

    . . .

}

-- 
Robert
http://octarineparrot.com/

On 30-04-2012 02:40, Robert Clipsham wrote:
> On 28/04/2012 20:22, Dmitry Olshansky wrote:
>> 3. with statement (?). I kind of like it but bleh it's too boggy and it
>> doesn't seem to pull its weight. (pointers? class references? a lot of
>> stuff to go wrong) Fluent interfaces solve a good portion of its
>> benefits to be specific.
>
> My primary use case for the with() statement is with final switch:
>
> final switch(something) with(MyEnumWithAPrettyLongName)
> {
> case A: // Save repeating myself everywhere
> break;
>
> . . .
>
> }
>

Hah, clever! Never would've thought of that.

-- 
- Alex

On Sunday, April 29, 2012 17:50:48 Don wrote:
> * package. I have no idea how a failed Java experiment got incorporated into D.

Really? In some cases, it's indispensable. For instance, once std.datetime has been split up, it will require it, or it would have duplicate a bunch of implementation-specific stuff which has no business in the public API.

- Jonathan M Davis