On Thursday, 25 June 2015 at 03:15:58 UTC, Andrew Gough wrote:
> On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote:
>> On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
>>> A rename can be proposed by creating a subthread: [...]
>>
>> Rationale:
>>
>> As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word "Case" is omitted. The distinction is not memorable.
>>
>> Proposed new name: lowerCased / upperCased
>
> I love painting bike sheds!
>
> An eager version implies present tense: split, join etc
>
> A lazy version implies future tense: willSplit, willJoin, etc

And hence: willUpperCase, willLowerCase

On Thursday, 25 June 2015 at 03:12:47 UTC, Steven Schveighoffer wrote:
> A curious thing though. All the tests for things like:
>
> assert(setExtension("file", "ext") == "file.ext");
>
> do not trigger a call to eager.

But it passes? That's bizarre. (My dmd is apparently too old to compile this, it segfaults when I try!)

> assert(setExtension("file", "ext").array == "file.ext");

I did experience this in my proof-of-concept because I didn't implement .length. So when array checked hasLength, it found it through the alias this, which called eager. (That's also why I did a foreach loop instead of just returning array(this). Well, that and the auto-decode nonsense, but array would be a recursive call and stack overflow anyway).

But since you did implement a length function, that shouldn't be happening. Maybe it passes the check in StringTypeOf though: is(T : const char[]) might pass due to the alias this too. Not sure.

(An interesting point here though is since alias this DOES return a string, any duck-type checks or implicit conversion checks will also pass what it passes... and work, it'll just silently allocate the string. Which is no regression! The status quo is it allocates that string EVERY time anyway. But it also isn't ideal. Someone earlier said we can probably apply @nogc to everything but the eager method. I think that'd work, and then at least the allocations wouldn't be silent anymore - the @nogc attribute at the call site can catch them.)



These two things are weird, but I'm sure they're just bugs that we can handle. In the morning, I'll try a git dmd and see if I can play with it a little, right now I'm just guessing since it won't build on my current setup.

