foobar:

> named parameters are 99% of the time a horrible idea and likely indicate a design flaw.

Named arguments help avoid some bugs, make the code more readable, and having used them for many years, they don't seem to indicate significant flaws in my code.

Bye,
bearophile

On 04/30/2012 07:03 AM, Jonathan M Davis wrote:
> On Sunday, April 29, 2012 21:56:08 H. S. Teoh wrote:
>> I wonder if dmd (or rdmd) should have a mode where it *only* compiles
>> unittest code (i.e., no main() -- the resulting exe just runs unittests
>> and nothing else).
>
> It wouldn't make sense. It's nowhere near as bad as C++, but dmd has to
> recompile modules all the time unless you compile the entire program at once.
> When you run a build, every single module on the command line and all of the
> imported modules get compiled.

Only the symbols that need to be analysed actually get analysed (eg. CTFE, instantiated templates.) The other symbols are merely parsed, and parsing is quite cheap.

> Object code is generated only for those on the
> command line, but the others are still compiled.

I think 'compiled' would imply that some output code is generated.

> Any imported module which
> uses a .di file won't have as much to compile,

There is no difference between .d files and .di files except that the compiler prefers the .di file for imports.

> and any templated code that
> doesn't get used in those modules won't get compiled,  but there's still lots
> of recompilation going on if you compile your program incrementally.

It depends on how much CTFE is performed on the module interface level.

> And D

DMD.

> just isn't set up to compile only a portion of a module.
>
> - Jonathan M Davis

If that is necessary then the module is too big.

On Monday, 30 April 2012 at 17:13:36 UTC, H. S. Teoh wrote:
> On Mon, Apr 30, 2012 at 01:04:01PM -0400, Jonathan M Davis It would be unwise to make major changes to the language at this point.
> Personally I'd like to see the comma operator removed, but people keep
> saying it will break existing code, so that's probably not going to
> happen in D2. D3 perhaps will be able to clean up a lot of this mess.

 Then perhaps the comma operator can be pushed to the 'depreciated' list for a while; If it breaks anything big and important, you can still compile it. After a while we can see if it should be kept or removed. I think that's the best approach all things considered.

 Personally, I have yet to really use it outside of a for/foreach statement. On the other hand if it breaks something, generally it will become quite clear where in few the few places and require you to fix and update it before moving on.

On 04/30/2012 05:21 PM, Alex Rønne Petersen wrote:
> On 30-04-2012 08:37, jerro wrote:
>>> 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.
>>
>> It does arithmetic shift if the left operand is signed,
>> unsigned shift otherwise. This code:
>>
>> void main()
>> {
>> int a = 0xffffffff;
>> uint b = a;
>> writefln("%x", a >> 1);
>> writefln("%x", b >> 1);
>> }
>>
>> prints
>>
>> ffffffff
>> 7fffffff
>>
>
> The documentation disagrees:
> http://dlang.org/expression.html#ShiftExpression
>
> It claims that it always does arithmetic shift and >>> always does
> unsigned shift.
>

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

On Mon, Apr 30, 2012 at 08:09:31PM +0200, Era Scarecrow wrote:
> On Monday, 30 April 2012 at 17:13:36 UTC, H. S. Teoh wrote:
> >It would be unwise to make major changes to the language at this point.  Personally I'd like to see the comma operator removed, but people keep saying it will break existing code, so that's probably not going to happen in D2. D3 perhaps will be able to clean up a lot of this mess.
> 
>  Then perhaps the comma operator can be pushed to the 'depreciated'
>  list for a while; If it breaks anything big and important, you can
>  still compile it. After a while we can see if it should be kept or
>  removed. I think that's the best approach all things considered.
> 
>  Personally, I have yet to really use it outside of a for/foreach
>  statement. On the other hand if it breaks something, generally it
>  will become quite clear where in few the few places and require you
>  to fix and update it before moving on.

Actually it's only inside for. A comma in foreach is not a comma
operator but a separator (foreach(a,b;c) is not the same as
foreach(b;c)). See, that's another case where it only causes confusion.

And I've said many times that inside a for, it really should just be special-cased in for syntax. It should not be an operator in general.


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.

On 30-04-2012 20:28, H. S. Teoh wrote:
> On Mon, Apr 30, 2012 at 08:09:31PM +0200, Era Scarecrow wrote:
>> On Monday, 30 April 2012 at 17:13:36 UTC, H. S. Teoh wrote:
>>> It would be unwise to make major changes to the language at this
>>> point.  Personally I'd like to see the comma operator removed, but
>>> people keep saying it will break existing code, so that's probably
>>> not going to happen in D2. D3 perhaps will be able to clean up a lot
>>> of this mess.
>>
>>   Then perhaps the comma operator can be pushed to the 'depreciated'
>>   list for a while; If it breaks anything big and important, you can
>>   still compile it. After a while we can see if it should be kept or
>>   removed. I think that's the best approach all things considered.
>>
>>   Personally, I have yet to really use it outside of a for/foreach
>>   statement. On the other hand if it breaks something, generally it
>>   will become quite clear where in few the few places and require you
>>   to fix and update it before moving on.
>
> Actually it's only inside for. A comma in foreach is not a comma
> operator but a separator (foreach(a,b;c) is not the same as
> foreach(b;c)). See, that's another case where it only causes confusion.
>
> And I've said many times that inside a for, it really should just be
> special-cased in for syntax. It should not be an operator in general.
>
>
> T
>

