Data.table: 与 magrittr 集成

DT[, a := some.function(a)]

工作得很好

但是恕我直言

Complicated_data_table_variable_name[, a_very_very_very_very_long_variable_name := some.function(a_very_very_very_very_long_variable_name)]

不是很好。 我喜欢添加这个便利功能的想法。

但也许%:>%会比%<>%更好？

你的数据集中不应该有这么奇怪的名字。 它既不方便又难以维护。 除此之外，您可以将列名存储在某个变量中，然后执行以下操作：

shortname <- "a_very_very_very_very_long_variable_name"
DT[, (shortname) := some.function(get(shortname))]

你是对的，但即使使用具有中间长度的变量，我仍然发现 magrittr 语法更便于读写。 无论如何，这只是我个人的意见。

我发现有时在复杂数据集中使用长变量名会更好，以明确保存在变量中的内容。 这是个人喜好的问题。 根据定义，便利功能不需要执行任务，它们只是使编码更快并且通常更容易理解。 我毫不怀疑此功能对许多用户有用。 但我也明白如果 data.table 开发人员不想实现/维护（太多）便利功能，你必须在某处划清界限；)

对于订阅此线程的人，请忽略最后一条评论（现已删除）。 这是愚蠢的。

根据@and3k的评论，我看到了一些价值：

DT[, a %:=>% some.function]

认为读起来更好（即:=和%>%在一起）。 是“快乐烟斗”吗？ 我热衷于减少变量名重复，如这里所写： http :

:=>运算符的=>部分有一些额外的含义，也许:=: ？

DT[, a %:=:% some.function]

或:=.直接映射为:=后跟.传递给 fun

=>有什么额外的含义？ >很好，因为它将 LHS 作为参数传递给 RHS。 这就是 Hadley 从原来的%.%变成%>% 。

我的理解是，转向%>%的主要动机是它比%.%更容易输入（我猜很多时候试图输入%.%会意外地导致%>% ）。

我的意思是 _greater 或 equal_ 运算符。
那么%:>%呢？ 这比%:=>%或%:=:%更容易输入。
and3k 已经在上面提到过。

我的投票是给%:>%或:> 。

%的存在只是因为 R 不允许在野外使用中缀运算符，对吗？ 不妨将运算符保持在DT[] 。

没有考虑打字方面，即我认为按住操作符中所有字符的 shift 更容易。 说得通。
不幸的是， :>无法解析。 [...]仍然必须是有效的 R 语法（所有参数在传递给函数之前总是被解析）所以我们不能在[...]组成新的运算符，仍然需要换行与%的。
好的，那么%:>%对我来说也很好看。 并不是说这是一个巨大的优先事项，但实施起来并不难，讨论也很好。

谢谢， %:>%看起来不错。

只是好奇，为什么:>不解析而:=在[....]内部解析？ :=也不是有效的 R 语法，是吗？

@my-R-help 这是有效的语法，请参阅为什么 := 允许作为中缀运算符？

+1 我同意 OP 功能请求和 magrittr 语法的使用。 出于多种原因，它是最佳和最明显的选择。

• 人们已经大量使用带有 itmagrittr 的 DT
• magrittr 的语法在这一点上无处不在……甚至可能有自己的 rstudio 热键……而任何其他语法选择都可能以混乱告终。

我强烈建议你不要通过引入一个新的运算符来过度考虑这个 FR，​​它的选择就像任意 magrittr 的选择一样。

我强烈建议你不要通过引入一个新的运算符来过度考虑这个 FR，​​它的选择就像任意 magrittr 的选择一样。

@ctbrown该提议是针对管道操作符的，它与 magrittr 的 vanilla %>%不同，该包还有其他几个管道操作符。 只要不与其中任何一个冲突，有什么问题？

我认为 OP 的 FR 要求已经足够清楚了，即
专门使用%<>%作为组合转发管道和分配
操作员。 大概这是因为 magrittr 已经定义了%<>%
正是这个目的。 由于 magrittr 似乎是占主导地位的管道
实施，许多人似乎在使用 %<>%，我的学生和
其中的同事。 介绍另一个没有意义
运算符用于完全相同的目的。 选择一个更有意义
与社区已经接触过或已经接触过的内容一致的语法
采纳。 请参阅我关于无处不在的观点。

