[elixir-core:11721] Re: Performance of local function capture

> At compile time, if it's possible, we could treat */0* as *&__MODULE__.fun/0* and get a free performance boost, if in the end they behave same. I believe local vs remote captures do not behave the same during hot code reloading. Remote calls always invoke the latest version of a module; so

Re: [elixir-core:11674] Introduce guards in MapSet

> Map, So I think some of my original concerns are no longer relevant. There > is also no need to deprecate any of the existing functions. > > On Sat, Mar 2, 2024 at 00:30 Christopher Keele > wrote: > >> MapSets are *very* useful constant time data structures; and

Re: [elixir-core:11668] Introduce guards in MapSet

MapSets are *very* useful constant time data structures; and I keep on finding myself wishing there was a future-proof approved way to use them in guards. Consider this my +1. I believe eksperimental's original rationale still holds: 1. :erlang.is_map_key/2, as well as :erlang.map_get/2, are

Re: [elixir-core:11580] Re: [Proposal] import only: :guards

on overlap, for example >> if *[:sigils, sigil_URL: 2]* was provided as a selector. >> >> On Sunday, October 22, 2023 at 12:27:21 AM UTC-5 Christopher Keele wrote: >> >>> Currently, *import , only: * accepts as a selector >>> either: >>> >>

[elixir-core:11571] Re: [Proposal] import only: :guards

. On Sunday, October 22, 2023 at 12:27:21 AM UTC-5 Christopher Keele wrote: > Currently, *import , only: * accepts as a selector > either: > >- a keyword list of functions/arities >- *:functions* to import only all functions >- *:macros* to import only all macro

[elixir-core:11570] [Proposal] import only: :guards

Currently, *import , only: * accepts as a selector either: - a keyword list of functions/arities - *:functions* to import only all functions - *:macros* to import only all macros Additionally, the selector can be *:sigils*, which only imports a specific subset macros: those known to be

[elixir-core:11522] Re: [Proposal] Warn on duplicated aliases

We'd need to go deeper with the logic here than just checking for literally "duplicated" alias calls, as aliases can impact later ones—for a contrived example, see: ``` defmodule Na.Na.Na.Na.Na.Na.Batman do def batman!, do: :batman end defmodule Test do alias Na.Na alias Na.Na alias

Re: [elixir-core:11487] [Proposal] mix build task

> Not sure how useful build with compile is, if you run mix test instead of mix compile, build won’t help it. > Phoenix standardized on setup, but it does not include the compile command. I think a standard `mix build` interface would be most useful for: - People new to Elixir just checking out

[elixir-core:11484] Re: [Proposal] mix build task

I'd make the counter-argument: mix is a build *tool*, but not your build; that's something you should define for your project. In pretty much all of my projects, I find myself writing a `mix build` alias, as a high-level one-stop-shop command, but it looks very different for each project—my

Re: [elixir-core:11477] [Proposal] Overload capture operator to support tagged variable captures

Here's a summary of feedback on this proposal so far. *Concerning the actual proposal itself* (ie, &:foo # => {:foo, foo}): 2 against re-using the capture operator. *Concerning the followup of a dedicated operator* (ie, $:foo # => {:foo, foo}): roughly 2 for and 1 against (because it was not

Re: [elixir-core:11472] [Proposal] Overload capture operator to support tagged variable captures

. On Thursday, June 29, 2023 at 4:04:16 AM UTC-5 José Valim wrote: > This is a separate convo but I don’t see value in adding a primary syntax > for sets given we can’t really use it in pattern matching. A syntax for > only adding and removing set elements is, IMO, not worth it. > >

Re: [elixir-core:11470] [Proposal] Overload capture operator to support tagged variable captures

Thursday, June 29, 2023 at 3:14:51 AM UTC-5 woj...@wojtekmach.pl wrote: > > %{foo, bar} > > Just throwing it out there that this notation would make for a very nice > MapSet literal. :) > > On 29 Jun 2023, at 10:05, Christopher Keele wrote: > > > Ther

Re: [elixir-core:11468] [Proposal] Overload capture operator to support tagged variable captures

