Re: [elixir-core:7661] [Proposal] Enhancing the standard Logger interfaces with application-specific logging

I personally think that it would be nice to be able to override the log level for a specific application and/or namespace (i.e. something like a pattern, where setting the level for `Foo.Bar` will set the level for logs produced by any module starting with `Foo.Bar`). This provides control to silen

Re: [elixir-core:7669] [Proposal] Introduce __STACKTRACE__

Just want to chime in here on the ML and say I'm a fan, solid +1! Paul On Fri, Dec 8, 2017 at 1:54 PM, Michał Muskała wrote: > Hello everybody, > > I submit a new proposal for changing how one can obtain a stack trace when > handling errors. > > *TL;DR* Replace the use of System.get_stacktrace(

Re: [elixir-core:7673] [Proposal] Enhancing the standard Logger interfaces with application-specific logging

I agree, for the scenario Arno describes, using the tracing tools is a more appropriate approach rather than logging, as you almost certainly want to only trace messages matching a certain pattern to prevent overload. I'm not sure I think a trace log level makes much sense when for the things you w

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

I think the only viable way to do something akin to "protected" modules, would be to have the compiler verify it, but generate public modules - this achieves the goal of protecting against improper use for the most part. That said, there are still ways to violate these boundaries, say by using `app

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

Could you clarify what the issue is? You haven't specified under what circumstances caching is a problem or with what tools. Paul On Mon, Dec 18, 2017 at 10:53 PM wrote: > The _build folder contains all build artifacts for external dependencies > and internal application code. This means that c

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

> I would like to cache pulling and buildings the deps, and just build the > > umbrella application. It would save some time off the CI build. We use > mix > > to do our compilation, testing and every other command. > > > > On Tuesday, December 19, 2017 at 4:00:10 PM UTC+11, Pa

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

;> application >> > and then runs our tests. >> > >> > I would like to cache pulling and buildings the deps, and just build >> the >> > umbrella application. It would save some time off the CI build. We use >> mix >> > to do our compilation,

Re: [elixir-core:7874] Firing up an app in a slave node

Have you tried simply running `Application.load(:app)` or `Application.ensure_all_started(:app)`? That should work. If not, it probably means the code path is not configured correctly and you'll need to make sure the code starting the nodes passes in `-pa _build//lib/*/ebin`. As for why the Mix pro

Re: [elixir-core:7879] Firing up an app in a slave node

I would second the boot loader approach when viable, but since it's not in your case, then there is nothing particularly special about how the paths are set up, you just need to add the lib directory from your Elixir install (e.g. `-pa /lib/*/ebin`). If you need to compile the project as part of th

Re: [elixir-core:7889] Add a `label:` option to IO.inspect

You can already do this today with IO.inspect(foo, label: "label") :) Paul On Mon, Feb 19, 2018 at 7:32 PM pragdave wrote: > When I use IO.inspect in a pipeline, I often find myself wanting to tag > the output with some kind of label: > > ~~~ elixir > get_name() > |> IO.inspect() > |> lookup_sc

Re: [elixir-core:7907] Re: [Proposal] Kernel.is_module?/1

If you are doing this at runtime and not compile-time, going through the code server will of course be slow, as well as bottlenecked by the code server process itself, it's a bad idea to go that route. I would want to see the use case here, because I'm convinced there is a better way to solve the p

Re: [elixir-core:7998] [Proposal] Crypto module wrapper

I think despite that Erlang has to keep some APIs for legacy reasons, it doesn't change the fact that both its documentation and the handling of invalid arguments should be improved, and that should happen _in_ Erlang, not anywhere else. A lot of the issues you have mentioned could be solved simply

Re: [elixir-core:8000] [Proposal] Crypto module wrapper

erface doesn't really solve the problem of the developer still needing > to figure out which interface to use. > > Anyway, I appreciate the input :) I'll start poking around for potential > solutions elsewhere. > > > > On Monday, May 14, 2018 at 2:02:29 PM UTC-4,

Re: [elixir-core:8242] Re: Proposal: make Application.get_env being able to resolve {:system, var} tuple out of the box