我问你，你希望通过引入另一个运营商获得什么
在不同的上下文中执行完全相同的功能？ 我看不到
任何好处。 您选择的任何运算符都将像 magrittr 一样随意。
那么通过简单的方式使整个系统不那么随意是没有意义的
在这里跟随 magrittr 的领导，而不是再做一个任意的
句法决定？

2016 年 10 月 27 日星期四上午 11:41，franknarf1 [email protected]
写道：

我强烈建议您不要通过引入新的 FR
操作员的选择就像任意 magrittr 的选择一样..

@ctbrown https://github.com/ctbrown 该提议是针对管道操作员的
这与 magrittr 的香草 %>% 有所不同，a
也有其他几个管道操作符的包。 只要不
与其中任何一个冲突，有什么问题？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -256732710，
或静音线程
https://github.com/notifications/unsubscribe-auth/AC5xaxIp36dTUCz9d5a5mU7CJUV6PaxCks5q4PBDgaJpZM4FSJR5
.

%<>%是否按引用分配？ 如果不是，那么他们实际上_不_在做完全相同的事情。

从技术上讲，您是正确的，magrittr 的 %<>% 不会按引用分配，
但这不是重点。 在用户的预期范围内，没有
不同之处。 无论是按引用还是按值赋值都是一个
实现问题不是接口问题。 OP 建议采用
magrittr 接口并不一定建议执行。
我在 OP 建议中看到了优点。 看上面的原因。 我不
查看采用类似 '%:>% or anything as arbitrary. The merit of this has not been articulated. The %<>%` 的理由
运营商已经存在并由 magrittr（第 12 大
根据 METACRAN 的流行包。）就像任何这似乎
成为标准（在 R 社区内）。 关注的好处
既定做法是减少用户混淆和需要
全面的文档。 你得到：“哦，这和 magrittr 一样，我
知道这个前向管道并进行分配”，而不是“这是什么
奇怪的 %:>%? 这是新的小丑表情吗？”

2016 年 10 月 27 日星期四下午 2:18，Michael Chirico通知@ github.com
写道：

%<>% 是否按引用分配？ 如果不是，那么他们实际上_不_在做
完全一样的东西。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -256772769，
或静音线程
https://github.com/notifications/unsubscribe-auth/AC5xa3ssE14PcamL2U9HlvCdfA8-7Iz8ks5q4RUagaJpZM4FSJR5
.

在用户的期望中，没有区别。

首先，我不认为这是真的，你代表所有用户； 例如，我是用户。 其次，如果这是真的，那么这些用户应该在学习使用 data.table 时了解差异。

你的“上述理由”在我看来并不成立。 实现一个非重叠的管道操作符来做一个独特但相关的事情并不是在某种程度上违背 magrittr。 对我来说——这只是我的印象，就像你所说的一切都是你的一样——这似乎与 magrittr 的“既定做法”完全一致（我使用它的频率几乎和我使用 data.table 的频率一样） ）。

在此上下文中的使用完全有可能一次分配给多个对象（列），您肯定会同意这与%<>% .. 截然不同？ 我是说

DT[, (cols) %:>% lapply(as.character) ]

而且，除了通过引用修改和可能同时修改几个东西之外，我们还有一个事实是我们正在修改一个东西的一部分（data.table），这与%<>%完全不同。

无论如何，由于开发人员短期内没有表现出任何执行此任务的迹象（通过将这个 FR 标记为优先级或里程碑），如果它真的向前推进了，如何重新审视它？

@ctbrown _by-reference_ 不仅在实现上有所不同，还需要与用户界面中的 _by-value_ 函数区分开来。 这就是 data.table 中set*函数和:=运算符的全部意义，以便向用户清楚地传达实际修改函数输入的内容。 在这么短的时间内很难对 R 社区内的标准进行判断，R 应用程序已经编写了几十年，现在判断“新标准”还为时过早，最终是关于代码格式（嵌套/取消嵌套）的 AFAIK ，如果我错了，请纠正我。 正如我在我发现 magrittr 管道之前多次说过的那样，当我想展示代码块时，它非常适合交互式使用，但在编写主要关注功能的 R 包时并不是真正必要的。 IMO 如果某些内容可以就地修改，则它必须具有不同的操作员，然后才不会进行就地修改。