9, 2023 at 2:59:39 AM UTC-5 Christopher Keele wrote: > > Another idea is to improve Elixir LS itself to suggest the variable name > itself after ":". So if I type "%{foo:", it immediately suggests " foo". > So, once again, easy to write, easy to read. >

Re: [elixir-core:11466] [Proposal] Overload capture operator to support tagged variable captures

e Elixir LS itself to suggest the variable name > itself after ":". So if I type "%{foo:", it immediately suggests " foo". > So, once again, easy to write, easy to read. > > On Thu, Jun 29, 2023 at 9:49 AM Christopher Keele > wrote: > >> &

Re: [elixir-core:11464] [Proposal] Overload capture operator to support tagged variable captures

at all. > > You are doing great. You defend your proposal and ideas. :) > > On Thu, Jun 29, 2023 at 9:29 AM Christopher Keele > wrote: > >> Honestly, I do not adore the syntax of the proposed solution, in either >> capture or $ operator incarnation. I would also prefer

Re: [elixir-core:11462] [Proposal] Overload capture operator to support tagged variable captures

opinion. If this thread is going to have any hope of making progress, broad >> assertions of that nature better be backed up with a lot of objective data. >> Make the case why *extra* syntax is better than the more limited >> barewords-only implementation, for example, by enabling

Re: [elixir-core:11459] [Proposal] Overload capture operator to support tagged variable captures

original pain points of this feature that future barewords support would not: 2) Visual clarity <https://groups.google.com/g/elixir-lang-core/c/XxnrGgZsyVc/m/NBkAVto0BAAJ> that atom/string matching is occurring 4) Easy confusion <https://groups.google.com/g/elixir-lang-core/c/XxnrGgZs

Re: [elixir-core:11458] [Proposal] Overload capture operator to support tagged variable captures

ifficult, but still much more tractable than re-appropriating the capture operator. On Thursday, June 29, 2023 at 12:16:23 AM UTC-5 Christopher Keele wrote: > > Perhaps in an ideal Elixir 2.0 future if we get garbage collection of > atoms like Ruby, Phoenix can move over to parsing pa

Re: [elixir-core:11457] [Proposal] Overload capture operator to support tagged variable captures

2023 at 11:40:39 PM UTC-5 Christopher Keele wrote: > > This proposal mentions OCaml, Haskell and JS as prior works of art for > > this type of feature. I think a key thing to point out is that in those > > languages, they did not need to add additional syntax in order to

Re: [elixir-core:11456] [Proposal] Overload capture operator to support tagged variable captures

> This proposal mentions OCaml, Haskell and JS as prior works of art for > this type of feature. I think a key thing to point out is that in those > languages, they did not need to add additional syntax in order to > support this. This is true, and the discomfort extends to Ruby as well. For

Re: [elixir-core:11454] [Proposal] Overload capture operator to support tagged variable captures

Specifically, we expanded an undefined variable foo to a function call foo(), warned about the expansion, then reported a compile-time error about the missing function, instead. On Wednesday, June 28, 2023 at 11:13:18 PM UTC-5 Christopher Keele wrote: > The above is how we dealt with undefi

Re: [elixir-core:11453] [Proposal] Overload capture operator to support tagged variable captures

The above is how we dealt with undefined variable references until recently (I think 1.15?): warn about the problematic expansion, error on the expanded syntax. On Wednesday, June 28, 2023 at 11:05:00 PM UTC-5 Christopher Keele wrote: > An alternative would be to prepend compiler iss

Re: [elixir-core:11452] [Proposal] Overload capture operator to support tagged variable captures

iex:12:47: # !> ┌─ error: iex:12:47 # !> 12 │ %{:foo => foo, "fizz" => "buzz", "bar" => bar, fizz: :buzz, :baz => baz} # !> │ ^ # !> │ # !> unexpected expression after keyword list. Keyword lists must always come

Re: [elixir-core:11451] [Proposal] Overload capture operator to support tagged variable captures

^ # !> │ # !> unexpected expression after keyword list. Keyword lists must always come last in lists and maps. # !> # !> Syntax error after: ',' On Wednesday, June 28, 2023 at 10:44:44 PM UTC-5 Christopher Keele wrote: > Posted that last reply ea