On Thursday, 25 June 2015 at 03:40:31 UTC, Adam D. Ruppe wrote:
> (An interesting point here though is since alias this DOES return a string, any duck-type checks or implicit conversion checks will also pass what it passes... and work, it'll just silently allocate the string. Which is no regression! The status quo is it allocates that string EVERY time anyway. But it also isn't ideal.

That depends entirely on what the templated function that it's being used with does. In general, implicit conversions in generic code is an incredibly bad idea. Almost inevitably what happens is that folks assume that because the type is implicitly convertible, it can be treated like the type that it implicitly converts to - but that often isn't true at all. It just means that you can convert it to that type and then use it as that type rather than its original type. So, if a function checks for implicit conversion and then forces that conversion, then it can work, but it needs to force the conversion. Otherwise, it'll either fail to compile when used with types that use alias this, or you'll end up with weird, hybrid behavior where some of the operations might use the actual type, whereas others use the converted type. In general, I think that using implicit conversions in generic code is a disaster.

So, yes, if we use a struct like this, then in code which ends up assigning the result to a string (or passing it to a function which explicitly takes a string), then the implicit conversion will take place, and everything should work fine. However, in any code that assumes that it's dealing with strings but doesn't actually use the type string anywhere, it's not going to implicitly convert to string, and you could easily end up with templated functions which test with isSomeString or similar and thus fail to compile, because they wouldn't do the implicit conversion in that case (the duck typing sees that the struct _isn't_ a string). As long as the functions work with general ranges of dchar, they should be fine (possibly less performant if too much autodecoding is going on, but the lack of allocation may make up for that), but any generic code that assumes strings without specifically using the type string is in trouble. How much of a concern that really is, I don't know. But I would not expect much code that involves duck typing to be converting the struct to string, and in general, I would be very worried about any generic code that involved implicit conversions.

But this should work just fine when used with non-generic code that's operating on strings or with generic code that operates on ranges of dchar and not necessarily just strings.

- Jonathan M Davis

On Wednesday, 24 June 2015 at 20:03:35 UTC, Vladimir Panteleev wrote:
> On Wednesday, 24 June 2015 at 13:35:06 UTC, Vladimir Panteleev wrote:
>> The problem with toXCase is that there is neither a noun for an upper-case transform, nor a verb for such an operation, such as e.g. "capitalization" and "capitalize", so I think we should look at it separately.
>
> Well, I suppose simply "upperCase" and "lowerCase" are an options, if you squint your eyes and pretend they're verbs.

Of course, even if you consider these acceptable on their own, they don't really solve the problem of being memorably distinguishable from toLower / toUpper.

On Wednesday, 24 June 2015 at 21:06:43 UTC, deadalnix wrote:
>> I'd like to raise concern about the Arguments name in std.meta . That is not the first time I do so, but this still needs to change.

I haven't participated with the discussion but I agree with the points in your post.

>> I discussed various names with many at DConf. The name that seemed to be, if not preferred by all, the one that nobody had any strong reason to be against is Sequence. Can we use that ?

There is std.range.Sequence, though.

> Also, I'm not sure why TypeTuple is introduced in std.meta "for legacy compatibility" as the module is brand new.

I think it can be moved back to std.typetuple?

On Wednesday, 24 June 2015 at 22:12:10 UTC, Brad Anderson wrote:
> On Wednesday, 24 June 2015 at 22:11:03 UTC, Brad Anderson wrote:
>> On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
>>> We disagreed on this on irc, but I ask you to consider the following which limits the code breakage a lot more than my first proposal in chat:
>>>
>>> [...]
>>
>> Couldn't this even be made @nogc by just applying it to eager()?
>>
>> Very neat. I love it.
>
> Err, everything but eager.

That would be inferred anyway, it's a template. But yes, `eager` is strictly an add-on, it doesn't after @nogc-ness of the range.

On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis wrote:
> When adding lazy versions in the past, for better or worse, we've generally gone for using nouns, whereas you're suggesting adjectives based coming from the past tense of a verb (though the verb "to case" has nothing with the case of letters).

OK, so I didn't really understand what were you referring to, since the only examples I found while looking through the *stable* documentation were joiner and splitter. But I went through the list of new symbols, and I found that a few more have been added after the last release to std.string:

en/detabber, left/right/centerJustifier, soundexer

So, one option is to stay consistent with these additions, and go with upperCaser and lowerCaser, even if those sound a bit odd.

Another option would be to rename those additions as well, so we would have:

en/detabbed, left/right/centerJustified, soundexed, upperCased, lowerCased

I don't know if this counts as being outside of the scope of this thread.

Any thoughts? Or is everyone bored to death already? :)

On 24/06/15 22:07, Suliman wrote:

> If not to look at docs I would say that size is bite size, count -
> number of elements. So what is length I can't say. Probably I missed
> length and count.

"length" and "size" are the exact same thing. They return the number of elements of an array or string. "count" is a bit more versatile, it can be called without parameters, with one parameter or with a block. If a parameter is given it will count the number of occurrences of that element. If a block is given it will pass each element to the block and count how many times it returns true. If no parameter or block is given it will work exactly like "length" and "size".

It gets event more interesting if you add ActiveRecord to the mix. The result of a query in ActiveRecord will return some form of object that acts like an array. Example:

Person.where(name: 'John').length

Will get all rows matching "John" and return how many. This on the other hand:

Person.where(name: 'John').count

Will actually perform a count query, avoid loading all objects in memory.

-- 
/Jacob Carlborg

On 24/06/15 22:56, Steven Schveighoffer wrote:

> I recently started learning ruby. Going through a tutorial, I came
> across this gem (no pun intended) when talking about how both intern and
> to_sym do the same thing:

Hmm, I didn't know about "intern". I've never seen in the wild.

> "Why have multiple ways to do the same things?
>
> Well, that's a silly question. To be able to write expressive code. A
> language that only has one way to get from A to B is not a language at
> all."
>
> Wow.

Hehe :)

-- 
/Jacob Carlborg

On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
> [...]

Same rationale as setExt/setExtension: the name difference from defaultExtension is abbreviating the word "Extension" to "Ext". Really should've been in the same thread, I simply missed it.

Suggested new name: withDefaultExtension