@弗兰克纳夫1 ，

首先，没有声称为ALL R 用户发言。 这是一个荒谬的断言。 提到“用户的期望”是我自己的，大概是 OP 和我的几个学生，他们已经尝试过dt[ , var %<>% ... ]并询问为什么它不起作用。 此外，如果 DT 可以按预期工作，_Forcing_ 用户“在学习使用 data.table 时了解差异”是危险的。 这会导致糟糕的软件设计。

其次，正如您所指出的，接受或拒绝支持遵循 OP 遵循 magriitr 语法的建议的论点取决于个人。 关于为什么这会是有益的，已经提出了一些论点，但很少有令人信服的论点提出为什么替代方案会更好甚至有益。 似乎有一个次要的论点，因为实现不同，但这是一个相当弱的论点。

此外，

• %<>%也可以实现来处理多个参数，并且在遵守 OP 和其他人的期望的同时，在上下文中仍然很有意义。 OP 的建议并没有真正说明他是否要修改多个参数。
• 无论您是修改部分还是整体都是一个问题——您总是在修改事物的一部分，即环境。
• 开发人员的作为或不作为是另一个红鲱鱼，与 OP 的提案/请求的优点无关。 这是一个相当糟糕的诉诸权威的论点，无论如何都没有真正提出意见。

如果有人支持/反对 OP 的建议，我很想听听他们的意见。 但我唯一听到的是，“因为它是不同的”。 也许有些人会认为这是有效的，但与 OP 最初的建议相比，替代方案似乎并没有更好。

曾经使用过data.table每个人都不得不在某个时间或其他时间学习如何使用:= （可能在开始后不久）。 哦不，阴森森的！ 为什么不是<-或= ？

这个问题的答案是任何人在使用data.table学到的第一件事。 这是第二个介绍小插图的主题。

%<>%与%<:>% （或任何可能的结果）是完全相同的区别。 所以马特在这里回答了这个问题：

http://stackoverflow.com/questions/7033106/why-has-data-table-defined-rather-than-overloading

@jangorecki

首先，大多数用户不需要知道按引用和按值的区别。 知道这一点并不是使用 DT 的先决条件。 据推测，这就是 DT 语法与 DF 如此接近的原因。 @mattdowle可以清楚地设计具有纯功能界面的 DT。 他没有。 据推测，原因之一是 DT 可以充当替代品。

关于set*函数，这些可能通过引用表示，但奇怪的是它们没有被命名为set*ByRef ，这样会更清楚。 这些功能似乎主要用于执行有效操作，将 DF 转换为 DT 并设置键。 它们可以用来表示按引用操作似乎是次要的。

至于:= ，我想我记得@mattdowle在 useR UCLA 被问到为什么他使用:=而不是= 。 IIRC，他说他不能使用=而:=是可用的。 IIRC，他更喜欢使用= 。

WRT，R 社区中的标准——因其缺乏标准而臭名昭著——magrittr 尽其所能：无处不在地使用和讨论。 OP 建议与它的互操作性将是一个不错的功能。 我同意。 如果您对此有任何疑问，请查看其 CRAN 页面。 开发人员正在自己的软件包中使用 magrittr。 而且，编写包并不是R用户的大多数。 但这确实是题外话。

您提供的论点属于：“DT 与 magrittr 不同，因为分配是通过引用进行的，因此语法不同”。 对此的回应仍然是：实现不同，是的。 但界面应该是相同的，因为它实际上是大多数用户的相同操作，符合用户期望，并且可以从上下文中推断出其真实操作。

@mattdowle可以清楚地设计具有纯功能界面的 DT。 他没有。

我很高兴他没有。 锁定“纯功能性”只是意味着放弃一些用户现在可以使用的重要功能，以便编写更快、内存效率更高的代码。 我有项目（即anchormodeling ）在“纯功能”框架中使用基本上是不切实际的。

@jangorecki
我完全同意。 但是我们开始从最初的提议偏离到 DT 的优点。

@MichaelChirico

感谢您为讨论带来了启发。 参考文献与原始提案略有不同，但它们有助于说明赞成或 OP 提案的观点，即，