In my opinion we absolutely should not support this. It is an old convention that was created to patch over problems with configuration in releases, but it has been considered a bad pattern for quite some time now. Not only are there better patterns available (see Phoenix and Ecto and their init/1

Re: [elixir-core:8245] Re: Proposal: make Application.get_env being able to resolve {:system, var} tuple out of the box

ld configs > are just code, when env variables are volatile. > And what is the rationale, why {:system, var} is so bad if what happens in > init callback is essentially the same? Am I missing something here? > > On Monday, August 6, 2018 at 4:21:34 PM UTC-7, Paul Schoenfelder wrot

Re: [elixir-core:8247] Re: Proposal: make Application.get_env being able to resolve {:system, var} tuple out of the box

taneously. I'll probably go with this Config module idea, > thanks. At least until there's a common solution. > > On Monday, August 6, 2018 at 6:25:18 PM UTC-7, Paul Schoenfelder wrote: >> >> > So the idea is to individually resolve these settings in init callback

Re: [elixir-core:8922] [Proposal] add "when" to @type and @typep syntax

This is mostly possible already, like so: @type params(k, v) :: %{k => v} @spec handle_params(params(s, s)) :: ok when s :: String.t While Erlang doesn't support expressing guards on the generic parameters in a type definition, Elixir could just convert such definitions to the Erlang compatible

Re: [elixir-core:8925] [Proposal] identity function

My two cents: use `identity`, or `id` if it absolutely must be ridiculously concise, but keep it simple. In my opinion, functional programmers will almost universally expect one of those two, and everyone else probably won't care because the concept will be new to them. I can't say that I've fou

Re: [elixir-core:8956] Re: [Proposal] Document the Big-O complexity (time and space) of every collection and their functions

Michał did a good job of explaining why I'm not much of a fan of this either. I think when it makes sense at all, it is best to have the big-O information in module/function docs, where they can be contextualized with their intended usage, or at least sit alongside a warning that says something

Re: [elixir-core:9327] [Proposal] IEx - add command to change module context, like in-module

I think the problem here is in how modules are compiled. Elixir modules are required to be defined in a single translation unit (i.e. a file, or an expression in the REPL). CL/Clojure modules on the other hand, can be defined in more than one translation unit. To support what you are asking for

Re: [elixir-core:9329] [Proposal] IEx - add command to change module context, like in-module

o this as well. I’m not certain how this was tackled, but it works. > > > Manfred > > > > > Am 21.01.2020 um 02:16 schrieb Paul Schoenfelder > > : > > > > I think the problem here is in how modules are compiled. Elixir modules are > > required

Re: [elixir-core:9412] Proposal: Closing the gap between configurations

This was always the hardest/most annoying part about the release tooling, and I think this is probably an improvement, but it does seem to me to trade one set of annoyances for another. That said, I think I'd prefer the new set. My take is that the config should be evaluated after compilation, a

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

I think the gotcha here is that there are various "profiles" of ISO-8601, and the one we typically think of as ISO-8601 in practice is the W3C profile used on the web (see https://www.w3.org/TR/NOTE-datetime for a description of what that profile includes). The other common profile is RFC-3339 w

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

I think in the case of someone who explicitly wants to omit support for some specific part of the standard, they should use a custom date/time parsing library to handle that, allowing them precise control over what is a valid parse. If you choose to use `DateTime.from_iso8601/`, presumably you a

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

I’m generally in favor of the option to have stricter semantics, but to me the introduction of `for!` feels out of sync with other special forms, none of which are bang-form. Furthermore, especially in contrast to `with`, you end up with this weird dichotomy with the `<-` operator, where sometim

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

h error. > > I think you'd have to more clearly de-mark the difference between the > generators and the filters, which feels like a big change. > > > Best > > Adam > > > > >> On 11 Jun 2021, at 00:13, Paul Schoenfelder >> wrote: >>

Re: [elixir-core:10398] Re: [Question] Support for __using__/3

It looks to me like the error is due to a stray comma: `use Command, [aggregate_identifier: :id] do` should be `use Command [aggregate_identifier: :id] do`, which should work as you’d expect. As an aside, you might be interested in https://github.com/bitwalker/strukt, which looks like it has a

Re: [elixir-core:10401] Re: [Question] Support for __using__/3

tom >> or alias, got: Command[[aggregate_identifier: :id]] >> (elixir 1.11.2) lib/kernel.ex:5006: anonymous fn/3 in >> Kernel."MACRO-use"/3 >> (elixir 1.11.2) lib/enum.ex:1399: Enum."-map/2-lists^map/1-0-"/2 >> (elixir 1.11.2) expanding m

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

I just want to +1 what Louis has said. Overall, this feels like it makes things more complex rather than less, particularly because of the limited scope that the feature applies to, which makes it difficult to fit into one’s intuition as they learn the language. While the original example is m

Re: [elixir-core:11109] Partially applied pipelines/currying/etc

A couple thoughts: * The proposed operator `&>` may be ambiguous to parse due to function capture syntax, e.g. distinguishing between `&>` and `&>/2` might be problematic. A different operator would probably be better. José would have to chime in on that * I like the idea of having a simple way

Re: [elixir-core:11134] Re: Proposal: Named Function Arguments

The problem is that in order to implement named function arguments, both the caller and callee must agree on the calling convention (i.e. how arguments are passed, in what order, etc.). In general, it isn't possible to know this in all circumstances, due to things like a callee being implemented

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

My thoughts on the proposal itself aside, I’d just like to say that I think you’ve set a great example of what proposals on this list should look like. Well done! I have an almost visceral reaction to the use of capture syntax for this though, and I don’t believe any of the languages you mentio

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

` syntax “capture syntax” is actually misleading, > > and only has that name because it can be used to construct closures by > > “capturing” a function name, but it is more accurate to consider it closure > > syntax, in my opinion. > > This is a very salient point

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

> For reasons explained in Austin's reply > , > a "barewords" implementation is not viable in Elixir, because of the > prevalence of both atom and string key types. > > IMO, discussing the nuance of if a barewords repres

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

They aren't exactly equivalent. The difference comes into play with code loading. The local captures will reference the version of the module they were captured with, while remote/external captures will always reference the latest version of the module. Depending on what the closure is doing, t

Re: [elixir-core:11727] [Proposal] introduce with_env in ExUnit

Ideally, your system pushes this kind of "global" configuration down from the top of the supervision tree, rather than reading global state like this in a bunch of places. I would definitely encourage you to try and build your system with that in mind. Then, all of your tests can pass specific c

Re: [elixir-core:5793] Escript installation via SCM

I'm a fan - this sounds like a great improvement! Paul On Tue, May 24, 2016 at 1:13 PM, Eric Meadows-Jönsson < eric.meadows.jons...@gmail.com> wrote: > Today we have `mix escript.install` for installing escripts on the local > system. > It supports installing pre-built escripts from the local fi

Re: [elixir-core:5820] Proposal for required fields in struct expansion

Given the context I'm not sure `require` is all that confusing personally. It seems familiar and very clear. +1 from me. Paul On Wed, May 25, 2016 at 11:07 AM, Chris McGrath wrote: > > On 25 May 2016, at 16:58, José Valim > wrote: > > That's a very good point. I believe :require is better than

Re: [elixir-core:5825] Proposal for required fields in struct expansion

The one thing I don't like about using options with defstruct is that I tend to define my structs with the keyword list syntax, defining default values - if I want to do that *and* define required fields, I now have to wrap the definition of the fields+defaults in a list, i.e.: defstruct [foo: "ba

Re: [elixir-core:5860] Re: Wrapping erlang modules with notoriously bad error messages

I like the idea, I know I've been bitten by :crypto myself, but I agree with Myron - submitting PRs to OTP seems like a better path since the whole BEAM community benefits. Paul On Thu, May 26, 2016 at 10:17 AM, Ben Wilson wrote: > I chatted briefly with Jose and James about this, and it seems

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

I like it much better with underscores than without, much more readable. I would +1 making it the default behaviour with an option to turn it off. Paul On Mon, Jun 20, 2016 at 11:37 AM, José Valim < jose.va...@plataformatec.com.br> wrote: > I like this proposal. I would even pick it is a default

Re: [elixir-core:5973] Mix OTP behaviour graph idea

The BEAM contains metadata such as what behaviors a module implements and that would be enough to determine what entities they represent. The tough part is being able to trace what the links between them are. As far as I know, there's no way to determine (from the BEAM attributes) what processes a

Re: [elixir-core:6168] Kernel.compare/2 and Comparable protocol

Just my two cents, but why would this function return atoms instead of -1, 0, 1? Then it works easily with sorting functions, and is consistent with compare implementations in other languages. I can say I've seen multiple people make the mistake of trying to use the comparison operators with struc

Re: [elixir-core:6187] Proposing backticks infix syntax for arity-2 functions

I agree that the pipe operator solves this already. I think what was meant by "difference between how code is executed inside clauses and outside" is the fact that guards have different rules than function bodies (i.e. you can only use a subset of "blessed" functions in guards). At least that's my

Re: [elixir-core:6208] Re: Introducing is_kind/2 and guard-safe operators: is, is_not, is_any, are, are_not, are_any

Just to throw in my two cents, here's how I define my own custom guards in Timex: https://github.com/bitwalker/timex/blob/master/lib/timex/macros.ex#L96 I'm not sure that this proposal simplifies anything for me really, but maybe I'm misunderstanding the benefit. Paul On Fri, Aug 12, 2016 at 2:2

Re: [elixir-core:6211] Introducing is_kind/2 and guard-safe operators: is, is_not, is_any, are, are_not, are_any

Hey José, could you give an example of what you mean? At least with those guards, using them in function bodies appears to work just fine, is it because they are working on simple types (i.e. integer, tuple)? If it does fall down in the general case, I can definitely see where that would make it a

Re: [elixir-core:6213] Introducing is_kind/2 and guard-safe operators: is, is_not, is_any, are, are_not, are_any

he function body. > "is_positive_integer send(self(), 1)" would send the message to self twice > and so on. > > > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Fri, Aug 12, 2016 at 10:22 PM, Paul Schoenfelder <

Re: [elixir-core:6342] Automatically infer the list of applications

I actually built exactly this feature into Distillery, but then removed it because I didn't have a good solution for omitting build-time only deps. I considered an option on dependencies, i.e. `release: false`, but that didn't feel right, and I didn't want to overload the meaning of things in the a

Re: [elixir-core:6344] Automatically infer the list of applications

releases metadata together, releases may have multiple > targets and therefore may still need to add their own configuration. So it > is important whatever format we choose can be used for both applications > and releases. > > > *José Valim* > www.plataformatec.com.br > Skype:

Re: [elixir-core:6346] Automatically infer the list of applications

> > We are discussing two types of application configuration (hence the > confusion) > > 1. If it is temporary, transient or permanent > 2. If it should be started, loaded, included, none or skipped (am I > missing any?) > I think it's unnecessarily confusing to split them apart that way, I think

Re: [elixir-core:6354] Automatically infer the list of applications

> > The issue with supporting entries such [myapp: :load] or [myapp: > :permanent] is what happens when projects A and B specify different > properties for :myapp. We would need to solve conflicts and that would > introduce complexity which otherwise does not exist on releases because > relaeses sp

Re: [elixir-core:6356] Automatically infer the list of applications

> > I am afraid it may not be that simple. Because if A requires the > application to only be loaded because let's say it needs to set some > configuration before the application starts, we would need to make sure > myapp is loaded before A and that myapp is started before B. So we need a > slightl

Re: [elixir-core:6362] Re: Automatically infer the list of applications

> > The last proposal completely dropped the ability to set an application as > permanent, temporary, etc. hence the name :extra_applications. If we are > going to have such ability, I would stick with :start_applications > previously proposed. Why drop that capability? It's rare for sure that so

Re: [elixir-core:6365] [Feature Suggestion] Wrap :rand.seed with Elixir

> > This code above just doesn't seem like the spirit of Elixir which focuses > on developer productivity and happiness by simplicity. > It sends people to learn the intricacies of erlang for something that > should be simple and is simple in a lot of other languages. > The first thing that pops o

Re: [elixir-core:6367] [Feature Suggestion] Wrap :rand.seed with Elixir

ld not find any additional official documentation on the matter and > that's the only way I found to seed rand with `crypto:strong_rand_bytes/1` > as suggested. > > On Wednesday, September 21, 2016 at 9:59:28 PM UTC-5, Paul Schoenfelder > wrote: >> >> This code above ju

Re: [elixir-core:6370] Deprecate 'single quotes for char lists'

At first blush I'm not a fan, I'm not sure that the use of ~c"foo" will be any less confusing than 'foo' - it will still look like a string, and behave like a list, but now with a sigil by it which new Elixir programmers will not remember and will need to look up. I also suspect this means there wi

Re: [elixir-core:6395] Proposal: Introduce `use GenServer, strict: true`

> > I am wondering if the best way to solve this problem would be to have a > @before_compile callback that checks if you defined any of the callbacks > with a different arity while, at the same time, did not define one with the > proper arity. This seems like a good compromise to me - it prevent

Re: [elixir-core:6540] Proposing Registry

Hey José, The use case I've been working on/with, and am most interested in, is a better distributed (global) registry, is this something that Registry will support (or perhaps even currently supports)? I haven't yet had time to look at Registry in detail, but it was the first thing that came to m

Re: [elixir-core:6542] Proposing Registry

consistent replication, but I'd love to see a solution which is either part of Registry, or can be built on it as an extension of some kind. Paul On Thursday, October 27, 2016, matteo brancaleoni wrote: > Hi, > > On Fri, Oct 28, 2016 at 2:59 AM, Paul Schoenfelder < > paulschoenfel...

Re: [elixir-core:6687] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

I just want to throw in my two cents. I don't think a warning should be generated if there is no ambiguity about a name. I see warnings primarily as a means of saying "hey, you've done this thing, and it may not behave the way you expect it to, or may cause errors at runtime, you should change it t

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

I think a good approach would be to define a reference date, from which all calendars can use as a point to convert to and from. This method is used in the book Calendrical Calculations, and their associated Java/Scheme implementation called Calendrica (which includes Egyptian/Armenian, Gregorian,

Re: [elixir-core:6758] [Proposal] Range.contains?

I think he is looking for a Range function which answers whether a range is a subset of another range, e.g. 1..10 contains 2..4 == true. On Tue, Dec 20, 2016 at 3:47 PM, José Valim wrote: > Is there any reason to use Range.contains? given you can already do "x in > range" or "Enum.member?(range,

Re: [elixir-core:6760] [Proposal] Range.contains?

rmatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Tue, Dec 20, 2016 at 10:53 PM, Paul Schoenfelder < > paulschoenfel...@gmail.com> wrote: > >> I think he is looking for a Range function which answers whether a range >> is a subset of another range,

Re: [elixir-core:6760] [Proposal] Range.contains?

subset?. >> >> >> >> *José Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Director of R&D >> >> On Tue, Dec 20, 2016 at 10:53 PM, Paul Schoenfelder < >> paulschoenfel...@gmail.com> wrote: >> >>> I think

Re: [elixir-core:6783] defstruct

I definitely wouldn't call this a severe limitation, but it would be a nice-to-have for readability. That said, I haven't actually run into any cases where I would've used the shorthand syntax - as José mentioned in his original reply, the vast majority of the time, structs have functions that go w

Re: [elixir-core:6819] Re: Proposal: Behaviours, defoverridable and impl

I believe the reason why `@impl` is required is because if a callback is optional, you can't warn about it missing, but the bug would be if someone *thought* they were implementing the optional callback, but had the signature wrong. I do wonder though if it would be possible to check for function d

Re: [elixir-core:6827] [Proposal] Enum.sort for Dates

Probably easier to use `Enum.sort_by(dates, &DateTime.to_unix/1)`, no? Paul On Fri, Jan 20, 2017 at 1:39 PM, Josh Crews wrote: > Current behavior: > > > iex(3)> [~D[2017-01-04], ~D[2017-04-03], ~D[2017-01-05]] |> Enum.sort > > [~D[2017-04-03], ~D[2017-01-04], ~D[2017-01-05]] > > > Proposed: > >

Re: [elixir-core:6830] [Proposal] Enum.sort for Dates

s"? > > On Friday, January 20, 2017 at 1:42:20 PM UTC-6, Paul Schoenfelder wrote: >> >> Probably easier to use `Enum.sort_by(dates, &DateTime.to_unix/1)`, no? >> >> Paul >> >> On Fri, Jan 20, 2017 at 1:39 PM, Josh Crews wrote: >> >

Re: [elixir-core:6868] Proposal: warn for untreated deps

Distillery does this currently, so the code could likely be reused with some tweaking, I'll look into opening a PR for it. Paul On Sat, Feb 11, 2017 at 1:57 PM José Valim wrote: > > Perhaps we could soft-deprecate it in 1.5, i.e. remove the description > from docs (e.g. https://hexdocs.pm/mix/M

Re: [elixir-core:6878] Sorting maps when inspecting

+1 from me! On Mon, Feb 13, 2017 at 4:49 PM, Eric Meadows-Jönsson < eric.meadows.jons...@gmail.com> wrote: > Currently struct and map keys are in indeterminate order when they are > inspected. Due to implementation details in the VM maps that have <32 keys > are in term order but for larger maps

Re: [elixir-core:6946] Is this a bug in my brain or the compiler?

Isn't the pin operator unnecessary/invalid here? Two bindings in a match with the same name asserts that the two values are the same. Paul On Wed, Feb 22, 2017 at 9:44 PM Allen Madsen wrote: > Your non-method example isn't the same as the method example. The > equivalent would be: > > [n, %{^n

Re: [elixir-core:6957] Proposal: Streamlining child specs

Just my two cents, but if the change involves reimplementing the supervisor behaviour, I'm really not a fan - I have to say that neither of the proposals solves any problems I actually have, but that in and of itself isn't a reason to object, but re-implementing :supervisor seems like a huge change

Re: [elixir-core:7138] Re: Thoughts on `Enum.compact/1`

> > This is probably my Ruby experience/bias exposing itself but: > > - removing nil elements from a collection is a common pattern > - Enum.compact(list) is more intention-revealing than Enum.reject(list, > &(nil?(&1))) > I really don't agree that `Enum.compact(list)` is somehow more revealing th

Re: [elixir-core:7171] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

I agree, it's an inherently subjective issue as well, which means no solution will make everyone happy. Additionally, at this point, the change has pretty well propagated throughout the community, so the "damage is done" so to speak (though in my opinion the current solution is the best given the l

[elixir-core:7274] Calendrical Calculations

Hey all, So I'm concerned about something I've noticed recently. I've seen multiple mentions of this book (Calendrical Calculations by Reingold and Dershowitz) and use of it's algorithms in Elixir's Calendar implementation, and I know I mentioned it back when I first suggested the idea of using so

Re: [elixir-core:7276] Calendrical Calculations

en the information above and the fact our "rata die" is no longer the > "by the book" definition, I believe we should change the name to something > more independent. > > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Dire

Re: [elixir-core:7286] Re: Calendrical Calculations

endrical Calculations paper (and as far as I know the > book) goes on about converting other calendars to the Rata Die format at > hand, and how the dates of certain holidays can be predicted, neither of > which we do in Elixir's standard library. > > So I am happy to say that

Re: [elixir-core:7314] Re: [Proposal] Control block with annotations and no commas

I'm not clear on the benefit here, why not just wrap the with expressions in a tuple for tagging? It's basically the same amount of code, doesn't require any new syntax, and accomplishes the same goal. In my opinion with is already the most complex syntactic construct in the language, adding even

Re: [elixir-core:7321] Re: [Proposal] Control block with annotations and no commas

> The `with` block is not that complicated, we could even think about adding support for left arrow notation, the `with` block beeing just a specific case It's not complicated for those of us who have the benefit of already knowing the language inside and out, but it is absolutely a complicated co

Re: [elixir-core:7403] [Proposal] DateTime.now_unix/1

You can also use System.system_time/1 as well. On Wed, Aug 30, 2017 at 6:34 PM Fernando Tapia Rico wrote: > Thanks for the prompt reply! > > I didn't know about :os.system_time(:second), that's exactly what I was > looking for. > > > It doesn't make a whole lot of sense to me to have a function

Re: [elixir-core:7586] Fixing default behaviour callback implementations

I'm not sure all of your criticisms are accurate. For one thing, I find that it is rather rare to provide default callback implementations for most behaviors - while there are exceptions, I think it's generally more common to have a "default" implementation of the behavior as a whole, for example,

Re: [elixir-core:7595] [Proposal] Introduce is_positive/1 and is_negative/1 macros

To be clear, those macros are used correctly within Timex, but that pattern is not safe in general, as the arguments are expanded multiple times, if the expanded arguments perform side effects, you'll have a bad time. Since those macros are meant for internal use only in Timex, I wasn't worried abo