[elixir-core:5913] Proposal: Pretty print integers with underscore digit separator

Hello everyone, It's very convenient to write down integer literals as e.g. 10_000_000 - much easier for humans to read. I was recently debugging some performance issues and I was working with this data in iex: [memory: 173978912, message_queue_len: 0, heap_size: 12834421, total_heap_size: 2

Re: [elixir-core:5935] Proposal: Pretty print integers with underscore digit separator

her) values. >> >> >> http://stackoverflow.com/questions/34064900/is-there-a-switch-to-enable-thousand-digit-grouping-100-000-by-default-in-iex >> >> There's a suggestion here that you can use right away. >> >> >> On Tuesday, June 14, 2016 at 10:22:03 PM

[elixir-core:6525] [ExDoc] Proposal: Anchor built-in types

Hello, I think it would be useful to add anchors to built-in types and the main benefit would be improving "discoverability" of the typespecs page. Demo: http://wojtekmach.pl/elixir-lang-docs/elixir/Agent.html#get/3 (click `timeout` type) (diff

Re: [elixir-core:6528] [ExDoc] Proposal: Anchor built-in types

> > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Wed, Oct 26, 2016 at 5:12 PM, Wojtek Mach > wrote: > >> Hello, >> I think it would be useful to add anchors to built-in types and the main >> benefi

Re: [elixir-core:6529] [ExDoc] Proposal: Anchor built-in types

t's the first part to figure out then. I am not sure how > acceptable is going to be in Elixir's repo. > > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Wed, Oct 26, 2016 at 5:40 PM, Wojtek Ma

Re: [elixir-core:6749] Re: Introducing Calendar types

g-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/CAGnRm4JzQOf2F-sO%2BZy4dYo% > 2Bn-UqOph7eer5dpL

Re: [elixir-core:6848] Proposal: add native language support for handling Decimal types

