On 2013-02-26 21:13, Jonathan M Davis wrote:

> Really? There are a few (particularly older ones), but for the most part, I'd
> argue that that's not the case at all. In general, IMHO, Phobos does an
> excellent job of having function names that are reasonably descriptive and are
> of a reasonable length. And, if anything, we tend to err on the side of being
> too long (e.g. ElementEncodingType).
>
> - Jonathan M Davis
>

These are just a couple:

std.string
icmp
makeTrans
succ
abbrev

std.array
assocArray

std.file
isDir
attrIsDir
attrIsFile
attrIsSymlink
dirEntries

std.uni
lineSep
paraSep

std.datetime
currTime
Every member of the Month, DayOfWeek and Direction enums.
fracSec

-- 
/Jacob Carlborg

On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg wrote:
> On 2013-02-26 21:13, Jonathan M Davis wrote:
> > Really? There are a few (particularly older ones), but for the most part, I'd argue that that's not the case at all. In general, IMHO, Phobos does an excellent job of having function names that are reasonably descriptive and are of a reasonable length. And, if anything, we tend to err on the side of being too long (e.g. ElementEncodingType).
> > 
> > - Jonathan M Davis
> 
> These are just a couple:
> 
> std.string
> icmp
> makeTrans
> succ
> abbrev
> 
> std.array
> assocArray
> 
> std.file
> isDir
> attrIsDir
> attrIsFile
> attrIsSymlink
> dirEntries
> 
> std.uni
> lineSep
> paraSep
> 
> std.datetime
> currTime
> Every member of the Month, DayOfWeek and Direction enums.
> fracSec

And in almost all cases, I see nothing to complain about here. Most of them are quite clear as they are. Making them longer would just make them longer to no real benefit IMHO, and it _would_ be adding a cost. You seem to think that abbreviations are bad, and I completely disagree. IMHO, a symbol name should be as long as it needs to be in order to be clear and no longer, and as long as an abbreviation is clear, then it's great to use it. But if you have problems with most of those names, then I think that it's pretty clear that we're just going to have to agree to disagree on this, because for the most part, I think that they're great as they are.

- Jonathan M Davis

On Wednesday, 27 February 2013 at 23:17:42 UTC, Jonathan M Davis wrote:
> On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg wrote:
>> On 2013-02-26 21:13, Jonathan M Davis wrote:
>> > Really? There are a few (particularly older ones), but for the most part,
>> > I'd argue that that's not the case at all. In general, IMHO, Phobos does
>> > an excellent job of having function names that are reasonably descriptive
>> > and are of a reasonable length. And, if anything, we tend to err on the
>> > side of being too long (e.g. ElementEncodingType).
>> > 
>> > - Jonathan M Davis
>> 
>> These are just a couple:
>> std.datetime
>> currTime
>> Every member of the Month, DayOfWeek and Direction enums.
>> fracSec

Would 'now' be even better than 'currTime'?

On Thursday, February 28, 2013 01:38:17 Zach the Mystic wrote:
> On Wednesday, 27 February 2013 at 23:17:42 UTC, Jonathan M Davis
> 
> wrote:
> > On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg wrote:
> >> On 2013-02-26 21:13, Jonathan M Davis wrote:
> >> > Really? There are a few (particularly older ones), but for
> >> > the most part,
> >> > I'd argue that that's not the case at all. In general, IMHO,
> >> > Phobos does
> >> > an excellent job of having function names that are
> >> > reasonably descriptive
> >> > and are of a reasonable length. And, if anything, we tend to
> >> > err on the
> >> > side of being too long (e.g. ElementEncodingType).
> >> > 
> >> > - Jonathan M Davis
> >> 
> >> These are just a couple:
> >> std.datetime
> >> currTime
> >> Every member of the Month, DayOfWeek and Direction enums.
> >> fracSec
> 
> Would 'now' be even better than 'currTime'?

I don't think so (other than maybe due to the fact that it's shorter), though I know that some people would think so. But it never even occurred to me to call it that when I wrote it, and I don't think that anyone ever brought it up during the review process.

Regardless, currTime works just fine, and even if now would have been better, it's not even vaguely worth it to rename it at this point.

- Jonathan M Davis

On Thursday, 28 February 2013 at 01:04:00 UTC, Jonathan M Davis wrote:
> On Thursday, February 28, 2013 01:38:17 Zach the Mystic wrote:
>> On Wednesday, 27 February 2013 at 23:17:42 UTC, Jonathan M Davis
>> 
>> wrote:
>> > On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg wrote:
>> >> On 2013-02-26 21:13, Jonathan M Davis wrote:
>> >> > Really? There are a few (particularly older ones), but for
>> >> > the most part,
>> >> > I'd argue that that's not the case at all. In general, IMHO,
>> >> > Phobos does
>> >> > an excellent job of having function names that are
>> >> > reasonably descriptive
>> >> > and are of a reasonable length. And, if anything, we tend to
>> >> > err on the
>> >> > side of being too long (e.g. ElementEncodingType).
>> >> > 
>> >> > - Jonathan M Davis
>> >> 
>> >> These are just a couple:
>> >> std.datetime
>> >> currTime
>> >> Every member of the Month, DayOfWeek and Direction enums.
>> >> fracSec
>> 
>> Would 'now' be even better than 'currTime'?
>
> I don't think so (other than maybe due to the fact that it's shorter), though
> I know that some people would think so. But it never even occurred to me to
> call it that when I wrote it, and I don't think that anyone ever brought it up
> during the review process.
>
> Regardless, currTime works just fine, and even if now would have been better,
> it's not even vaguely worth it to rename it at this point.
>
> - Jonathan M Davis

Into my cryogenic idealistic freezer it goes!

On 2013-02-28 01:38, Zach the Mystic wrote:

> Would 'now' be even better than 'currTime'?

I think so.

-- 
/Jacob Carlborg

On Thursday, 28 February 2013 at 08:07:28 UTC, Jacob Carlborg wrote:
> On 2013-02-28 01:38, Zach the Mystic wrote:
>
>> Would 'now' be even better than 'currTime'?
>
> I think so.

Be careful what you say, or you might have to go into my cryogenic freezer as well!