• 运营商的选择是任意的。 马特·道尔在:=之前尝试了几次。 他首先尝试了更符合标准的显而易见的事情： <- 、 <<- 、 :=只是偶然发现的，因为它是可用的，并且为丑陋的语法做了替代. 很明显，他更喜欢现有的运营商而不是定义一个新的运营商。
• 用户会从上下文中了解到赋值是通过引用赋值发生的，但它是如何发生的并不重要。
• 等等。

首先，没有声称为 ALL R 用户发言。 这是一个荒谬的断言。 提到“用户的期望”是我自己的，大概是 OP 和我的几个学生

我想说的是，当您真正指的是自己时，提及“用户”是一种适得其反和分散注意力的修辞手段。 您可能还注意到 OP 说“ %:>%对我来说看起来不错”。

开发人员的作为或不作为是另一个红鲱鱼，与 OP 的提案/请求的优点无关。 这是一个相当糟糕的诉诸权威的论点，无论如何都没有真正提出意见。

这不是对权威的呼吁，因为我不是在那里争论一个观点。 它呼吁你冷静下来。 这甚至可能永远不会实现，所以你不能推迟大惊小怪吗？ 我想在实现之后切换函数的名称将是一件微不足道的事情（如果有的话），我们将更好地了解此时我们正在查看的确切功能。

就实质性论点而言：

• 我认为 magrittr 不太可能使用%<>%来修改其 LHS 上的多个对象，例如list(x, y) %<>% log ，类似于DT[, c("x", "y") := lappy(.SD, log), .SDcols = c("x","y")] 。
• 同样，您的提示是我看到的第一个提示，即%<>%可能用于修改对象的一部分，例如x[ 2:4 ] %<>% log ，类似于DT[ 2:4, x := log(x) ] 。

我期待在https://github.com/tidyverse/magrittr/issues上看到您关于这些功能的 FR，并希望它们通过，因为我肯定会使用该功能。

@弗兰克纳夫1 ，

取点； 我错过了 OP 说“%:>% 对我来说看起来不错”。

尽管如此，不仅仅是我。 OP 首先建议使用 magrittr 语法。 据推测，尽管后来承认了替代方案，但他认为这是一个好主意。 我也认为这是一个好主意，这就是让我来到这里的原因，这是由几个尝试过它的学生提出的。 据推测，还有其他人。 无论如何，将其视为一个孤立的观点是有点离题的。

其次，这个论点实际上是对权威的呼吁。 这也可能是“呼吁我冷静下来”，尽管我非常冷静。 无论如何，这一点似乎离题了，它没有解决 OP 建议的优点。 此外，这极不可能实施的事实似乎与提案的优点无关。

它必须进一步承认你是正确的。 一旦实现，更改函数的名称将是微不足道的。 但是，此类更改可能并且可能会破坏使用该功能开发的任何代码。 在实现之前花时间讨论接口而不是在以后用不兼容的更改给用户带来负担是非常有意义的。 目前尚不清楚关闭讨论有什么用处。

至于实质性的论点，他们似乎更多地主张增加 magrittr 的功能，而不是提出的%<>%语法。 （就个人而言，我同意您的意见，即 magrittr 人员应该实施您的建议，尤其是第一个。我不确定我是否会使用第二个。）不管向 magrittr 人员提出的建议，都没有采用您的增强功能和使用 magrittr %<>%运算符与 DT 不一致。 而且我还没有真正读懂和的优越性的一个有力的论据%:=% （或备用），以%<>% 。

为了回到主题，我认为总结相关论点可能会有所帮助。

支持%:>%论据：

• DT 管道前向分配将通过引用实现分配。 这需要在运算符中加以区分，因为它使用户清楚如何实现分配。 这可以避免不必要的混淆。
• 在某些情况下（例如多重分配、部分分配），DT 可能会添加 magrittr 不（还？）支持的附加功能。 因此，最好区分这些操作。
• %<>%与任何其他选择一样随意， %:>%更像 DT。

支持%<>%论据：

• magrittr 已经实现了一个管道前向赋值运算符，它被广泛使用，并且似乎是一个标准。 遵循标准，无论多么隐含，都意味着 DT 开发人员在描述新运算符所需的文档和解释数量方面的负担会减少。
• 用户已经在:=的 RHS 中使用 magrittr 和 DT。 此外，一些证据表明用户期望/已经尝试过 magrittr %<>%语法。 采用它符合这些用户的期望。
• 将代码移至 dplyr/magrittr <--> DT 会更简单、更容易，因为在某些情况下语法可能相似。
• 操作员数量的增加导致额外的复杂性。 在这种情况下，复杂性是不需要的，因为操作符应该指定操作并且确实需要指定实现——这就是通用方法的工作方式。
• %:>%与%<>%一样随意。