(sorry for digging up old topic) I would be open though to adding support for number sigils like 13.0d, > 13.0f although we should also consider how numbers like rationals would > play into that. > Would the idea by that Elixir would allow doing a 13.0d sigil, and Decimal (whether in core or

Re: [elixir-core:6849] Proposal: add native language support for handling Decimal types

macro. > > On Wed, Feb 8, 2017 at 02:28 Wojtek Mach > wrote: > >> (sorry for digging up old topic) >> >> I would be open though to adding support for number sigils like 13.0d, >>> 13.0f although we should also consider how numbers like rationals would >>

Re: [elixir-core:7186] [Proposal] mix report

Excellent idea, Michał! I started experimenting with it at https://github.com/wojtekmach/mix_report. I have basic issue reporting for Elixir and (temporarily vendored) for Ecto. W dniu niedziela, 4 czerwca 2017 17:15:31 UTC+2 użytkownik Michał Muskała napisał: > > That could work. In a similar

[elixir-core:7243] Re: [Proposal] Non-naive DateTime sigil

I think that'd be a nice addition. Even if it does not eventually land in Elixir, anyone can define the `~Z` (or whatever) sigil just for tests as shown at the end of the post. I usually deal with just `NaiveDateTime`s but on the rare occasion that I used `DateTime` not having the sigil wasn't

Re: [elixir-core:7245] Re: [Proposal] Non-naive DateTime sigil

th UTC. > What I would love to see, however, is an Inspect implementation for > DateTime. The structs are extremely hard to read and see what's happening. > Even having a simple inspect implementation should make it much easier. > > Michał. > > On 27 Jun 2017, 16:29 +02

Re: [elixir-core:7292] Enhancement propsal: @doc for types

web visit https://groups.google.com/d/ > msgid/elixir-lang-core/098b967e-d38c-47aa-8783- > 34e76bff00c0%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/098b967e-d38c-47aa-8783-34e76bff00c0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For m

Re: [elixir-core:7412] Re: [Proposal] Non-naive DateTime sigil

a 2017 16:49:41 UTC+2 użytkownik Wojtek Mach napisał: > > There's DateTime.to_string/1 which seems perfect to use, I'm looking into > it: > > iex(1)> DateTime.utc_now > #DateTime<2017-06-27 14:46:54.331343Z> > > iex(3)> %DateTime{year: 2000, month: 2,

Re: [elixir-core:7647] Pipe and anonymous functions

Shameless plug: I just created a small library that allows to do: `4 |> & &1 * 2` and similar. You might find it occasionally useful in a local iex session but for the good reasons mentioned in this thread please don't use it in production code :) https://github.com/wojtekmach/pipe_capture W d

[elixir-core:7687] Re: [Proposal] Protected/Private modules

(I tried sending below message to the list but is still doesn't show up so if it eventually does: sorry for dup!) There is already kind of a notion of protected module in Elixir: a module with `@moduledoc false`. Such module is e.g. not autocompleted in IEx. You're right however that all module

Re: [elixir-core:7704] Move Dependency Build files into a seperate location

> The _build folder contains all build artifacts for external dependencies and internal application code. This means that caching this folder is a pain. Could you elaborate why is this painful? Is it the sheer size of the _build directory? Or you don't want to cache app code? Please note that e

[elixir-core:7725] Proposal: Inspect implementation for URI

Hello, Having an Inspect implementation would make a shorter output in iex, exunit diffs etc and the string representation is inambiguous. Under the hood it would use `String.Chars.URI.to_string/1`. The only reason it might have been omitted that I can think of is how it plays with `URI.default

Re: [elixir-core:7730] Proposal: mix compile to have --no-warnings option

Warnings are printed on stderr so you can silence them by redirecting output: mix deps.compile --force 2> /dev/null W dniu wtorek, 2 stycznia 2018 10:55:07 UTC+1 użytkownik Andrea Leopardi napisał: > > This has been asked a few times and I will report the gist of José's usual > answer: if we

[elixir-core:7743] Re: Proposal: Inspect implementation for URI

the output format the thing needed to execute to recreate the > same structure. > > > On Monday, January 1, 2018 at 9:33:47 AM UTC-7, Ben Wilson wrote: >> >> The downside here is that you can no longer copy and paste the output. >> >> On Monday, January 1, 2018 at

[elixir-core:7795] Re: [Proposal] Add async functions definitions

> Also another benefit is having a syntax more similar to other languages. This can make Elixir more welcoming for people from other communities such as python or javascript. Adding syntax and APIs that feel familiar is one way to potentially make it easy for people to learn Elixir. It doesn't

[elixir-core:7801] Proposal: IEx.Helpers.use_if_available/2

Hello, I'd like to propose to introduce a `use_if_available/2` to complement `import_if_available/2`. On our project we can do `use Shared` to get common aliases and imports. We can't use it in `.iex.exs` though because it won't work without `-S mix`; we have to copy-paste stuff to .iex.exs. Si

Re: [elixir-core:8310] Proposal: analogue of node's .editor for iex

; To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/6611b3ce-0cbd-4e40-b212-a880e7a0f8ce%40googlegroups.com > &l

Re: [elixir-core:8360] [proposal] Allow module attributes in binaries length

Perhaps worth mentioning that in order for it to work today it needs to be written as: <<5::size(@some_attrib)-unit(2)>> > On 2 Nov 2018, at 14:33, Jakub G wrote: > > We can use <<5 :: 4>> or <<10 :: 4*3>> to control our binaries' size. > Why can't we use modules attrib (which are const) to

[elixir-core:8398] Proposal: Inspect for records

Hello, I'd like to discuss support for Inspect protocol for records. I created a proof-of-concept here: https://github.com/wojtekmach/record_inspect Basically, for these records: defrecord :resultset [ :column_count, :column_definitions, :row_count, :rows, :warning_count, :status_fla

[elixir-core:8399] Re: Proposal: Inspect for records

One way to avoid issues with state is to avoid... state. Maybe we'd configure it like this: records = [ # explicit {:column_definition, [:name, :type]}, # grabs record fields from record macro in that module, e.g: resultset(resultset()) |> Keyword.keys() {Records, :resultset} ] IEx.con

Re: [elixir-core:8402] Re: Proposal: Inspect for records

> Couldn't you define a method like __record_keys__/0 on the atom in the defrecord call? Yes. To be concrete, this is how it could work: ``` defmodule Records do import Record defrecord :a, [:x, :y] defrecord :b, [:x, :y] end iex> Records.__records__() [ a: [:x, :y], b: [:x, :y] ] ```

[elixir-core:8464] Re: [Proposal] - New Formatter option for spaces around brackets/parens

Hi Chris, To quote one of the design principles behind the formatter [1] > The second principle is to provide as little configuration as possible. This eases the formatter adoption by removing contention points while making sure a single style is followed consistently by the community as a who

[elixir-core:8487] Re: [Proposal] Debug macro like dbg! in Rust 1.32

I just wanted to add that I've been using such macro from the day I saw that Rust blog post [1] and it had replaced all my usages of `IO.inspect` ever since (and I did use it a lot) and it proved really helpful to me. To try moving this forward, I'd like to try fleshing out a concrete proposal

[elixir-core:8562] Re: Enum.repeat/2

iex(1)> List.duplicate(:something, 5) [:something, :something, :something, :something, :something] :-) Hi there, > > I would like to know your opinion about an `Enum.repeat/2` function. In > test, I notice often that I write: > > Enum.map(1..5, fn(_) -> :something end) > [:something, :somethin

Re: [elixir-core:8766] Move dependencies into a separate file (e.g. deps.exs)

> https://hex.pm/packages/wand I’m glad to see community is stepping up to fill this gap. My personal opinion is such tools makes it almost “too easy” to adds deps whereas I think we should do the opposite, encouraging people to audit deps before adding them and ideally limiting deps in the fi

Re: [elixir-core:8982] [Proposal] Add public API to check if a test is async

You can already check whether a given test is async by inspecting context, perhaps it’s enough for your use cases? defmodule FooTest do use ExUnit.Case, async: true setup c do IO.inspect c.async :ok end test "greets the world", c do IO.inspect

Re: [elixir-core:9020] [Proposal] Add ability to parse ISO8601 "basic" format

I don't recall any examples at the moment but I remember seeing APIs that return data in the basic format so the proposal sounds good to me. I agree that the format should be specified explicitly. Given a Date.from_iso8601/2 already exists, the second argument is the calendar (Calendar.ISO by d

Re: [elixir-core:9039] Proposal: standardize expression to refer to functions with multiple arities (and ExDoc auto-linking)

> Is anyone ok with `fun/1,2`? `fun/*` won't be supported. I think this is already a pretty common way so definitely +1 from me on making it official. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and sto

Re: [elixir-core:9092] [Proposal] Add ability to parse ISO8601 "basic" format

Another idea is to deprecate `Date.from_iso8601(string, calendar)` in favour of `Date.from_iso8601(string, calendar: calendar)`, and then `:format` becomes just another option. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe

Re: [elixir-core:9094] [Proposal] Add ability to parse ISO8601 "basic" format

I believe the proposal is about supporting :basic format in all calendar types. All from_iso8601 functions have the same shape right now and if we make a change in one place we should make it remaining too. -- You received this message because you are subscribed to the Google Groups "elixir-la

Re: [elixir-core:9095] [Proposal] Add ability to parse ISO8601 "basic" format

But yes, I only showed Date.from_iso8601(string, calendar: calendar), I meant to say we’d make this change everywhere. Which also means there would be deprecations everywhere. Thanks for follow-up, this needed clarification. -- You received this message because you are subscribed to the Google

Re: [elixir-core:9114] Suggestion Add Rubys tally

As I mentioned on the linked PR, I’m in favor of such feature. I like how Clojure calls this function: frequencies. Thus if we are considering Enum.frequencies/1 and/or Enum.frequencies/2, it has my vote. To move the proposal forward I think it would be very valuable if you could survey other p

Re: [elixir-core:9140] [Proposal] latest and earliest functions for DateTime and NaiveDateTime

I think earliest and latest are good because they are descriptive but wondering if they should be called min and max instead. The advantage of the latter is they’d be similar to Kernel.min/2 and Enum.min/1,2. I guess a disadvantage is someone reading `min` could think it returns the minimum allo

Re: [elixir-core:9141] [Proposal] latest and earliest functions for DateTime and NaiveDateTime

Should Date.earliest operate on `Date.t` or `Calendar.date`? That is, should we allow the following? iex> Date.earliest([~N[2019-01-01 09:00:00], ~D[2019-01-02]) ~D[2019-01-01] Seems like this could be useful. -- You received this message because you are subscribed to the Google Group

Re: [elixir-core:9236] Re: Automatically time long-running iex commands.

+1 from me for `IEx.Helpers.time`. It doesn't solve the „oh I wish I timed this command” problem, but I think its useful on its own, and personally I'd much rather have just this. I suggested something somewhat similiar with additional timing information in a `Kernel.dbg` macro proposal. One of

Re: [elixir-core:9256] [Proposal] Create a sigil_P for PIDs, and use it for inspection

In general I'm keen on adding inspect implementations (and corresponding sigils) and have proposed a few myself. (e.g. ~U was accepted and #URI<> wasn't.) **Personally** I didn't have a need for a pid literal often enough. The times I did, it was pretty much always in an IEx session where I cou

Re: [elixir-core:9256] [Proposal] Create a sigil_P for PIDs, and use it for inspection

So this is a separate discussion but what I'd rather see is another sigil like mechanism for structs that would make these valid: URI[https://elixir-lang.org] Decimal[1] Complex[0, 1] Ratio[1, 3] MapSet[1, 2, 3] Money[100 USD] Date.Range[2019-01-01/12-31] Having such mechanism doesn't address yo

Re: [elixir-core:9274] adding a :doc option to defdelegate?

defdelegate already adds a `@doc delegate_to: …` on master! > On 22 Nov 2019, at 18:55, Rich Morin wrote: > > About a month ago, I made the following suggestion, which never received any > comment: > >> ... give `defdelegate` an option to create the `@doc delegate_to` entry >> automagically:

Re: [elixir-core:9276] adding a :doc option to defdelegate?

est/elixir/io/ansi/docs_test.exs 32:delegate_to: {Foo, :bar, 3} 36: \e[33mdelegate_to:\e[0m Foo.bar/3 Looks like the first hit, lib/elixir/lib/kernel.ex:4909, is relevant. > On 22 Nov 2019, at 19:55, Rich Morin wrote: > >> On Nov 22, 2019, at 10:29, Wojtek M

Re: [elixir-core:9278] adding a :doc option to defdelegate?

I can’t think of cases where I wouldn’t want `@doc delegate_to` generated for me or where I would use it explicitly. > On 22 Nov 2019, at 20:11, Rich Morin wrote: > >> On Nov 22, 2019, at 10:58, Wojtek Mach wrote: >> >> ~/src/elixir[master]% rg delegate_to >&

Re: [elixir-core:9291] [Proposal] Create a sigil_P for PIDs, and use it for inspection

For anyone interested I published a proof-of-concept for this here: https://github.com/elixir-lang/elixir/pull/9640 W dniu piątek, 25 października 2019 20:21:54 UTC+2 użytkownik OvermindDL1 napisał: > > I've always thought that structs could use a 'constructor' format like > `%URI("https://elix

[elixir-core:9388] Proposal: Multi-letter sigils

Currently sigils are single letter which means there can be only 2 x 26 of them and some of them are already taken by the standard library. As mentioned in [1] it's not clear if there should be for example a `~P` and if so, whether it should be for PID or Port. Similarly, there couldn't be an `~

Re: [elixir-core:9405] proposal: Shorthand syntax to access structs keys values with compile-time checks

When we do: def foo(%User{} = user) do user.bad_field end The compiler should have all the information it needs to catch invalid fields. (At least until the variable is re-bound but ideally even then.) So I believe there is no need to introduce new syntax! > On 22 Feb 2020, at 21

Re: [elixir-core:9418] [Proposal] Mix deps.get option to avoid updating the lockfile

Yeah, `mix deps.get` would create the lock file if there isn’t one, but I also believe it would not update it unless you also change your deps. If that isn’t the case I would also argue that’s a bug (i.e. —frozen-lockfile would be implicit. An exception is where we change the lock file format, e

Re: [elixir-core:9451] Proposal: use name of the defined guard in error reporting

> Correct me if I'm wrong, but isn't this not just specific to custom guards? > As far as I know, all macros behave this way because macro expansion happens > at compile time, and this sort of runtime-error within the generated code > can't know about the macro that produced it without some sort

Re: [elixir-core:9525] [Proposal] Extend the mix formatter to work with eex files.

In my opinion formatting non-Elixir code is definitely out of the scope of project. Instead of adding different backends to `mix format`, I’d do the opposite: find a formatter that supports multiple backends and add `mix format` as one of them. I thought the feature request was about formatting

Re: [elixir-core:9532] [Proposal] Support additional time units

Just a word of warning, I believe that while supporting minutes, hours, and days is rather trivial since we have such fields on the structs and so we could just increment them, supporting weeks is trickier - are all weeks composed of 7 days or there are calendars where this is not true? Maybe

Re: [elixir-core:9587] Pagination of help in iex

IEx uses erlang shell so such capability should be added there first and then IEx will get it for free. > On 24 Jun 2020, at 15:12, Bülent Erdemir wrote: > > Hi, is it possible to have pagination for help content in iex ? It's been > discussed earlier in around 2013 but not implemented since t

[elixir-core:9597] Proposal: ExUnit.Callbacks.tmp_dir!/0

It’s common to create temporary directories for tests, ideally a unique directory per test to run them concurrently. I’d like to propose adding `ExUnit.Callbacks.tmp_dir!/0` and this is how we could use it: defmodule MyTest do use ExUnit.Case, async: true test "my test" do

Re: [elixir-core:9602] Proposal: ExUnit.Callbacks.tmp_dir!/0

> with debugging or anything, but I can see how this might be confusing for > folks. > > Wojtek Mach schrieb am Sa. 27. Juni 2020 um 12:19: >> It’s common to create temporary directories for tests, ideally a unique >> directory per test to run them concurrently. >>

Re: [elixir-core:9604] Proposal: ExUnit.Callbacks.tmp_dir!/0

:17, Wojtek Mach wrote: > > The downside of doing work in setup/0 is if you only need temp dir for one > test, unless you mess with tags which adds boilerplate, you’d unnecessarily > create dirs for tests that don’t need it. But then again you could argue that > if you need it in ju

Re: [elixir-core:9606] Proposal: ExUnit.Callbacks.tmp_dir!/0

g and :timeout tags that are more than just filters. :) > > Is it too overkill or does it make sense? > > On Saturday, June 27, 2020 at 7:43:37 AM UTC-4, Wojtek Mach wrote: > Here is a proof of concept for the tag-based solution: > https://gist.github.

Re: [elixir-core:9858] Proposal: Add option to mix format to create .formatter.exs

I am slightly -1 given, as you mentioned, you can very easily achieve it today: cd /path/to/project && mix new foo && mv foo/.formatter.exs . && rm -rf foo > On 13 Dec 2020, at 12:30, eksperimental wrote: > > It happens that when I want to update a project that has been created > with an Eli

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

This addition would be nice for importing record macros, defrecord defines 3 different arities: 0, 1, and 2. > On 26 Dec 2020, at 09:43, Devon Estes wrote: > >  > This seems like a source of potentially confusing issues to me, as mentioned > earlier. I do admit that this would be a very rare

Re: [elixir-core:9914] Validating keywords keys

I think this would be a great addition to the core. While there are libraries in this space, as silly as this may seem, solving this key typo problem seems like solving the 60%-80% case (not to take away anything from those libraries!) How about a Keyword.take!/2? iex> Keyword.take!([a: 1],

Re: [elixir-core:9917] Validating keywords keys

on and Ruby provide at the syntax-level a convenience that checks > only the given keys are expected. So, when it comes to options, both of these > languages are allowing us to write assertive code more elegantly than Elixir. > > > On Wed, Dec 30, 2020 at 10:10 AM Wojtek Mach <m

Re: [elixir-core:10016] Proposal: Mix.install

> On 25 Jan 2021, at 11:40, Boris Kuznetsov wrote: > > Recompilation (and delay) on every new run seems like a major issue. > > Probably, if you call `Mix.install/?`, then you should pass the target > directory to cache compiled dependencies. > > By default it can use `_build` as all current

Re: [elixir-core:10107] [Proposal] New module attribute managed by Elixir: `@__using__`

I have trouble understanding the use case too but fwiw compilation tracers to the rescue! :D defmodule MyTracer do def trace({:remote_macro, _, M, :__using__, 1}, env) do IO.puts "#{inspect(env.module)} called M.__using__/1" end def trace(_other, _env) do :ok end end Code.put_co

Re: [elixir-core:10180] Proposal: Add function to return the first async task to complete

Check out Task.yield_many/2 (https://hexdocs.pm/elixir/Task.html#yield_many/2 ) :-) > On 31 Mar 2021, at 22:54, thia.md...@gmail.com > wrote: > > Proposal > > Add a function to the Task module that takes a list of tasks, and returns as > soon

Re: [elixir-core:10238] [Proposal] Expose functions from `Code.Formatter` via the `Code` module

Looking forward to any progress on this front. If anyone is interested, I was playing with these ideas and you can see some example use cases here: https://github.com/wojtekmach/fix/blob/master/test/fix_test.exs. But exactly because Code.Formatter is private, I had to vendor it and that code broke

Re: [elixir-core:10269] using mix do add dependencies to the project

Please check previous discussions around this topic on this mailing list and Elixir issue tracker. On May 22, 2021, "gmail.com" wrote: > Hi > I'm a node.js developer and I like elixir a lot. One thing about > node.js is that you can install packages using: > ``` npm install ``` > And it installs

Re: [elixir-core:10334] Allow access to compiler_options while compiling EEx

I know for a fact that :parser_options key is exactly what José had in mind :) -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@g

[elixir-core:10364] Proposal: Add List.keyfetch!/2

When working with lists of two element tuples like: headers = [{"content-type", "html"}] attributes = [{"href", "https://elixir-lang.org"}] I'd usually access the value like this: {_, content_type} = List.keyfind(headers, "content-type", 0) IO.puts content_type And when the valu

Re: [elixir-core:10388] [Proposal] Include Keyword default argument validation

Keyword.validate will accept just a keyword, right? Did you consider making it accept any enumerable of pairs, just like Keyword.new does? Same for Map. I think one particular scenario is something like this:     def foo(opts) when is_list(opts) do       config = Map.validate!(opts, …)       conf

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

On August 14, 2021, "gmail.com" wrote: > I was about to create another thread kind of related to this, please > my apologies if I misunderstood. > > Recently I started working on a package, and I wanted to share as part > of the package a lot of TestSupport codes that people would take > advantage

Re: [elixir-core:10488] assert %{} = value should warn that author probably meant assert %{} == value

This: x = :foo; assert %{} = x produces: match (=) failed code: assert %{} = :foo left: %{} right: :foo stacktrace: foo_test.exs:11: (test) (emphasis mine) This: x = :foo; assert is_map(x) gives: Expected truthy, got false code: assert is_map(x) arguments: # 1 :foo I personally find

Re: [elixir-core:10575] Proposal: disable doctests per doc entry

Another popular pattern I've seen in the wild is: ## Examples Foo.bar() #=> :baz since :baz is in a comment, it is not going to be syntax highlighted, but I think that's fine. On December 9, 2021, elixir-lang-core wrote: > Hi list, > documenting functions made me realize the need to be able to

Re: [elixir-core:10588] [Proposal] Include Keyword default argument validation

and return > > > > keywords as well. > > > > > > > > However, I can see benefits in accepting Enumerables. What do > > > > you think about using another verb such as cast or coerce, > > > > instead of validate, for this typing > &g

Re: [elixir-core:10702] Allow String.to_integer/1 to return integer when passed integer argument

If your project is already using Ecto, you can also use Ecto.Type.cast/2: iex(2)> Ecto.Type.cast(:integer, 42) {:ok, 42} iex(3)> Ecto.Type.cast(:integer, "42") {:ok, 42} (same for floats, dates, etc) Probably best to wrap it in a more convenient function like this though: defmodule MyApp do def

Re: [elixir-core:10710] [Proposal] Add a shortcut to access a struct within the module where it is defined

Neither `%_{}` nor `%self{}` can be supported because they already have a meaning in pattern matches. The former means _any_ struct and the latter binds the matched struct name to the variable `self`. You can give `__MODULE__` another name with an alias: alias __MODULE__, as: Struct def connect(%

Re: [elixir-core:10747] Proposal: Allow `describe` blocks in ExUnit test to be skipped

This is already possible with `@describetag :skip` inside a describe block. There's a `@moduletag :skip` too! On February 3, 2022, elixir-lang-core wrote: > Currently `@tag :skip` is only effictive in tests, but if I have a > describe block with 10 test, i need to add the tag to each one > indivi

Re: [elixir-core:10766] [Proposal] Update MapSets with pattern matching, assignments, update shorthand, etc.

Regarding `%MapSet[1, 2]`, I think it looks really nice. Regarding multi-letter sigils, I think we should have those but not for this particular use case. Sigils are for textual representations so not a good fit for "containers" like MapSet, Vector, etc, when evaluating `%MapSet[...]` we want to e

Re: [elixir-core:10837] [Proposal] Add auto-formatting of alias/import/use statements to mix format

I don't think the proposal is going to be accepted. A very important design goal of `mix format` is never to change the semantics of the code and changing the order of statements is changing semantics. On March 18, 2022, elixir-lang-core wrote: > The Elixir style guide has guidance on how to orga

Re: [elixir-core:10855] Non UTF8 Binaries in ExUnit.CaptureIO

I believe capture_io(encoding: :latin1, fun) should do the trick, can you check? On April 6, 2022, "maennchen.ch" wrote: > Hi everyone, > > Background > > While developing tests for a mix task, that returns non UTF8 binaries > into STDOUT (building block to be piped into a file / pipe), I found >

Re: [elixir-core:10857] Non UTF8 Binaries in ExUnit.CaptureIO

ture_io([encoding: :latin1], fn -> IO.binwrite(<<222>>) end) == <<222>> On April 6, 2022, "maennchen.ch" wrote: > That unfortunately gives me the same result. > > On Wednesday, April 6, 2022 at 6:57:35 PM UTC+1 Wojtek Mach wrote: > > I believe capture_

Re: [elixir-core:10919] [Proposal] List.delete support for delete multiple fields inside a list

The --/2 operator already does this. :) iex(1)> [:a, :b, :c, :d, :e] -- [:a, :b] [:c, :d, :e] > On 7 Jun 2022, at 17:31, Randson wrote: > > Currently, the function `List.delete` only works for a single field. What I > want to add is the possibility to delete multiple fields by passing a list

[elixir-core:11016] Proposal: Warn on assert %{} = x

Hi, Developers can easily shoot themselves in the foot if they write: assert %{} = x but really what they meant was to write: assert %{} == x The mistake is writing `=` instead of `==`, an easy one to make. The difference is of course that the former will succeed on _any_ map and the

Re: [elixir-core:11017] Proposal: Warn on assert %{} = x

Just to be clear what I proposed was not a change in the compiler, just changing ExUnit's assert macro to emit the warning under that specific scenario. > On 16 Aug 2022, at 11:59, Ben Wilson wrote: > > To me this feels like a good use of credo or similar linter, not something > that the Elixi

Re: [elixir-core:11019] Proposal: Warn on assert %{} = x

tual` > > I really like this suggestion you made in the previous thread, it helps a lot > distinguishing between matches and equality, maybe it could be encouraged in > the official docs? > > > > Le mar. 16 août 2022 à 19:17, Wojtek Mach <mailto:woj...@wojtekmac

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

Yes, a Calendar.strptime companion to Calendar.strftime is very appealing. Unfortunately there’s no obvious way to create highly-optimzed parser (like the one for ISO8601 is) because it would have to handle e.g. %b (abbreviated month name) along with :abbreviated_month_names option so the input

Re: [elixir-core:11262] Force compilation of a single file/files for benchmarking purposes

You can also force recompilation by defining this function:    def __mix_recompile__?, do: trueWiadomość napisana przez José Valim w dniu 23.02.2023, o godz. 11:20:Could you potentially use `mix run lib/my_file.ex` for those cases?On Thu, Feb 23, 2023 at 10:27 AM Tobias Pfeiffer

[elixir-core:11386] Proposal: Deprecate ~U in favour of ~UTC

Hi, I'd like to propose deprecating ~U in favour of ~UTC. I don't think the change would necessarily increase readability of existing code given the common datetime format. I think the advantage is discoverability, if we look at list of available sigils or Kernel functions in general, this one

[elixir-core:11388] Proposal: Add ~URI sigil

Hi, I'd like to propose adding ~URI for constructing URI structs. Here's an example: iex> ~URI"https://elixir-lang.org"; %URI{ scheme: "https", authority: "elixir-lang.org", userinfo: nil, host: "elixir-lang.org", port: 443, path: nil, query: nil,

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

I just realised another small benefit of showing the full URL in the sigil. Here’s a snippet from the proposal as rendered by my e-mail client: The URL was automatically made clickable. Tools like Livebook could potentially do the same. > On 16 May 2023, at 10:38, Wojtek Mach wrote: >

Re: [elixir-core:11398] [Proposal] Change in Signature of Map and Keyword *_lazy functions to better facilitate piping

I believe an apples-to-apples comparison would be: # before x |> then(&Map.put_new_lazy(&1, :file_path, fn -> Path.join([&1.base_path, &1.filename]) end)) # after x |> Map.put_new_lazy(:file_path, &Path.join([&1.base_path, &1.filename])) And I think it does read better.

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

Btw, you may want to check out https://andrealeopardi.com/posts/a-story-of-regret-and-retiring-a-library-from-hex/. > On 26 Jun 2023, at 21:58, Ben Wilson wrote: > > Hi, > > This has been proposed before. Someone came up with > https://github.com/meyercm/shorter_maps which accomplishes this a

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

> %{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: > > > There is another idea here, which is to fix this at the tooling level. > > > > For example, we could write %{foo, bar} and have

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

> - People new to Elixir just checking out a project from source and trying to > see if it compiles, using familiar semantics from other langs I’d love to hear from actual users because to _me_ this feels like a bit of a stretch. I think people don’t want to see whether something compiles, they

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

I just realised that for this alias: setup: [“deps.get”, “app.start”] Running: $ iex -S mix setup Just works™. Make of that what you will. :) -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop

Re: [elixir-core:11525] [Proposal] System.put_env/2 clears env on getting nil as value

While rather uncommon to delete things by setting to nil, I think parity with put_env/1 is worth it. I think it is fine to have put_env and delete_env. delete_env matches Application.delete_env, {Map,Keyword}.delete, etc, so I’d definitely keep it. > On 18 Sep 2023, at 19:38, Michal Śledź wrot

Re: [elixir-core:11544] Support using brackets to access an index of a list

I believe the best outcome would be for OTP to get a native vector type and then Elixir can support it, including the Access behaviour. So I would wait. it may never happen because the barrier to entry is so high but hey, OTP didn't use to have native maps either! piątek, 22 września 2023 o 13:0

Re: [elixir-core:11553] [Proposal] mix new --add-dep="ash" app

mix deps.add was proposed a few times on this mailing list and I believe on forum too. Please see previous discussions.Wiadomość napisana przez Stefan Wintermeyer w dniu 15.10.2023, o godz. 11:13:Hi,most Elixir related new projects start with editing mix.exs and adding one or multiple deps. What

Re: [elixir-core:11560] Proposal: Struct field documentation

> PS. Having already typed this, it could be possible maybe if the `@doc` > attribute could be shaped like `@doc x: 1, y: 2` already works and so does `@moduledoc …`. The data is written into metadata section of the docs chunk. If you support this in Next LS and tell users it’s possible, it wil

Re: [elixir-core:11599] Re: [Proposal] `as: level` for deprecrated attribute

This is fairly specialized scenario so I’d go with a specialized solution. How about this: do your build in a build.sh, compile without warnings as errors however in the script inspect stderr and fail on a "warning: " unless that warning is for a deprecation. Hopefully fairly straightforward regexp

Re: [elixir-core:11607] Safe versions for `hd/1` & `tl/1`

I don’t think we should change semantics of hd/1 as it comes from Erlang and can be used in guards. Fortunately we have `List.first([])` and `Enum.drop([], 1)` as “safe" replacements. > On 12 Dec 2023, at 13:19, waiting-for-dev wrote: > > Kernel.hd/1 and Kernel.tl/1 raise an ArgumentError whe

  1   2   >