April 12, 2009
On Sat, Apr 11, 2009 at 7:36 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
> I wonder what a good name would be.

How about...

umm...

oh I don't know.  "Tuple"?
April 12, 2009
Jarrett Billingsley wrote:
> On Sat, Apr 11, 2009 at 7:36 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> I wonder what a good name would be.
> 
> How about...
> 
> umm...
> 
> oh I don't know.  "Tuple"?

That name is already taken.

http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/typecons.d#L337
April 12, 2009
On 2009-04-11 19:36:36 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Frits van Bommel wrote:
>> Andrei Alexandrescu wrote:
>>> Frits van Bommel wrote:
>>>> Andrei Alexandrescu wrote:
>>>>>     alias TypeTuple!(GENERIC_READ,
>>>>>             FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING,
>>>>>             FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
>>>>>             HANDLE.init)
>>>>>         defaults;
>>>> 
>>>> How is that a type-tuple? (As far as I can see, none of those are types...)
>>> 
>>> TypeTuple is a misnomer. A TypeTuple can contain not only types, but also compile-time expressions.
>> 
>> I know, that's what I was pointing out :).
>> I figure, you've got commit access to Phobos...
> 
> I wonder what a good name would be.

Compile time expressions, just like in a static assert and a static if? StaticTuple, obviously.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

April 12, 2009
On 2009-04-11 20:33:15 -0400, Michel Fortin <michel.fortin@michelf.com> said:

> Compile time expressions, just like in a static assert and a static if? StaticTuple, obviously.

I would add that StaticTuple justifies perfectly the use of "Tuple" as a name for runtime expression tuples (because non-static ifs and asserts take runtime expressions).

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

April 12, 2009
Jarrett Billingsley wrote:
> On Sat, Apr 11, 2009 at 7:36 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> I wonder what a good name would be.
> 
> How about...
> 
> umm...
> 
> oh I don't know.  "Tuple"?

Tuple is taken by tuples.

Andrei
April 12, 2009
Michel Fortin wrote:
> On 2009-04-11 20:33:15 -0400, Michel Fortin <michel.fortin@michelf.com> said:
> 
>> Compile time expressions, just like in a static assert and a static if? StaticTuple, obviously.
> 
> I would add that StaticTuple justifies perfectly the use of "Tuple" as a name for runtime expression tuples (because non-static ifs and asserts take runtime expressions).

That sounds good to me. If nobody opposes it, I'll make the change.

I also made a lot of breaking changes (capitalization) in std.date. The idea is to take the hit once (with the next release) and then have improved overall stability.


Andrei
April 12, 2009
On Sun, Apr 12, 2009 at 5:50 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Lars Kyllingstad wrote:
>> I think isInfinite!() should be called isInfiniteRange!(). The current
>> name is, in my opinion, too general.
>
> I'm undecided about this (and similar cases). isInfinite sits inside std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange feels redundant. On the other hand, I don't want to use too common symbols because then the user will be forced to prefix them whenever they clash.

This is one of the big reasons why "static import" by default would have been better than pull-everything-in by default.

But since pull-everything-in *is* the default.  I agree with Lars. Symbols supplied by modules should look unambiguous even when undecorated by their module name.  Or you could use the trick that Tango often uses -- make a static struct with a few members.  It's pretty ugly though, if you ask me.  Introducing a static struct just to get a namespace to replace the namespace that is already there but gets stripped as the default action upon 'import'.  Ick.

--bb
April 12, 2009
Bill Baxter Wrote:

> On Sun, Apr 12, 2009 at 5:50 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> > Lars Kyllingstad wrote:
> >> I think isInfinite!() should be called isInfiniteRange!(). The current
> >> name is, in my opinion, too general.
> >
> > I'm undecided about this (and similar cases). isInfinite sits inside std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange feels redundant. On the other hand, I don't want to use too common symbols because then the user will be forced to prefix them whenever they clash.
> 
> This is one of the big reasons why "static import" by default would have been better than pull-everything-in by default.
> 
> But since pull-everything-in *is* the default.  I agree with Lars. Symbols supplied by modules should look unambiguous even when undecorated by their module name.  Or you could use the trick that Tango often uses -- make a static struct with a few members.  It's pretty ugly though, if you ask me.  Introducing a static struct just to get a namespace to replace the namespace that is already there but gets stripped as the default action upon 'import'.  Ick.
> 
> --bb

There's no need for imported names to be unambiguous. Users can give aliases to imports or import specific members. I hate how Tango puts stuff in structs for no good reason
April 12, 2009
Bill Baxter wrote:
> On Sun, Apr 12, 2009 at 5:50 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> Lars Kyllingstad wrote:
>>> I think isInfinite!() should be called isInfiniteRange!(). The current
>>> name is, in my opinion, too general.
>> I'm undecided about this (and similar cases). isInfinite sits inside
>> std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange
>> feels redundant. On the other hand, I don't want to use too common symbols
>> because then the user will be forced to prefix them whenever they clash.
> 
> This is one of the big reasons why "static import" by default would
> have been better than pull-everything-in by default.
> 
> But since pull-everything-in *is* the default.  I agree with Lars.
> Symbols supplied by modules should look unambiguous even when
> undecorated by their module name.  Or you could use the trick that
> Tango often uses -- make a static struct with a few members.  It's
> pretty ugly though, if you ask me.  Introducing a static struct just
> to get a namespace to replace the namespace that is already there but
> gets stripped as the default action upon 'import'.  Ick.


This could be easily fixed by changing the import statement such, that the module name is used as namespace:

import some.mypackage.mymodule;

mymodule.somefunctionfrommymodule();

This is a bit different from static imports, that require the full package path, and it's exactly like you use Tango modules.

> --bb
April 12, 2009
Andrei Alexandrescu:
> That sounds good to me. If nobody opposes it, I'll make the change.

StaticTuple sounds acceptable.
(I have used "Tuple" instead of "StaticTuple" and "Record" instead of "Tuple").

Bye,
bearophile