将代码移至 dplyr/magrittr <--> DT 会更简单、更容易，因为在某些情况下语法可能相似。

您绝对没有想到通过引用进行修改会严重破坏这种移植代码。
你知道你的原始对象不会改变的地方会因为赋值方法改变而突然改变，这就是为什么区分运算符很重要（并保持按值（复制）赋值的可能性在同一行代码也）。

与复制 data.table 与复制 data.frame (dt2 <- dt) 时遇到的问题相同，您突然想知道为什么当您只在第二个上工作时您的原始 dt 已更新。

采取这种确切的预防措施，也使您的第一点无效，因为它需要对操作员做什么的精确文档，使用不同的文档可以轻松找到正确的文档。

@tensibai，

明白了。 因此，“可能是”断言的一部分。

在星期三，2016年11月2日在上午01时32分，Tensibai [email protected]写道：

将代码移至 dplyr/magrittr <--> DT 会更简单更容易，
因为在某些情况下，语法可能相似。

你完全错过了通过引用修改的方式
打破这种移植的代码。 您确实知道原件的地方
对象不会改变会突然改变因为赋值方法
改变，这就是为什么区分运营商很重要的原因
（并保持在同一行中按值（复制）分配的可能性
的代码也）。

与复制 data.table 与复制 data.frame 时的问题相同
(dt2 <- dt)，突然你挠头为什么你的原始 dt 有
当你只在第二个工作时更新。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -257801913，
或静音线程
https://github.com/notifications/unsubscribe-auth/AC5xaxyWXkh4C7i5-GtjMFiQ0AY2L5BLks5q6EqIgaJpZM4FSJR5
.

感谢您的所有评论和反馈。

只是一件小事（也许我遗漏了一些东西）：在这种特定情况下，无论是按引用分配还是按值分配，它是否会有所不同？ 我们要做的是更新data.table 中的一列（或几列）。 用户知道无论哪种方式，旧列都会被覆盖。 没有误会的余地，不是吗？ 相比之下，这与DTa=DTb与DTa=copy(DTb) （我不是在这个功能请求中谈论的）非常不同，我们在那里处理 data.table 本身，以及在哪里无论我们是按引用分配还是按值分配，这确实有所不同。

@我的-R-帮助，

你的直觉是正确的。

它不会使这个操作是如何_implemented_用户的差异。 从用户的角度来看，结果是相同的——列中的值被重新分配。 有一些论点表明应该有一些区别，但没有关于_为什么_的令人信服的解释。

您采用%<>%语法的建议是合理的。 它正确地假设实现与 _interface_ 不同，并且由于执行操作有一种流行和现存的实践，因此应该采用它。 事实上，这遵循了良好的软件设计实践。

（顺便说一句，当你说“谢谢（SIC），%:>% 对我来说看起来不错。”时我有点沮丧，并没有更强有力地支持你最初的直觉和建议。无论如何，谢谢你的提议。不管它是否在DT中实现，都很棒，）

谢谢你的回复，克里斯托弗。

澄清一下，我个人更喜欢%<>%因为它与 magrittr 更一致，而且似乎很多人都在使用它。 但是，如果 data.table 开发人员更喜欢另一个运算符（例如%:>% ），我也可以接受（尽管我个人更喜欢 magrittr 方式）。

也许我应该这样表达。 对不起，如果它引起了任何混乱。

用户知道无论哪种方式，旧列都会被覆盖。 没有误会的余地，不是吗？

用户如何实现此操作并没有什么不同。 从用户的角度来看，结果是相同的——列中的值被重新分配。

我仍然觉得有加入足枪的空间。

让两个运算符在其副作用上的行为略有不同，命名相同很容易出错，并且_will_ 会导致混淆。 我没有比这更好的争论了，但是当包屏蔽基函数或加载包重载另一个包函数时，为什么 R 会警告您是有原因的。