Re: [elixir-core:11450] [Proposal] Overload capture operator to support tagged variable captures

!> [some: :value, :another] # !> %{some: :value, another => value} # !> # !> Instead, reorder it to be the last entry: # !> # !> [:another, some: :value] # !> %{another => value, some: :value} # !> # !> Syntax error after: ',' On We

Re: [elixir-core:11449] [Proposal] Overload capture operator to support tagged variable captures

t;` or `$:key` / `$"key"` will work > very nicely for this feature, although it would be nice to have `:` or > `$key:` work the same as the former version. Alternatively, the `$` symbol > could be used at the beginning of the data structure to indicate that it

Re: [elixir-core:11447] [Proposal] Overload capture operator to support tagged variable captures

, %{$"chat", $"question_id", $"data", $"attachment", ...}, socket) do... On Wednesday, June 28, 2023 at 9:42:13 PM UTC-5 Christopher Keele wrote: > Again, for the purposes of the code examples above, assume: > > {foo, bar} = {1, 2} > > Additi

Re: [elixir-core:11446] [Proposal] Overload capture operator to support tagged variable captures

ing with *# !> * represent an exception. On Wednesday, June 28, 2023 at 9:30:41 PM UTC-5 Christopher Keele wrote: > I've figured out the tokenizer enough to prototype this as new operator; > working title the "tagged variable literal" operator (not in love with that > name)

Re: [elixir-core:11445] [Proposal] Overload capture operator to support tagged variable captures

t, so I don't want to derail your proposal here, or add > to the noise, particularly with regard to the "tagged variable captures" > portion, which deserves its own consideration. I will leave it up to the > community at large to decide, but just want to say thanks again for putting

Re: [elixir-core:11443] [Proposal] Overload capture operator to support tagged variable captures

ooting for this, because then I might be able to do tricky things to allow literal $1 and $$ Elixir syntax in my elixir-to-matchspec compiler <https://github.com/christhekeele/matcha/discussions/61>. On Wednesday, June 28, 2023 at 8:10:37 PM UTC-5 Christopher Keele wrote: > > My p

Re: [elixir-core:11442] [Proposal] Overload capture operator to support tagged variable captures

me:password@host:5432/database_name?schema=public") [$uri.host, $uri.port] #=> [host: "host", port: 5432] However, I wanted to keep the initial proposal simple and focused on the most commonly desired functionality. On Wednesday, June 28, 2023 at 8:02:01 PM UTC-5 Christopher

Re: [elixir-core:11441] [Proposal] Overload capture operator to support tagged variable captures

but it feels expressive to me, and the $ currently >> has no use in mainstream elixir syntax (its used in ets match specs as a >> value, not as an operator). That seems like a good solution to me. >> >> >> On Wed, Jun 28, 2023 at 8:45 PM, Christopher Keele < >

Re: [elixir-core:11438] [Proposal] Overload capture operator to support tagged variable captures

more difficult to teach and learn. > > That’s my two cents anyway, I think you did a great job with the proposal, > but I’m very solidly against it as the solution to the problem being solved. > > Paul > > > > On Wed, Jun 28, 2023, at 7:56 PM, Christopher Keele wrote: &g

[elixir-core:11436] Re: [Proposal] Overload capture operator to support tagged variable captures

arch on keyboards over the years, most the commonly-used keyboards have it, and because of the prevalence in other language's syntax, most programmers have solutions to typing it regardless. On Wednesday, June 28, 2023 at 6:56:18 PM UTC-5 Christopher Keele wrote: > This is a formal

[elixir-core:11435] [Proposal] Overload capture operator to support tagged variable captures

This is a formalization of my concept here , as a first-class proposal for explicit discussion/feedback, since I now have a working prototype

Re: [elixir-core:11434] [Proposal] Syntax sugar for Maps construction and pattern matching

This is a decade-old discussion at this point, and one I've avoided participating in much because I've historically viewed the problem as untractable, and did not have much to contribute. We want a syntax sugar construct that can interact with the variable binding scope, that visually feels

Re: [elixir-core:11395] Proposal: Add ~URI sigil

I dislike +1 posts, but I feel very strongly about this—it'd be amazing to have. I want booting an application to fail as fast and obviously as possible if someone gives it a bad phoenix host url, ecto database url, rabbitMQ url, redis url, mongodb url, etc. Preferably, before the connection

Re: [elixir-core:11382] [Proposal] Enhancements in the API for optional dependencies

> Is there any particular issue with the information I shared that wouldn't help with the situation? Your thoughts are compelling and merit discussion! It's just that there's a slippery slope in proposal conversations: between discussing *a specific* proposal (in this instance, Michal's

Re: [elixir-core:11355] Maps and merge behaviour in Config

I can second that this has caught me off-guard before as well, and keyword list support would be a welcome addition. > It can be confusing if folks then use the direct Erlang APIs. I think this could be circumvented for now by only describing the proposed keyword list support in the boot

Re: [elixir-core:11233] Re: Formatting of module attributes

about columns. On Thursday, December 29, 2022 at 12:54:02 AM UTC-6 Christopher Keele wrote: > > the Elixir formatter does not change the AST by default > > Ah, this makes sense. The whitespace in a sigil is part of the AST > (unlike, say, a list literal) so it must stay put. >

Re: [elixir-core:11232] Re: Formatting of module attributes

> the Elixir formatter does not change the AST by default Ah, this makes sense. The whitespace in a sigil is part of the AST (unlike, say, a list literal) so it must stay put. It feels like that this soft guarantee is *not* exactly upheld by the formatter's treatment of heredoc strings, which

[elixir-core:11230] Re: Formatting of module attributes

to reason about how it should format its contents with respect to indentation. On Wednesday, December 28, 2022 at 4:49:49 PM UTC-6 Christopher Keele wrote: > This feels like a feature request to me: I understand why sigils are > generally not touched by the formatter without plugins, but I fee

[elixir-core:11229] Re: Formatting of module attributes

This feels like a feature request to me: I understand why sigils are generally not touched by the formatter without plugins, but I feel like the sigil_w included in the standard library should have smarter formatting by default. *NOTE: I'm using Elixir 1.14.2 here to observe the behaviour of

Re: [elixir-core:11199] Re: Proposal: Introduce string limit function.

> Yeah, features vs functions make sense that they would have different leeway, and I think maybe deserves its own rubric. It'd be interesting to see a PR that introduces a new .md file in the language repo (or adds to DEVELOPMENT.md) that provides some guidance here. Then we can continue the

Re: [elixir-core:11161] A More Human DateTime Comparison API

> DateTime.is?(a, operator, b), when operator :lt | :le | :eq | :ge | :gt, which would capture the :le and :ge options. > I like the :inclusive option if the need ever arises. If we combine these proposals, we'd only need the exact options that DateTime.compare already returns (:lt | :eq |

Re: [elixir-core:11058] Re: Proposal: Date.parse_date(String.t(), "%d/%m/%Y") to parse custom date formats defined in strftime

There is some related discussion on this in this thread . Some relevant take-aways are that even in the context of the most common standard formatting, it is hard™️ to get correct and not trivial to optimize (see: the

[elixir-core:10906] Re: Describe the return value of `Stream.each/2` in its docs?

I think expanding on the `Stream.each/2` docs to clarify that it returns the provided enumerable unchanged, and pointing to `Stream.map/2` if producing a modified stream is desired, would be a welcome enhancement! On Friday, May 27, 2022 at 11:10:55 AM UTC-4 kenny...@gmail.com wrote: > Other

Re: [elixir-core:10852] [Proposal] - Add an option to deps.get to force failure on lock mismatch

I took a really quick look to see what the most naive approach would look like (literally before/after compare the mix.lock file, or rather the map representing it before final write-back). I originally had a whole write-up documenting how this simple lockfile-change-checking strategy would

Re: [elixir-core:10695] ExUnit: async exclusion groups instead of async off

> async: true | false | {:async_within, :group} | {:async_outside, :group} Best ideas I can come up with are *async: {isolate: :group}*, and *async: {alongside: :group}*, but not sure how much better that is. On Wednesday, January 5, 2022 at 8:39:39 AM UTC-5 José Valim wrote: > To be clear, I

Re: [elixir-core:10662] Introduce let and reduce qualifiers to for

*Guides Feedback* These look excellent, should make the power of *for* much more accessible. *let Feedback* I like the functionality of this proposal much more! I will say, I'm still not a fan of using new qualifiers. I'm not sure why we need to introduce a new special form for this, since we

Re: [elixir-core:10621] Introduce :let in for-comprehensions

>> that, by introducing special syntax, I believe most would expect it to be >> fully mutable, so you can modify it from any scope. That's why I decided >> to go with plain variables, because they already have a limited scope in >> Elixir and clear rules (but at the same time I

Re: [elixir-core:10618] Introduce :let in for-comprehensions

I love the thought put into this proposal, and really like the problem it is tackling! I am looking forward to the next proposal and will try to get to my inbox earlier for it. *Proposal Feedback* I mostly second the impressions voiced here, but *really* want to call attention to the

Re: [elixir-core:10553] ExUnit: async exclusion groups instead of async off

--include db_case2:true Would this approach solve what you are trying to do? On Tuesday, November 30, 2021 at 11:43:48 AM UTC-5 Christopher Keele wrote: > Not weighing in on the intent here, but the mechanism: > > It probably makes sense to leverage the existing tagging mechanism here. &

Re: [elixir-core:10552] ExUnit: async exclusion groups instead of async off

Not weighing in on the intent here, but the mechanism: It probably makes sense to leverage the existing tagging mechanism here. We could then just configure ExUnit like: use ExUnit.Case On Tuesday, November 30, 2021 at 7:28:09 AM UTC-5 pdgi...@gmail.com wrote: > Sorry for the delay in

Re: [elixir-core:10427] Re: Proposal: built-in DynamicSupervisor partitioning

This sounds great to me. A couple of thoughts: 1. *DynamicSupervisor.start_link(__MODULE__, :ok, partitions: 8)* — should we default partitions to *1*? Technically a more aggressive value would be acceptable, since the goal is for this to be a transparent improvement to DynamicSupervisor.

Re: [elixir-core:10409] Proposal: "Dependency Groups" or "one of these dependencies is required, w/ a default"

The current idiom for this that José mentions is, in my opinion, superior to the proposed approach. It is still declarative, but at the code level rather than a data-driven config level within mix, which makes it much more flexible. Ie, it lets more complicated checks occur, can reference

[elixir-core:10380] Re: [Proposal] Use different exit codes for compilation errors versus test failures

This is a compelling notion to me. I'd prefer an implementation where the default was generic and the use-case was specific; ie have the complier return 1's for compilation errors/other, and have specific CLI use-cases extend the semantics, like mix test returning 2 for test failures. On

Re: [elixir-core:10330] [Proposal] Strict matching comprehensions

1:51:11 PM UTC-7 Allen Madsen wrote: > Re: Christopher Keele > > > Another option would be extending *for* to accept matches and set > bindings in its macro's list of clauses, like *with* (which also mixes > *<-* with *=*) > > This is already supported. You can do: > >

Re: [elixir-core:10328] [Proposal] Strict matching comprehensions

ithin the block. I agree I'd prefer this convention over the addition of new constructs or operators increasing the surface area language, but if it was added to the language I'd use the feature since I imagine that'd become the new convention. On Tuesday, June 15, 2021 at 11:47:18 AM UTC-7 Chris

Re: [elixir-core:10327] [Proposal] Strict matching comprehensions

h feels like a big change. >>>> >>>> >>>> Best >>>> >>>> Adam >>>> >>>> >>>> >>>> >>>> On 11 Jun 2021, at 00:13, Paul Schoenfelder >>>> wrote: >>>> >>>&

[elixir-core:10318] Re: [Proposal] {Enum, Stream}.zip_all

Not commenting on the feature itself, but I believe there's a convention in the collection stdlib of keeping the same function names, but accept an extra parameter, for default values. See: - Enum.find/3 - Enum.find_value/3 - Map.pop/3 - Keyword.get/3 On Sunday, June 13, 2021 at

Re: [elixir-core:10307] [Proposal] Strict matching comprehensions

omeone reading the code. The strict option is modifying > the behavior of the operator <-, which may be quite before it in the text. > > I prefer for! in this case as it is upfront. > > On Fri, Jun 11, 2021 at 00:09 Christopher Keele > wrote: > >> > My concern with

Re: [elixir-core:10306] [Proposal] Strict matching comprehensions

the behavior considerably of > the generators but it may show up only quite later on, far from them, > especially if you have multiple filters. > > On Thu, Jun 10, 2021 at 23:56 Christopher Keele > wrote: > >> > for {:ok, num} <- list, strict: true, do: num >&g

Re: [elixir-core:10304] [Proposal] Strict matching comprehensions

y two cents is `for!` makes the most sense, and follows the conventions >> of other functions. >> >> Best >> >> Adam >> >> On 8 Jun 2021, at 18:18, Christopher Keele wrote: >> >> This feature would be very useful, I've experience this signa

[elixir-core:10301] Re: [Proposal] Strict matching comprehensions

This feature would be very useful, I've experience this signature-change pain point before too (and kind of have been avoiding `for` ever since, TBH). I'm reluctant to increase the surface area of the language itself, what do you think about adding a `:strict` option to `for` instead of a new

Re: [elixir-core:10289] [Proposal] `mix xref` improvements to detect problematic dependencies

> I like --fail-above. --fail-at may read like it should be exactly 1. --fail-above is really nice. I couldn't think of a concise term for --fail-at-or-over, and --fail-over is the only term I could come up with which is obviously cognitively overloaded already. On Thu, Jun 3, 2021 at 11:39 AM

Re: [elixir-core:10287] [Proposal] `mix xref` improvements to detect problematic dependencies

> > About 4, what if we call it --fail-if-any? Or alternatively, --at-most=0 (and you can set it to any positive integer)? > `at-most` is short and sweet  I think it's important for this flag name to communicate that it will cause a failure. at-most sounds like it would simply limit graph

Re: [elixir-core:10268] [Proposal] Add a Float.nearly_equal? function.

y 20, 2021 at 8:12:20 PM UTC-7 Christopher Keele wrote: > > It doesn't behave very well with pattern matching. This could of course > be rectified by making it usable as a function clause ala: > > def float_stuff(x, y) when nearly_equal?(x, y, 5), do ... > > I wanted to see if

Re: [elixir-core:10267] [Proposal] Add a Float.nearly_equal? function.

> It doesn't behave very well with pattern matching. This could of course be rectified by making it usable as a function clause ala: > def float_stuff(x, y) when nearly_equal?(x, y, 5), do ... I wanted to see if the algorithm described in the linked article

[elixir-core:10259] Re: [Question] mix depencency behavior

If you're executing Elixir code within the context of the mix project, you can invoke Mix.Project.deps_paths/{0,1} to figure this out. On Tuesday, May 11, 2021 at 8:45:38 PM UTC-7 raphael...@gmail.com wrote: > > Hi! > > There is an

Re: [elixir-core:10255] Re: [Proposal] Don't update git dependency when only origing is changed

e dependency that I use which…doesn’t because the version > is set by the automated release process). > > -a > > On Mon, May 10, 2021 at 2:18 PM Christopher Keele > wrote: > > > > I would argue that today's behaviour is correct. > > > > Conceptually, a depe

Re: [elixir-core:10253] Re: [Proposal] Don't update git dependency when only origing is changed

git dependency origins often? On Monday, May 10, 2021 at 11:18:55 AM UTC-7 Christopher Keele wrote: > I would argue that today's behaviour is correct. > > Conceptually, a dependency's *version* is only part of its identity; its > *source* is the other component. When either changes, m

Re: [elixir-core:10252] Re: [Proposal] Don't update git dependency when only origing is changed

I would argue that today's behaviour is correct. Conceptually, a dependency's *version* is only part of its identity; its *source* is the other component. When either changes, mix should re-install. I'll bring up a few examples below. Note that I bring them up less because they'd be common in

Re: [elixir-core:10233] [Proposal] - Add IO.inspect/2 with a binary as the second argument

> Thanks for your feedback folks. Thanks for your proposal, discussions like these are what help keep the language evolving towards better user-friendliness! On Thursday, April 22, 2021 at 11:34:56 PM UTC-7 fghu...@gmail.com wrote: > Thanks for your feedback folks. I see where you are coming

Re: [elixir-core:10228] [Proposal] - Add IO.inspect/2 with a binary as the second argument

> From a developer consistency perspective, though, I’m not as sold on this. I tend to agree, this feels like nice parameter sugar but makes it harder to interface consistently with extended options. Maybe it makes more sense for an application-level helper? On Thursday, April 22, 2021 at

Re: [elixir-core:10205] Ranges with steps

> IMHO, a range(together with its now established stepping capability) is but syntactic sugar This is true, but in Elixir a range is syntactic sugar specifically for a *compile-time* list of integers. This is what lets it be used in guards and pattern matching, where streams (and non-literal

Re: [elixir-core:10170] Ranges with steps

eld in the range - but how are we going to >> remind users implementing range_to_list to check this field? >> >> * Keep ranges as is and normalize the boundary when creating the range - >> this means you can't use x,.y in match, because we can't have a x-n,.y in >>

Re: [elixir-core:10167] Ranges with steps

I like the idea of supporting steps in ranges in general! The path to supporting it in range *literals* with special rules for guard, match, and normal contexts seems a little rough, but I can't think of a better way than what's been proposed so far. x..y//z seems like a reasonable syntax to

Re: [elixir-core:10080] ISO 8601 ordinal dates

on't support basic on parsing. Our > options are: > > 1. Keep as is > 2. Parse basic > 3. Deprecate basic to_iso8601 > > I have already fixed master to raise if someone is trying to convert a > date with a negative year to basic. > > On Fri, Feb 5, 2021 at 2:20 AM Christoph

Re: [elixir-core:10076] ISO 8601 ordinal dates

Will resume work on it a little later! On Thursday, February 4, 2021 at 4:30:43 PM UTC-8 Christopher Keele wrote: > Sounds great to me, I'll start a PR. > > On Thursday, February 4, 2021 at 4:27:28 PM UTC-8 Kip wrote: > >> > So my takeaway is that if we add some docs around

Re: [elixir-core:10075] ISO 8601 ordinal dates

man readable UI content. So restricting conformance and documenting > clearly seems sound. > > > > On 5 Feb 2021, at 8:23 am, Christopher Keele wrote: > > It also goes on to say "When the application identifies the need for a > complete representation of a calendar date, it

Re: [elixir-core:10073] ISO 8601 ordinal dates

e, and our use of the year extension for the minus, and support leading plusses, we are in spec without adding ordinal date or basic format support. On Thursday, February 4, 2021 at 4:17:58 PM UTC-8 Christopher Keele wrote: > > That is supported by the spec because everything on ISO is

Re: [elixir-core:10072] ISO 8601 ordinal dates

ed by the spec because everything on ISO is per agreement. > unless it explicitly says that supporting the regular format also requires > supporting the ordinal one. > > On Fri, Feb 5, 2021 at 00:53 Christopher Keele > wrote: > >> The most straight-forward source I've b

Re: [elixir-core:10069] ISO 8601 ordinal dates

4 PM UTC-8 Christopher Keele wrote: > So by my read, the leading minus is part of the expanded year spec, and > the expanded year spec is by agreement only, because all parties have to > agree on how much the year is being expanded, to avoid ambiguity with basic > ordinal notation. >

Re: [elixir-core:10068] ISO 8601 ordinal dates

, 2021 at 3:53:20 PM UTC-8 Christopher Keele wrote: > The most straight-forward source I've been referencing is the wikipedia > page on ISO-8601, augmented by the spec itself and some explanatory > articles for confusing cases. But the wiki does a good job > <https://en.wikipedia.or

Re: [elixir-core:10066] ISO 8601 ordinal dates

or negative years. If they do, then there may be ambiguity. > > On Fri, Feb 5, 2021 at 00:22 Christopher Keele > wrote: > >> > Here is another question: if we are going to parse ordinals by default, >> how am I going to format to the ordinal format? Use strftime exclusivel

Re: [elixir-core:10063] ISO 8601 ordinal dates

mit (by default). On Thursday, February 4, 2021 at 3:20:21 PM UTC-8 Christopher Keele wrote: > > Ordinal also has both extended and basic forms too. > > Yup, basic/extended can apply to the entire date/time/datetime string (but > must be universally applied to it, saving at l

Re: [elixir-core:10062] ISO 8601 ordinal dates

> Ordinal also has both extended and basic forms too. Yup, basic/extended can apply to the entire date/time/datetime string (but must be universally applied to it, saving at least some headache). > The distinction between basic ordinal and basic DateTime is a single character I agree that

Re: [elixir-core:10060] ISO 8601 ordinal dates

> I think sigils should only ever accept the extended format. Imagine reading ~D[2020-01-03] and then two lines below ~D[20200103]. :) Sold! Also, technically the sigils support any calendar (ISO and its parser are just used by default), so upon reflection ISO flags don't belong here. And

Re: [elixir-core:10057] ISO 8601 ordinal dates

> I am not necessarily worried about sigils because sigils are always compile-time literals. It is probably fine to enforce a given format there rather than multiple ones. Agreed! What I am wondering here is if the sigils -- and other parsing functions -- should probably be universally

Re: [elixir-core:10055] ISO 8601 ordinal dates

licitly does not want to support this format? For > example, my invoices follow precisely the -NNN format, and if someone > wrote a code that detects between invoice numbers and dates, you may now > accidentally parse invoices as dates. > > So if we want to support this

Re: [elixir-core:10054] ISO 8601 ordinal dates

Calendar.ISO`. > > > > On 5 Feb 2021, at 6:16 am, Christopher Keele wrote: > > Ordinal dates are interesting because while they are not calendar dates, > they are trivially convertible into them. > > > -- You received this message because you are subscribed to the Go