Indeed. C# just special-cases it inside for.

-- 
- Alex

On 30-04-2012 20:17, Timon Gehr wrote:
> On 04/30/2012 05:21 PM, Alex Rønne Petersen wrote:
>> On 30-04-2012 08:37, jerro wrote:
>>>> 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.
>>>
>>> It does arithmetic shift if the left operand is signed,
>>> unsigned shift otherwise. This code:
>>>
>>> void main()
>>> {
>>> int a = 0xffffffff;
>>> uint b = a;
>>> writefln("%x", a >> 1);
>>> writefln("%x", b >> 1);
>>> }
>>>
>>> prints
>>>
>>> ffffffff
>>> 7fffffff
>>>
>>
>> The documentation disagrees:
>> http://dlang.org/expression.html#ShiftExpression
>>
>> It claims that it always does arithmetic shift and >>> always does
>> unsigned shift.
>>
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8007

Thanks; these kinds of documentation bugs can cause really nasty misunderstandings.

-- 
- Alex

On 04/30/2012 05:45 AM, H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 04:40:37PM +0200, Jacob Carlborg wrote:
> [...]
>
> So really, what is needed is a sane looping construct that unifies while
> loops, do-loops, and exit-in-the-middle loops. Something like this:
>
> 	loop {
> 		// first part of loop body
> 	} exitWhen(!loopCondition) {
> 		// second part of loop body
> 	}
>
> It doesn't have to be this exact syntax, but the point is that you need
> to be able to express loop exits from the middle of a loop body without
> needing to resort to for(;;) and break, when the loop is a good ole
> simple loop with a single entry point and a single exit point. (More
> complex loops that need continue's and break's are, well, more complex,
> so it's OK to sprinkle if conditions in them like we do now.)
>
> </rant>
>

do{
    // ...
}while(cond){
    // ...
}

I think the scoping rules of the do-while loop should be fixed such that the loop condition can refer to loop-local variables. Violates C backwards compatibility though...


>
> [...]
>> * Infix notation for calling any method taking one argument
>> * Basically any symbol is allowed in method names
>>
>> That is:
>>
>> 1 + 2
>> foo bar foo_bar
>>
>> Would be translated to:
>>
>> 1.+(2)
>> foo.bar(foo_bar)
>>
>> That is a very general way to handle operators and let the user
>> create new operators, not just overloading existing ones.
> [...]
>
> While personally, I like the idea of being able to create new infix
> operators, it will cause too big a change to D syntax, and probably
> cause lots of breakages with existing code, as well as make the
> lexer/parser much harder to implement (given the existing D features).
>

Should be trivial. (The parser can just defer operator precedence resolution to the analysis phase if necessary, and otherwise it is very simple anyway.)

> You also then have to deal with operator precedence between arbitrary
> user-defined operators, which is non-trivial in general (though it's
> workable if you impose some constrains

I kinda like the Scala-approach.

> -- but it's probably way beyond the scope of D2 or even D3).
>

An issue is that it clashes with eg. a+***ptrtoptrtoptrtodata.

"SomeDude" <lovelydear@mailmetrash.com> wrote in message news:ajdmseliewbindkkoxxj@forum.dlang.org...
>
> [...]There would be no longer any need for the "in" and "out" keywords.[...]

void foo()
in{ ... }
out{ ... }
body{ ... }

On 04/30/2012 08:30 PM, Alex Rønne Petersen wrote:
> On 30-04-2012 20:17, Timon Gehr wrote:
>> On 04/30/2012 05:21 PM, Alex Rønne Petersen wrote:
>>> On 30-04-2012 08:37, jerro wrote:
>>>>> 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.
>>>>
>>>> It does arithmetic shift if the left operand is signed,
>>>> unsigned shift otherwise. This code:
>>>>
>>>> void main()
>>>> {
>>>> int a = 0xffffffff;
>>>> uint b = a;
>>>> writefln("%x", a >> 1);
>>>> writefln("%x", b >> 1);
>>>> }
>>>>
>>>> prints
>>>>
>>>> ffffffff
>>>> 7fffffff
>>>>
>>>
>>> The documentation disagrees:
>>> http://dlang.org/expression.html#ShiftExpression
>>>
>>> It claims that it always does arithmetic shift and >>> always does
>>> unsigned shift.
>>>
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=8007
>
> Thanks; these kinds of documentation bugs can cause really nasty
> misunderstandings.
>

I don't trust the documentation. In my experience, it is usually best to rely on common sense to get a grasp for how a feature is supposed to behave (that works surprisingly well!) and occasionally file bug reports if either the documentation or DMD is strange in a certain aspect. (I'll probably file a bunch of implicit-conversion related bugs tomorrow.)