在我看来，当副作用不同时，至少对某些用户来说，拥有特定的操作符确实会有所不同。

_Bonus_ 搜索操作符你最终会在 DT 页面上解释它的警告/限制，而不是在帮助中有两个选择。

这里我们谈论的是一种语言，而不是用户界面，虽然我同意最终的软件用户不应该关心 X 按钮背后的实现，但我非常不同意程序员不应该关心功能背后的实现。

主要反对意见是：有人认为%<>%行为与在 DT 之外的行为相同，当它在无意中划伤他的 DT 列时会变得疯狂。

TL;DR：编程不是用户体验，你必须明确你想要什么，因此不应该重用众所周知的名字。

@滕斯拜，

副作用在某种程度上不同的说法是可疑的。 在每种情况下，都在执行变量重新分配。 它们都是副作用。 实现（by-ref 或 by-value）并没有真正区分这些，因为两个系统的比较最终状态以类似的方式发生了变化。

即使副作用不同。 这种区别并不重要。 这一点在上面的讨论中已经反复提到过。 如果区别很重要，则应该可以提供一个示例，说明它会对用户产生影响。 缺乏反事实的例子但不是结论性的，这强烈表明没有区别。

关于：

你必须具体说明你想要什么，因此不应该重用众所周知的名字。

这是错误的。 重用常见的、众所周知的名称不仅应该发生，而且非常普遍，被认为是良好的编程实践。 这称为多态性。 具有相同名称但实现方式不同的方法是完全可以接受的：

人.speak()
“你好世界”
狗.speak()
“纬”

在每种情况下都使用speak 。 这是不好的做法吗？ 不。事实上，如果不采用多态，那将是一场灾难； 每个函数和方法都有自己的名字。 虽然这是一个基于 OO 语言的相当通用的示例，但 R 也不例外。 R 具有以类似方式工作的 S3 方法和通用函数。

建议是：

我非常不同意程序员不应该关心函数背后的实现。

同样存在缺陷，与大多数用户体验背道而驰。 大多数程序员可能使用数百个函数/方法。 他们这样做是在不知道他们的实现细节的情况下。 用户_确实_需要知道函数的输入和输出/副作用才能有用，但它如何到达那里通常是无关紧要的。 诚然，用户有时需要了解细节才能调整或调试功能，但可以说在极少数情况下是这样。 考虑这样一个世界，在这个世界中，用户必须知道每个功能在各个级别是如何工作的。 认知负担将是巨大的； 对任何复杂的事物进行编程将是一项不可能完成的任务。 关于：

搜索操作符的奖励，你最终会在 DT 页面上解释它的警告/限制，而不是在帮助中有两个选择。

这不是一个 _Bonus_，而是 a) 引入混淆（这与非常流行的 magrittr 包有什么不同，exaclty？）和 b) 首先创建额外不需要的文档的需要。 如果使用 magrittr 语法，DT 开发人员可以说：“去那里阅读文档和小插图；DT 支持他们在那里做的事情。” 这种合作和跨包借用提升了 DT、magrittr 和 R 生态系统的价值。 )

最后，从“用户界面”、“X 按钮”和“UX”的评论中可以推断出，隐含了特定的 UI。 事实并非如此。 而且，虽然很明显我们在谈论一种语言，但说该语言缺乏界面是错误的。 接口就是它的语法，它很重要。

总结一下，所以问题最终可以得到解决。

我们所需要的只是处理以下翻译。

DT[, a %<:>% fun] ## or "%:>%"

DT[, a := fun(a)]

是对的吗？

如果a不是符号而是字符变量，它应该如何表现？

DT[, "a" %<:>% fun]

DT[, "a" := fun(a)]   ## this?
DT[, "a" := fun("a")] ## or this?

如果它的长度不是 1 呢？

DT[, c("a","b") %<:>% fun]

DT[, c("a","b") %<:>% fun(a, b)]
DT[, c("a","b") %<:>% fun("a","b")]
DT[, c("a","b") %<:>% lapply(list(a, b), fun)]
DT[, c("a","b") %<:>% lapply(c("a", "b"), fun)]

就个人而言，我会关闭它，因为它不会修复，因为会增加很多复杂性并且不会解决任何新问题。
我看到同意，因此关闭，如果确实需要，我们可以随时重新开放。