<FromGitter>
<acook> Well, none of those methods are problems. It's the efficient use of `Array#+`, `Array#|` and methods like that. I could just modify them by hand but I don't want to fall out of sync with the official release.
<FromGitter>
<HertzDevil> @asterite just remembered `&.` in ruby is now the try operator so it can't be the short block syntax for them anymore
<FromGitter>
<HertzDevil> so `x.flat_map &.itself` in ruby is our `x.flat_map.try &.itself`, while `x.flat_map(&.itself)` is a syntax error
<FromGitter>
<HertzDevil> i specifically avoided it because i had at least one occasion where i couldn't use anything newer than like 2.0
<FromGitter>
<Blacksmoke16> think thats moreso just returning the set value
<FromGitter>
<HertzDevil> also `if _ = 1; end` is legal
<FromGitter>
<oprypin:matrix.org> yes why not
<FromGitter>
<acook> Looks like there's a number of bugs that I might be stepping on the toes of, including possibly #9755. In #9874 there's a comment about "Inheritance of generics types is broken" and I'm unclear on which issue number is the one that encompasses that work.
<FromGitter>
<Blacksmoke16> subclassing built in types like array or hash, etc is usually not a good idea
<FromGitter>
<acook> I've also seen the comment "we should never allow subclassing any of the stdlib containers".
<FromGitter>
<Blacksmoke16> sounds about right
<FromGitter>
<acook> It feels silly to have to reimplement types to add functionality without affecting their namespace.
<FromGitter>
<Blacksmoke16> i mean you can have a container of your custom type that you can define your custom methods on, then just do like `forward_missing_to @internal_array` or whatever
<FromGitter>
<Blacksmoke16> so it would use your methods first, but fallback on something else
<FromGitter>
<acook> Sure, but then all methods will have to be wrapped to return values that don't accidentally return the underlying type.
<FromGitter>
<acook> I've done this work before in Ruby, wrapping all problematic method calls with a "wrap" function. But I did that for a test tool, and adding those layers affects performance.
<FromGitter>
<Blacksmoke16> :shrug: depends on what your exact use case is
<FromGitter>
<Blacksmoke16> fwiw, `find_and_map` could be implemented with `compact_map`
<FromGitter>
<Blacksmoke16> wait nvm
<FromGitter>
<Blacksmoke16> why is it called `find_and_map` if it just finds and not maps?
<FromGitter>
<acook> It finds and maps. It returns the first value which returns truthy, like find, but instead of returning the original element, it returns the value like map.
<FromGitter>
<acook> `compact_map`with `.first` could give a similar but much less efficient effect, sure.
<FromGitter>
<Blacksmoke16> idt `map` is the right word tho
<FromGitter>
<Blacksmoke16> map assumes it returns an array
<FromGitter>
<acook> Hmm, that's a valid point
<FromGitter>
<acook> Wait does `find` work differently in Crystal than Ruby? I didn't check, I just ran the tests to make sure my implementation worked.
<FromGitter>
<Blacksmoke16> pretty sure they're the same. It returns the element for which the block is true
<FromGitter>
<acook> "No" was to my comment, I would say "yes" to you :)
<FromGitter>
<Blacksmoke16> but id argue having the block control both what value is returned and the return value is kinda confusing
<FromGitter>
<acook> I should add the `if_none` feature fallback like `#find`
<FromGitter>
<acook> Maybe? It's been useful to me over the many years I've had the Ruby gem. I just brought it forward into Crystal.
<FromGitter>
<acook> I think renaming it for clarity would be great. Do you have a suggestion?
<FromGitter>
<Blacksmoke16> not really
<FromGitter>
<Blacksmoke16> doesnt hurt to put it out there. But imo few extra chars you save isn't worth it
<sorcus>
Blacksmoke16: Yeah, but maybe someone will find his shard useful :-)
<FromGitter>
<Blacksmoke16> sure, hence why i said it doesnt hurt to put it out there
<FromGitter>
<acook> I just figure everyone someone says "that doesn't belong in the stdlib" and then people don't feel like their one suggestion is worth a whole shard, a lot of those ideas for ways to improve the ergonomics and usefulness of built in types. I'd like to find the cleanest and most efficient way to do that for Crystal.
<sorcus>
acook: :thumbs_up:
<FromGitter>
<acook> Like Hashie for Ruby's Hashes and to a lesser extent ActiveSupport. But I feel dirty even mentioning AS. D:
<FromGitter>
<alexherbo2> how to delete a list of items in an array?
<FromGitter>
<alexherbo2> I guess using a delete in `each` will mess the iterating. I was going to iterate and store the indices of handled arguments to delete, and looking for a `delete_at` method accepting a list of indices, but it takes only one indice.
<FromGitter>
<alexherbo2> my use case is to add a method to post-parse the rest of arguments, to handle `+<line>` and `+<line>:<column>`
<yxhuvud>
alexherbo2: array1 - array2.
<FromGitter>
<alexherbo2> the method `parse_coordinates(argv)` should modify in-place the `argv`, like the `option_parser`