Re: [elixir-core:10051] ISO 8601 ordinal dates

so the argument in that, if we parse 2021-034 by default, what >> happens when the user explicitly does not want to support this format? For >> example, my invoices follow precisely the -NNN format, and if someone >> wrote a code that detects between invoice numbers and dat

Re: [elixir-core:10047] ISO 8601 ordinal dates

feedback, get >> some discussion going on explicit points I call out in the PR, and think of >> ways to clean the implementation up a little. >> >> On Wednesday, February 3, 2021 at 2:53:23 PM UTC-8 br...@grox.io wrote: >> >>> +1 >>> >>> On We

Re: [elixir-core:10045] ISO 8601 ordinal dates

, 2021 at 2:53:23 PM UTC-8 br...@grox.io wrote: > +1 > > On Wed, Feb 3, 2021 at 2:54 PM Christopher Keele > wrote: > >> As observed by @ryanbigg <https://twitter.com/ryanbigg> on Twitter >> <https://twitter.com/ryanbigg/status/1356847900035190786>, *&

[elixir-core:10042] ISO 8601 ordinal dates

As observed by @ryanbigg on Twitter , *"2021-034"* is a valid ISO 8601 date. Specifically, it is an ordinal date descriptor of the format -DDD. Unlike some

Re: [elixir-core:10032] [Proposal] Add `URI.encode_query/2` to allow RFC3986 space encoding

*> For example, someone could use a query string where the meaning of & and = are replaced and that's fine.* I've had to work with an API that used subtly different querystring encoding semantics, and had to pretty much throw out all of Tesla to get it to work, since it made these assumptions

Re: [elixir-core:9969] [Proposal] Make Kernel.tap/2 and Kernel.then/2 macros

> I am worried making it a macro will signal to developers they need to worry about these kinds of low-level optimizations, which is not generally true! Devil's advocate, one (of many) reasons why dev's shouldn't need to worry about these kinds of optimizations is because the language is

Re: [elixir-core:9894] import a function having default values: we must specify each arity used

> Do you think using :* makes it explicit and consistent enough, or still not worth it in your opinion? I think :all is even more explicit, and a little more consistent with the import only/except DSL: import Foo, only: [bar: :all, baz: 3] On Saturday, December 26, 2020 at 2:19:21 AM UTC-8 José

Re: [elixir-core:9842] Enum.index/2

I think that even if it enabled awesome optimization opportunities, 1. Having both *Enum.index_with* and *Enum.index*/*indexed* will confuse people. 2. Straying from Elixir's consistent API design of "Module X functions take X's as their first argument" will confuse people. a. Especially in

  1   2   >