Few things I have collected in the last days.

Can RAND_MAX be added to std.c.stdlib of D1 too?

-----------------------

What is the advantage of having a separate /+ +/ nestable comment syntax?
Can't the /+ +/ be removed to make the normal /* */ syntax nestable?
(IS the different C semantics of /* */ a problem here? I don't think so.)

-----------------------

Using obj2asm to the .obj produced by D2 (v2.029) produced huge (like 100-600 KB!) asm files even for 10-lines long programs (The same asm files where very small for D1). There's a very large amount of asm code inside there.

-----------------------

From the Python newsgroup:

>Linden Lab, makers of Second LIfe virtual world, found it was good to create a C++ class similar to a Python dictionary in order to leverage some of the faster prototyping advantages of that Python type when converting to C++.<

>LLSD is a proposed IETF standard so there's no licensing issues involved in using the technique, and I believe there are implementations in C++ (GPL) and C#(BSD) and possible other languages as well.<

>Linden Lab Structured Data (LLSD) is an abstract type system intended to provide a language-neutral facility for the representation of structured data.  It provides a type system, a serialization system and an interface description language.<

http://wiki.secondlife.com/wiki/LLSD http://tools.ietf.org/id/draft-hamrick-llsd-00.txt

-----------------------

The std.intrinsic module may gain a standard way to perform a 64-bit by 32-bit division, for the situations where you know the quotient will fit in 32 bits ('divl' instruction on X86).
CPUs that don't support such operation can use the normal 64-big division.

-----------------------

I don't like the way Ruby denotes intervals open/closed on the right.

The following is how you do it in the Groovy language (but I don't like it, because I like intervals by default open on the right):

Loop on closed on the right range:
for (i in 0..n)

Loop on open on the right range:
for (i in 0..<n)


Two possible syntaxes for D, to represent intervals closed on the right, using ..#  or  ..>

for (i; 0 ..# n)
for (i; 0 ..> n)

I like the syntax with # better.
But probably adding a +1 at the end is good enough too for D. Better keep things simpler.

Later,
bearophile

Reply to bearophile,

> Few things I have collected in the last days.
> 
> What is the advantage of having a separate /+ +/ nestable comment
> syntax?
> Can't the /+ +/ be removed to make the normal /* */ syntax nestable?
> (IS the different C semantics of /* */ a problem here? I don't think
> so.)

you spotted the issue, code porting and principle of least surprise

BCS:
> you spotted the issue, code porting and principle of least surprise<

- Code porting: If you port C code to D, it uses /* */ in a non nested way, so making /* */ nestable in D doesn't cause problems. The new semantic is backward compatible.
- The principle of least surprise: a C programmer doesn't nest them. So if used correctly there's no surprise. If he/she/shi tries to nest them (creating a bug if it's C code) finds their increased semantic meaning. I don't think this can lead to bugs. The new nesting semantic is natural, and quick to learn once you read about it, see it, or try it once. My editor colorizes the code correctly according to the nestable /+ +/ too.
- Complexity: every syntactic bit removed from the D language is a gain. Less things to learn, to read about, to remember, etc.

So I'm for the removal of /+ +/ and making /* */ nestable.

Bye,
bearophile

bearophile wrote:
> BCS:
>> you spotted the issue, code porting and principle of least surprise<
> 
> - Code porting: If you port C code to D, it uses /* */ in a non nested way

No. This is valid C:

/* comment /* more comment */

> - The principle of least surprise: a C programmer doesn't nest them.

Nesting occurs often when various portions of code are commented.

> - Complexity: every syntactic bit removed from the D language is a gain.

I guess I agree with this.

> So I'm for the removal of /+ +/ and making /* */ nestable.

This can't work.


Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsku34$29tn$1@digitalmars.com...
> bearophile wrote:
>> BCS:
>>> you spotted the issue, code porting and principle of least surprise<
>>
>> - Code porting: If you port C code to D, it uses /* */ in a non nested way
>
> No. This is valid C:
>
> /* comment /* more comment */
>

That seems like a rather trivial thing to be designing our language around. And regarding principle of least surprise, the current /**/ behavior is only least-surprise for people who are already familiar with that particular detail of /**/. From a fresher perspective, the /++/ behavior is vastly less surprising.

I can understand the desire not to cause too much trouble for porting, but sometimes I think D places far too much emphasis on that.

Reply to Nick,

> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message
> news:gsku34$29tn$1@digitalmars.com...
> 
>> bearophile wrote:
>> 
>>> BCS:
>>> 
>>>> you spotted the issue, code porting and principle of least
>>>> surprise<
>>>> 
>>> - Code porting: If you port C code to D, it uses /* */ in a non
>>> nested way
>>> 
>> No. This is valid C:
>> 
>> /* comment /* more comment */
>> 
> That seems like a rather trivial thing to be designing our language
> around. And regarding principle of least surprise, the current /**/
> behavior is only least-surprise for people who are already familiar
> with that particular detail of /**/. From a fresher perspective, the
> /++/ behavior is vastly less surprising.
> 
> I can understand the desire not to cause too much trouble for porting,
> but sometimes I think D places far too much emphasis on that.
> 

I'd be fine depricating /**/.

On Tue, 21 Apr 2009 23:42:20 +0400, BCS <ao@pathlink.com> wrote:

> Reply to Nick,
>
>> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsku34$29tn$1@digitalmars.com...
>>
>>> bearophile wrote:
>>>
>>>> BCS:
>>>>
>>>>> you spotted the issue, code porting and principle of least surprise<
>>>>>
>>>> - Code porting: If you port C code to D, it uses /* */ in a non nested way
>>>>
>>> No. This is valid C:
>>>  /* comment /* more comment */
>>>
>> That seems like a rather trivial thing to be designing our language
>> around. And regarding principle of least surprise, the current /**/
>> behavior is only least-surprise for people who are already familiar
>> with that particular detail of /**/. From a fresher perspective, the
>> /++/ behavior is vastly less surprising.
>>  I can understand the desire not to cause too much trouble for porting,
>> but sometimes I think D places far too much emphasis on that.
>>
>
> I'd be fine depricating /**/.
>
>

You mean, deprecating /++/?

Personally, I rarely use /++/ because it feels uncommon and unstandard. I will be glad if /**/ become nestable and /++/ go away.

Reply to Denis,

>> I'd be fine depricating /**/.
>> 
> You mean, deprecating /++/?
> 

No, I mean exactly what I said. 

/**/ has well defined semantics, changing it will cause problems that replacing it will not.

Reply to Benjamin,

> Reply to Denis,
> 
>>> I'd be fine depricating /**/.
>>> 
>> You mean, deprecating /++/?
>> 
> No, I mean exactly what I said.
> 
> /**/ has well defined semantics, changing it will cause problems that
> replacing it will not.
> 

I'd also be fine with doing nothing. What I'd not be fine with is making /**/ nest.

"BCS" <ao@pathlink.com> wrote in message news:78ccfa2d3e7918cb909fe7a39778@news.digitalmars.com...
> Reply to Denis,
>
>>> I'd be fine depricating /**/.
>>>
>> You mean, deprecating /++/?
>>
>
> No, I mean exactly what I said.
> /**/ has well defined semantics, changing it will cause problems that
> replacing it will not.
>

Are there any problems you see with it other than porting code to D? (FWIW, I've never come across any code that had a /* in between a /* and */.)